Email authentication is not one system but three, built at different times to answer different questions. SPF asks which servers may send for this domain? DKIM asks was this message really authorised by the domain, and has it been altered? DMARC asks do those answers match the address the reader actually sees — and what should happen if they do not? Each has a hole the others cover, which is why the large mailbox providers now expect all three from anyone sending meaningful volume.
SPF: a list of permitted servers
SPF (Sender Policy Framework, RFC 7208) is a TXT record at the domain root listing the IP addresses and services allowed to send mail on its behalf:
v=spf1 include:_spf.google.com ip4:203.0.113.10 ~allWhen a message arrives, the receiver looks up the SPF record for the domain in the envelope sender (the return-path — not the From line the reader sees) and checks whether the connecting server's IP is on the list.
Where it breaks: forwarding. When a message is forwarded, it arrives at its final destination from the forwarder’s server — an IP that is not on your list — and SPF fails even though the mail is genuine. SPF also says nothing about the message content: a permitted server can send an altered message and SPF will still pass. And because it checks the envelope sender rather than the visible From, SPF alone does not stop a scammer putting your domain in the From line while using their own envelope domain.
DKIM: a signature that travels with the message
DKIM (RFC 6376) takes the opposite approach: instead of vouching for servers, it signs the
message itself. The sending server adds a cryptographic signature over the body and selected
headers; the receiver fetches the domain’s public key from DNS — at
selector._domainkey.domain — and verifies it. The mechanics are covered in
What is DKIM?.
Because the signature is part of the message, it survives forwarding intact — the main hole in SPF. It also proves integrity: change the signed content anywhere en route and verification fails.
Where it breaks: mailing lists and gateways that modify messages (subject-line tags, appended footers) invalidate the signature. Weak or mismanaged keys undermine the whole scheme — a 1024-bit key is a warning for good reason. And like SPF, DKIM on its own never looks at the visible From line: a scammer can sign a message perfectly validly with their own domain’s key while displaying yours to the reader.
DMARC: tying both to the From line
DMARC (RFC 7489) closes that gap with a concept called alignment. A message
passes DMARC only if it passes SPF or DKIM and the domain that passed matches the
domain in the visible From header. A valid DKIM signature from
scammer-mail.com does nothing for a message claiming to be from
yourbank.com.
DMARC is also where policy lives. The record — a TXT at _dmarc.domain — tells
receivers what to do with failures:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.comp=none— deliver anyway, but report. The monitoring stage.p=quarantine— treat failures as suspicious (typically the spam folder).p=reject— refuse failures outright. The destination policy.
The rua= tag requests aggregate reports: daily summaries from receivers showing
what is sending as your domain and whether it authenticates. These reports are how you
discover forgotten senders before tightening policy — and how you monitor a
DKIM key rotation for trouble.
Side by side
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Verifies | Sending server’s IP | Signature over content | Alignment with the From line, plus policy |
| DNS record | TXT at the domain root | TXT at selector._domainkey | TXT at _dmarc |
| Survives forwarding | No | Usually | Passes if either aligned check survives |
| Detects tampering | No | Yes | Via DKIM |
| Protects the visible From | No | No | Yes — its whole purpose |
| Tells receivers what to do on failure | Weakly (~all vs -all) | No | Yes (p=) |
Common misconceptions
“SPF is enough.”
It was a reasonable position in 2006. Today it fails forwarded mail, proves nothing about content, and without DMARC does not even protect the address your customers see. Receivers score mail with SPF alone accordingly.
“DKIM encrypts my email.”
No — it signs it. The content remains readable to every server that handles it. DKIM proves origin and integrity, not confidentiality.
“DMARC works without DKIM.”
Technically it can pass on aligned SPF alone — until the first forwarder breaks SPF and your genuine mail starts failing DMARC. DKIM is what makes a strict DMARC policy safe to enforce. Treat DKIM as a prerequisite, not an optional extra.
“Any DKIM pass is a good sign.”
Spam and phishing mail frequently carries a valid DKIM signature — for the spammer’s own domain. The pass only means the named domain signed it; alignment (DMARC) is what connects that fact to the sender the reader sees.
A sensible rollout order
- Publish SPF for every domain that sends mail — and a null record (
v=spf1 -all) for domains that never send. - Enable DKIM signing everywhere, with 2048-bit keys. Verify each selector with the DKIM checker.
- Publish DMARC at
p=nonewithrua=reporting, and watch the reports for a few weeks. - Fix whatever the reports surface — forgotten newsletter platforms are the classic find.
- Tighten to
p=quarantine, thenp=reject.
You can check your SPF and DMARC records with the email DNS validator on dns.studio, and your DKIM selectors right here — start with the selector finder if you are not sure what your domain publishes.
Related guides
- What is DKIM? — the signing and verification mechanics.
- DKIM troubleshooting — the failures you will actually meet.
- DKIM selectors explained — where the public key lives.
- Email DNS validator (dns.studio) — check SPF and DMARC records.
- BIMI Studio — take email trust further with a verified brand logo.