SPF, DKIM and DMARC — how they fit together
Search for SPF DKIM DMARC and you will find the three treated as one checklist item. SPF DKIM DMARC is really three email authentication standards with three different jobs, and people usually meet them as a checklist — publish SPF, publish DKIM, publish DMARC, done. That framing hides the interesting part: they are not three versions of the same idea, and two of them are almost useless without the third. Understanding which question each one answers is what turns a fragile setup into a durable one.
Three different questions
| Standard | The question it answers | What it inspects |
|---|---|---|
| SPF | Was this message delivered by a server I authorised? | The connecting IP address |
| DKIM | Did this message arrive unmodified from a signer holding my key? | A cryptographic signature in the headers |
| DMARC | Do either of those results belong to the domain the reader actually sees? | Alignment, plus what to do about failure |
The SPF vs DKIM question has a short answer — one checks the connecting server, the other checks the message — but it is the wrong question on its own, because neither is decisive without the third. SPF and DKIM are checks. DMARC is a policy that consumes their results. That is the whole architecture, and it is the real difference between SPF, DKIM and DMARC: two of them measure something, the third decides what the measurement means.
Why SPF and DKIM alone do not stop spoofing
Here is the gap that DMARC was invented to close.
SPF validates the envelope-from — the address used during the SMTP conversation, which your recipient never sees. DKIM validates whatever domain the signer put in the signature's d= tag. Neither one is required to have anything to do with the From: header — the name and address displayed in the mail client.
So an attacker can register evil-sender.example, publish a perfectly valid SPF record for it, DKIM-sign their mail with their own key, and put From: [email protected] in the visible header. Both checks pass. Both checks passed for the attacker's domain, which nobody is looking at.
DMARC adds the missing requirement: the passing check must be aligned with the domain in the From header. That single rule is what makes the other two meaningful. It is set out in full in DMARC alignment explained.
The DMARC rule, in one line
A message passes DMARC if aligned SPF passes OR aligned DKIM passes. One is enough. Both failing is what triggers your policy.
The "one is enough" clause is not a technicality — it is the design that makes email authentication survive the real world. Forwarding breaks SPF every time, because the forwarding server is not in your record. When DKIM is aligned, the message still passes DMARC, and the reader never knows there was a question. A domain relying on SPF alone loses that mail the day it enforces. The mechanics are in Why SPF fails on forwarded mail.
What each one cannot do
- SPF cannot survive forwarding, and cannot protect the visible From address. It also cannot be extended indefinitely — see the ten-lookup limit.
- DKIM cannot survive content modification. A mailing list that appends a footer breaks the signature, exactly as a tamper-evident seal should break.
- DMARC cannot authenticate anything by itself. With no SPF and no DKIM there is nothing to align, and every message fails. DMARC is a verdict, not a check.
- None of them inspect the message for malice. They answer "is this really from that domain", not "is this email safe". Authentication is not a spam filter.
The order to deploy them in
The sequence matters, because two of these steps can bounce legitimate mail if taken early.
- Publish SPF listing every server that sends for you — including the ones you forgot. See SPF record syntax.
- Enable DKIM signing at every sending platform, each with its own selector. This is the step people skip, and the one that makes enforcement survivable.
- Publish DMARC at
p=none. Nothing changes for your mail; reports start arriving. - Read the reports for a few weeks. Find the senders you did not know about. Unknown sending sources is usually the most revealing page in the product at this stage.
- Fix alignment, then raise the policy in steps to
quarantineandreject— covered in DMARC policy: none, quarantine, reject.
Step 4 is not optional padding. Going straight to p=reject on a domain whose senders have never been inventoried is the single most common way to lose real mail.
Do I need all three?
Yes, and the reason is asymmetric.
You need DMARC because it is the only one that protects the address your reader sees. You need DKIM because it is the only one that survives forwarding, so it is what keeps mail flowing once DMARC enforces. You need SPF because it is cheap, universally supported, and it covers the cases DKIM misses — most usefully bounce messages and other mail with an empty envelope-from.
A setup with SPF and DMARC but no DKIM technically works, and technically breaks the first time someone forwards your mail to Gmail. Deployments that never make it past p=none are very often stuck for exactly this reason.
Where DMARCmetric fits
None of the three tells you what is happening — DMARC only asks receivers to report back, in a compressed XML format nobody wants to read. Turning those reports into "here are your senders, here is what is failing, here is the one thing to fix next" is the job of the dashboard: Understanding your dashboard.