DMARC vs SPF: What's the Difference, and Which Do You Need? (2026)
Published · updated
Figures as of 2026-07-28 · methodology v8. Aggregate census data across 276 million graded domains. “Enforcing” means a DMARC policy of
quarantineorreject. See how we grade.
Part of the DMARC pillar — DMARC adoption, maturity and league tables, measured across the whole census.
You need both — SPF first, then DMARC — because they answer different questions. SPF is a list: which servers are allowed to send email for my domain? DMARC is a policy: what should receivers do with a message that fails authentication — and how do I find out it happened? Neither replaces the other. SPF without DMARC leaves your visible “From” address forgeable; DMARC without SPF (or DKIM) has nothing to enforce. The census shows how often the two get confused: as of 2026-07-28, 51.25% of 276 million graded domains publish SPF, but only 11.84% enforce DMARC — a gap of tens of millions of businesses that did step one and believe they’re done.
What SPF actually does
SPF (Sender Policy Framework) is a single DNS TXT record that lists the servers allowed to send mail for your domain — your mailbox provider, your newsletter tool, your CRM. When a mail server receives a message claiming to come from you, it checks whether the server that delivered it is on your list.
Two details matter here, because they define SPF’s limits:
- SPF checks the technical sender, not the visible one. The address SPF validates is the envelope sender (the “Return-Path” — the address bounces go to). It never looks at the “From” line a human reads in their inbox. Those two addresses can be completely different, and in most fraud they are.
- SPF doesn’t say what happens on failure. The record ends with a qualifier (
-allor~all) that suggests how receivers should treat unlisted senders, but there’s no binding instruction and no feedback to you. Of domains with SPF, only 39.2% even use the strict-all; 55.9% use~all, which most receivers deliver anyway.
SPF is necessary plumbing. It is not, on its own, protection — a point the data makes bluntly: 30.9% of all domains publish SPF but have no DMARC at all (the false-security gap, measured).
What DMARC actually does
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and adds the three things they’re missing:
- It protects the address people see. DMARC requires alignment: the domain that passed SPF or DKIM must match the domain in the visible “From” header. This closes the gap SPF leaves open — an attacker can no longer pass SPF on their own infrastructure while displaying your name.
- It tells receivers what to do on failure. Your DMARC record publishes a policy:
p=none(deliver anyway, just report),p=quarantine(spam folder), orp=reject(refuse it). This is the enforcement layer SPF never had. - It reports back to you. Receivers send you aggregate reports showing who is sending as your domain — legitimate and otherwise. It’s the only one of these standards with a feedback loop, and it’s how you tighten the rest safely.
The catch: DMARC only protects at quarantine or reject. A record parked at p=none monitors and does nothing else — p=none is not protection. As of 2026-07-28, 74.19% of domains have no DMARC record, 13.96% sit at monitor-only, and just 11.84% enforce.
SPF vs DMARC, side by side
| SPF | DMARC | |
|---|---|---|
| What it is | A list of servers allowed to send for your domain | A policy for what happens when authentication fails |
| The question it answers | ”Did this come from an approved server?" | "Does the visible sender match who authenticated — and if not, what now?” |
| What it checks | The envelope sender (Return-Path) — invisible to the reader | Alignment between SPF/DKIM and the “From” address people see |
| On failure | Suggests an outcome (-all/~all); receiver decides | Instructs an outcome you chose: none / quarantine / reject |
| Reporting back to you | None | Aggregate reports on everyone sending as your domain |
| Survives forwarding | Often breaks — the forwarder isn’t on your list | Yes, when DKIM alignment holds (signatures travel with the message) |
| Stops visible-From impersonation alone | No | Yes — at quarantine or reject, with SPF/DKIM underneath |
| Adoption (2026-07-28) | 51.25% publish | 11.84% enforce |
The one-line summary: SPF authenticates a path; DMARC protects an identity. Receivers weigh SPF as one signal among many. DMARC at enforcement is a decision.
Why SPF alone fails
Three structural reasons, not implementation bugs:
The From-header gap. SPF never inspects the “From” line. A scammer sends from scammer-domain.com infrastructure with your company in the visible From field: SPF checks their envelope domain against their SPF record, passes cleanly, and the forgery lands looking authentic. Only DMARC’s alignment requirement catches this — which is why email spoofing remains routine against SPF-only domains, and why 88.16% of graded domains can still be impersonated.
Forwarding. When someone auto-forwards your mail (an old address to a new one, a distribution alias), the forwarding server delivers it — and that server isn’t in your SPF record, so SPF fails on entirely legitimate mail. This isn’t misconfiguration; it’s how forwarding works. DKIM signatures survive forwarding, which is why DMARC (passing on either aligned SPF or aligned DKIM) handles it and raw SPF can’t. Details: forwarding breaks SPF.
No consequences, no feedback. Even a perfect SPF record with -all relies on each receiver choosing to act, and tells you nothing about what’s being sent in your name. DMARC turns that into an explicit instruction plus a report.
Which order to deploy
The order matters because DMARC consumes what SPF and DKIM produce. Deploy top-down:
- SPF first. Publish one TXT record listing every legitimate sender, ending
~allwhile you verify,-allonce complete. Fix SPF. - DKIM second. Turn on signing with your mail provider — it’s what keeps authentication intact through forwarding. Fix DKIM.
- DMARC at
p=none, with reporting. Publishv=DMARC1; p=none; rua=mailto:...and actually read the reports — a surprising number of domains publish DMARC blind, with no reporting address at all. Provider steps: Google Workspace · Microsoft 365. - Tighten to
quarantine, thenrejectonce reports show your legitimate mail passing. This step is the protection; everything before it is preparation. The safe progression.
Skipping ahead breaks things in both directions. DMARC-before-SPF/DKIM quarantines your own legitimate mail. SPF-and-stop — the most common end state, 30.9% of all domains — leaves the visible From address open. Only 2.79% of domains complete all the steps.
The honest edge cases
- Mailing lists can break both. Lists that rewrite subjects or add footers invalidate DKIM signatures and fail SPF (the list server sends). Modern lists rewrite the From header to compensate. If your community lives on mailing lists, expect some pain at
reject— it’s manageable, not a reason to stay atnone. - SPF can pass while DMARC fails. Many sending platforms use their domain as the envelope sender, so SPF passes — unaligned with your From domain. That mail needs aligned DKIM (a custom signing domain, which good platforms support) to pass DMARC. If your DMARC fails while SPF and DKIM pass, alignment is almost always why.
- SPF has a 10-lookup limit. Chain too many
include:entries and the record returns a permanent error and is ignored entirely. Consolidate before you tighten DMARC, or you’ll enforce on top of broken SPF. - Domains that never send email need both too — the strictest versions (
v=spf1 -allandp=reject) — otherwise your parked and unused domains are the easiest ones to forge. - DMARC isn’t the end of the road. It stops exact-domain impersonation. Lookalike domains, display-name tricks and compromised genuine mailboxes are different problems — real, but no reason to skip the one attack class you can shut off with three DNS records.
Frequently asked questions
Is DMARC the same as SPF? No. SPF is a list of approved sending servers, checked against an address the reader never sees. DMARC checks that whoever authenticated matches the visible “From” address, applies your chosen policy on failure, and reports back to you.
Do I need DMARC if I already have SPF? Yes. SPF alone doesn’t protect the visible From address — 30.9% of domains have SPF and no DMARC, and they remain forgeable. SPF is a prerequisite for DMARC, not a substitute.
Can I use DMARC without SPF? Technically yes, if DKIM is in place — DMARC passes on either aligned mechanism. In practice you want both underneath: SPF catches what DKIM misses and vice versa (forwarding being the classic case where only DKIM survives).
Which should I set up first?
SPF, then DKIM, then DMARC at p=none with reporting, then enforcement. DMARC needs the first two working before you can safely tighten it.
Does either cost money? No — SPF, DKIM and DMARC are all free DNS records. The investment is care and sequence, not budget. (Reading DMARC reports is easier with a free or paid report viewer, but the protection itself costs nothing.)
Check where your domain stands
Most domains have the list and not the lock. Check yours free and private — you’ll see your SPF, DKIM and DMARC status together, and which step is next.
Check your domain → · Fix SPF → · Fix DMARC → · How we grade → · Aggregate data only. Data stored and processed in the EU.