SPF vs DKIM vs DMARC: What's the Difference?
SPF, DKIM, and DMARC are three separate email-authentication standards that work together. SPF lists who can send for your domain, DKIM signs your mail so it can't be tampered with, and DMARC ties the two together and tells receivers what to do when a message fails. You need all three.
TL;DR
- 1 SPF authorises sending servers, DKIM cryptographically signs messages, DMARC sets the policy and reporting on top of both.
- 2 SPF and DKIM each answer one question; only DMARC decides what happens to mail that fails, and only DMARC sends you reports.
- 3 They are not alternatives. A spoof-resistant domain publishes all three, with DMARC at p=reject.
What it does
The confusion is understandable: all three are DNS-published email-authentication standards, they are almost always set up together, and the acronyms get used interchangeably. But each does a distinct job. SPF (Sender Policy Framework) publishes the list of servers allowed to send mail for your domain. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message so a receiver can prove it wasn't altered and was authorised by your domain's key. DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of both: it checks that an SPF or DKIM pass actually aligns with the visible From address, tells receivers what to do when nothing aligns, and asks them to send you reports.
Do you need all three? Yes. SPF alone breaks the moment a message is forwarded, because the forwarding server isn't in your SPF list. DKIM survives forwarding but, on its own, tells a receiver nothing about what to do when the signature is missing. DMARC has no effect at all unless SPF or DKIM is already in place, because it only acts on their results. Publishing one or two of the three leaves a gap an attacker can use; the three together are what make a domain genuinely hard to spoof.
SPF vs DKIM vs DMARC at a glance
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it does | Lists the servers allowed to send mail for your domain. | Signs each message with a private key so receivers can verify it. | Sets the policy on SPF/DKIM results and requests reports. |
| What it checks | Is the sending server's IP on my authorised list? | Does the signature verify against my published public key? | Does an SPF or DKIM pass align with the visible From domain? |
| Where the record lives | A TXT record at your domain apex (v=spf1 ...). | A TXT record at <selector>._domainkey.<domain>. | A TXT record at _dmarc.<domain>. |
| Survives forwarding? | No. The forwarding server isn't in your SPF list. | Yes, as long as the body isn't rewritten. | Yes, via DKIM alignment (and ARC for rewritten mail). |
| What it can't do on its own | Doesn't tell receivers what to do on failure, and breaks on forwarding. | Doesn't say what to do when the signature is missing. | Does nothing unless SPF or DKIM is already published. |
How it works
-
1
You publish SPF (the list of allowed senders) and DKIM (your public signing key) so that legitimate mail can authenticate two different ways.
-
2
Your sending platforms sign outbound mail with DKIM and send from servers covered by SPF, so a normal message passes both.
-
3
A receiver checks SPF and DKIM, then DMARC checks alignment: does the domain that passed match the domain in the visible From header?
-
4
If neither SPF nor DKIM aligns, the receiver applies your DMARC policy (none, quarantine, or reject) and counts the message in the next aggregate report.
-
5
You read those DMARC reports to find legitimate senders that aren't yet aligned, fix them, and then tighten the policy to p=reject.
Common pitfalls
-
Treating them as alternatives and publishing only SPF. SPF breaks on forwarding and never tells receivers to block anything, so spoofing still works.
-
Publishing DMARC at p=reject before SPF and DKIM are aligned for every legitimate sender. DMARC only acts on their results, so a premature reject bounces real mail.
-
Confusing this comparison page with setup. Knowing the difference is step one; publishing the records is a separate job (see the setup guide and the guided scan).
-
Forgetting that a third-party sender (Mailchimp, a help desk, a CRM) needs its own DKIM alignment, or it passes SPF for its IPs while still failing DMARC for your domain.
FAQ
Do I need all three of SPF, DKIM, and DMARC?▾
Yes. They are not alternatives. SPF lists your allowed senders but breaks on forwarding; DKIM signs your mail and survives forwarding but doesn't say what to do on failure; DMARC ties them together, decides what happens to mail that fails, and sends you reports. A spoof-resistant domain publishes all three, with DMARC at p=reject.
What is the difference between SPF and DKIM?▾
SPF checks where a message came from: is the sending server's IP on the list you published for your domain? DKIM checks that the message itself wasn't altered, by verifying a cryptographic signature against your public key. SPF is about the server, DKIM is about the message, and DKIM survives forwarding while SPF does not.
What is the difference between DKIM and DMARC?▾
DKIM is one of the two authentication methods (it signs the message). DMARC is the policy layer that sits above DKIM and SPF: it requires that a DKIM or SPF pass align with the visible From domain, tells receivers what to do when nothing aligns, and requests aggregate reports. DKIM proves authenticity; DMARC decides the consequence.
Which comes first: SPF, DKIM, or DMARC?▾
Publish SPF and DKIM first, because DMARC has no effect until at least one of them is in place and aligned. Get both passing and aligned for every legitimate sender, then publish DMARC at p=none to collect reports, and only then ramp the DMARC policy to quarantine and reject.