Why DMARC Fails When SPF and DKIM Pass: Alignment Explained
This is the question I get more than any other, and the answer is a single word: alignment. SPF passed. DKIM passed. DMARC failed anyway. Nothing is broken — DMARC is simply asking a different question than you think it is.
DMARC is not a third check
SPF and DKIM each answer a narrow question, and each answers it about a domain of its own choosing. DMARC does not re-run either test. It reads the results and asks one additional question: did either of those checks pass for the same domain the recipient can see in the From header?
That is the whole protocol. A message can carry a perfect SPF pass and a cryptographically valid DKIM signature and still fail DMARC, because both belong to somebody else's domain.
Three domains live in every message
Every message you send has at least three domains in it, and recipients only ever see one:
- The From domain. What appears in the mail client. The only one a human ever reads, and the only one DMARC cares about protecting.
- The Return-Path domain (envelope sender). Where bounces go. SPF is checked against this, and your sending platform frequently sets it to a domain of its own.
- The DKIM signing domain — the
d=value inside the signature header. Whoever generated the key owns this.
When all three are your domain, DMARC passes comfortably. When the platform supplies the second and third, you get two passes and a DMARC failure.
Where SPF actually gets checked
SPF validates the envelope sender, not the visible one. If a platform sends on your behalf using bounce.theirplatform.com as the Return-Path, the receiver looks up their SPF record, finds the sending IP listed, and returns a pass. Correctly. That pass has nothing to do with your domain, so it cannot satisfy DMARC alignment.
This is why an SPF checker reporting a healthy record tells you less than it appears to. The record can be flawless and still never produce an aligned pass on the mail you actually send. Check yours with the SPF checker, but read the result as one input rather than a verdict.
Where DKIM actually gets checked
DKIM validates against the d= tag in the signature. If the platform signs with its own key, d= is the platform's domain and alignment fails for the same reason. If you published the keys the platform generated under your own domain, d= becomes yours and DMARC is satisfied.
Confirm which domain is signing with the DKIM checker, or open the raw headers of a message you have sent and read the d= value directly.
Relaxed and strict alignment
DMARC has two alignment modes, set by adkim for DKIM and aspf for SPF. Both default to relaxed, which is what you want.
- Relaxed (
r) — the organizational domain has to match. A signature frommail.yourdomain.comaligns with a From address atyourdomain.com. - Strict (
s) — the domains must match exactly. That same subdomain signature now fails.
If someone has set adkim=s; aspf=s on a domain that sends through any third party, that alone can be the cause. Strict alignment buys almost nothing in practice and breaks a great deal. Leave both relaxed unless you have a specific reason.
The two fixes — and you only need one
DMARC passes if either mechanism aligns. So there are exactly two levers:
d= reads your domain, DMARC aligns on DKIM. This is the better fix, because DKIM also survives forwarding.Setup instructions live with the provider: Google Workspace DKIM and Microsoft 365 DKIM. Do the first if you can only do one. Do both if the provider supports both — it gives you a second aligned mechanism when the first breaks.
The case where it fails and it is not your fault
Forwarding. When a recipient forwards your message, or a mailing list redistributes it, the message arrives at the next server from an IP you never authorised. SPF fails, unavoidably. If a gateway or list also rewrites the body or appends a disclaimer, the DKIM body hash breaks too and the signature fails with it.
Nothing in your DNS prevents this, and it is the main reason to read aggregate reports before tightening a policy — a chunk of what looks like failure in your reports is legitimate mail taking an indirect route. Google's own guidance acknowledges this by not requiring alignment on forwarded or mailing-list messages.
Diagnosing it in five minutes
Authentication-Results line. Note spf=, dkim= and dmarc=, and — critically — the domain listed beside each.d= domain in DKIM-Signature and the SPF domain against your From domain. Any mismatch is your answer.Full authentication setup across a sending fleet: SPF, DKIM and DMARC for cold email. What it costs you when this is wrong: why cold emails go to spam.
Sources
- Google — Email sender guidelines FAQ: only one of SPF or DKIM needs to align
- Google Workspace — Turn on DKIM signing
- Microsoft Learn — Configure DKIM for Microsoft 365
- Microsoft Learn — Configure DMARC
- RFC 9989 — DMARC alignment rules
- RFC 7208 — SPF, including the Return-Path identity
Check a real message
Paste the headers of a failing message into the DMARC alignment checker: it fetches the domain's actual adkim and aspf tags and shows which identifier aligned and which did not. If the message was forwarded, the ARC checker shows whether a trusted chain carried the original verdict.
Tools for this
SPF checkerValidate a record and see who it authorises.DKIM checkerFind signing keys without the selector.Header analyzerTrace hops and read the real verdicts.DMARC checkerSee whether your policy enforces anything.Frequently asked questions
Why does DMARC fail when SPF and DKIM both pass?
Because DMARC checks alignment, not authentication. SPF is validated against the Return-Path domain and DKIM against the d= signing domain — if your sending platform supplies both, each check passes for the platform's domain while your visible From domain remains unauthenticated. DMARC needs one of them to pass for the From domain specifically.
What is DMARC alignment in plain terms?
It means the domain that passed authentication is the same domain the recipient sees. Relaxed alignment, the default, accepts a match at the organizational domain level, so a signature from a subdomain still aligns with a root-domain From address. Strict alignment demands an exact match and breaks most third-party sending.
Do I need both SPF and DKIM to align?
No — one aligned pass satisfies DMARC, and Google's sender guidelines confirm only one is required. Aligning both is still worth doing, because SPF breaks on forwarding while DKIM survives it, so having only one aligned mechanism leaves you exposed the moment mail takes an indirect route.
How do I fix a DMARC alignment failure?
Two options and either works alone. Publish your sending provider's DKIM keys in your own DNS so the d= tag reads your domain, or configure a custom Return-Path — normally a CNAME from the provider — so SPF is evaluated against your domain. Publishing DKIM is the better single fix because it also survives forwarding.
Can forwarding cause DMARC to fail?
Yes, and it is usually not fixable from your side. A forwarded message arrives from the forwarder's IP, so SPF fails; if a mailing list or gateway also modifies the body, the DKIM body hash breaks and the signature fails too. Expect some of this in aggregate reports and do not mistake it for a configuration fault.