What are SPF, DKIM and DMARC, in plain English?
Scott Anderson · Last reviewed
Short answer
SPF lists which servers may send email using your domain. DKIM adds a cryptographic signature proving a message wasn't altered and genuinely came from you. DMARC ties those two to the name your recipient sees, tells receiving servers what to do when they fail, and sends you reports. You need all three; they solve different halves of the same problem.
Key facts
SPF is defined in RFC 7208, DKIM in RFC 6376 and DMARC in RFC 7489. All three are open standards, not vendor products. RFC 7489 (DMARC) ↗
Bulk senders to Gmail need SPF and DKIM and DMARC, with the visible From: domain aligned to at least one of them. Google sender guidelines ↗
SPF evaluation is capped at ten DNS lookups. Exceed it and the result is a permanent error, not a partial pass. RFC 7208 §4.6.4 ↗
Email was designed in an era when everyone on the network was trusted, which is why anyone can still type any name they like into the From: field. The three records below are the retrofit: a way for a receiving server to check whether a message claiming to be from your business actually is.
They're often described as interchangeable. They aren't. Each answers a different question, and each fails in a different way.
SPF — who is allowed to send as you
SPF is a public list, published in your DNS, of the servers and services permitted to send email using your domain. When a message arrives, the receiver looks at the server it came from and asks whether that server is on your list.
Its famous weakness is that it breaks on forwarding. If your address forwards to a personal Gmail, the forwarding server isn't on your list, so SPF fails — even though the message is entirely legitimate. Its less famous weakness is the ten-lookup limit: every service you add consumes at least one lookup, and past ten, receivers throw the whole record away.
What an SPF record looks like
A small business on Google Workspace
v=spf1 include:_spf.google.com ~all
Google's servers may send. Everything else is a soft fail.
The same business, plus a newsletter and invoicing
v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.xero.com ~all
Three lookups of the ten available. Each new tool costs at least one more.
DKIM — proof the message wasn't tampered with
DKIM signs each outgoing message with a private key held by your mail provider. The matching public key lives in your DNS under a name called a selector. The receiver recalculates the signature and checks it against that key.
Because the signature travels with the message, DKIM survives forwarding in a way SPF cannot. That makes it the more valuable of the two, and it's why relying on SPF alone leaves gaps you'll never see from your own desk.
Every separate service that sends as you needs its own DKIM key installed. One working selector doesn't cover the others.
DMARC — the instructions, and the reporting
SPF and DKIM both authenticate technical details that your recipient never sees. DMARC connects them to the domain in the From: line — the part a human reads — and that connection is called alignment.
It then tells receiving servers what to do when a message fails: nothing (p=none), send it to junk (p=quarantine), or refuse it outright (p=reject). And it asks receivers to email you daily aggregate reports of everything sent in your name, which is the only practical way to discover the tools you forgot about and the people spoofing you.
The three at a glance
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Answers | Is this server allowed? | Was this message altered? | Do the first two match the visible sender, and what now? |
| Survives forwarding | No | Usually | Depends on the other two |
| Lives at | your domain | selector._domainkey | _dmarc.yourdomain |
| Fails when | Sender not listed, two records, or over ten lookups | Key missing, rotated, or message modified | Neither aligned check passes |
The order to do this in
Sequence matters more than speed. Enforcing before you've found every sender is how businesses block their own invoices.
- 01
Inventory every sender
Mail host, accounting, CRM, newsletter, e-commerce, forms, appointment reminders. You cannot authorise what you haven't listed.
- 02
Publish one SPF record covering all of them
One record, ending in ~all or -all, comfortably under ten lookups.
- 03
Turn on DKIM everywhere it's offered
Each platform gives you a selector and a key to publish. Do this for every tool, not just your main mail host.
- 04
Publish DMARC at p=none with reporting
Monitoring mode, deliberately. Collect a few weeks of reports and find out what's actually sending as you.
- 05
Move to quarantine, then reject
Once the reports show only senders you recognise, tighten the policy. This is the step that finally stops spoofing.
Frequently asked
Do I need all three, or is one enough?
You need all three. SPF alone breaks on forwarding. DKIM alone doesn't tell receivers what to do when it fails. DMARC alone has nothing to check. Gmail and Microsoft now expect the full set from anyone sending in volume, and treat the baseline as non-negotiable for everyone.
What's alignment, exactly?
SPF checks the hidden return-path address and DKIM checks the signing domain — neither is the name your recipient sees. Alignment requires that one of those matches the domain in the visible From: address. Without it, a spammer could pass SPF for their own domain while displaying yours.
How long do DNS changes take to work?
Usually minutes to a couple of hours, governed by the TTL on your records. The authentication effect is immediate once propagated; reputation recovery, if your domain has been failing for a long time, takes longer.
Is 1024-bit DKIM still acceptable?
It still validates, and plenty of platforms shipped 1024-bit keys years ago and never rotated them. 2048-bit is the current expectation, and rotating up is a straightforward change worth making when you're in there anyway.
Find out where your domain actually stands.
The checker reads your real records in a few seconds. The review works out whether they cover everything you send.