DMARC Alignment in Depth
A message can pass SPF, pass DKIM, and still fail DMARC. That surprises people the first time they see it — but it’s not a bug, it’s alignment: the extra check DMARC adds on top of SPF and DKIM’s own pass/fail results.
Think of it like matching a boarding pass to an ID
DMARC alignment is like matching the name on a boarding pass to the name on your ID: SPF and DKIM can both come back as technically “valid”, but if the name they validated doesn’t match the name on the email people actually see (the visible “From” address), it still doesn’t count as a match.
Why it matters
SPF and DKIM each authenticate a domain — but not necessarily the same domain a reader actually sees. SPF checks the invisible “envelope” sender used between mail servers; DKIM checks whichever domain applied the cryptographic signature, which is often a sending platform or vendor rather than you. DMARC’s job is to make sure whichever one passed is checking the same domain shown in the message’s visible From address — the one a person actually reads. Without that extra check, SPF or DKIM passing for any domain would be enough, even one that has nothing to do with the message a reader sees.
How it works: a worked example
Say newsletter@marketing-vendor.com sends a campaign on behalf of example.com, and the message’s visible From address reads news@example.com.
- SPF passes for
marketing-vendor.com(the envelope/return-path domain) — but that’s notexample.com, so it does not align. - DKIM is signed by
example.com‘s own key, and passes forexample.com— which matches the visible From domain, so it does align.
Because at least one mechanism (DKIM) both passed and aligned with the visible From domain, this message passes DMARC overall — even though SPF alignment failed. DMARC only needs one of the two to pass and align, not both.
I need more information
The plain-language version and example above cover what most people need day to day. The rest of this article is the detailed reference: exactly how “pass” is defined for each mechanism, and how strict versus relaxed alignment mode changes what counts as a match.
Condition 1: a pass result
DMARC needs at least one of SPF or DKIM to produce a “pass” on its own terms first, before alignment is even considered:
| Result | Meaning |
|---|---|
| None | The message was not signed. |
| Pass | The signature passed verification. |
| Fail | The signature failed verification. |
| Policy | The signature was not acceptable under the receiver’s policy. |
| Neutral | The signature contained syntax errors or could not be processed. |
| TempError | A temporary error prevented verification; a later attempt may succeed. |
| PermError | A permanent error prevented verification; a later attempt is unlikely to help. |
Only “Pass” counts as a DKIM pass for DMARC purposes — every other result above is treated as a fail.
| Result | Meaning |
|---|---|
| None | The domain published no SPF record. |
| Neutral | Treated the same as “None”. |
| Pass | The sending server is authorised to use that domain. |
| Fail | The sending server is not authorised to use that domain. |
| SoftFail | Treated as somewhere between “Fail” and “Neutral”. |
| TempError | A transient error occurred during the check. |
| PermError | The domain’s SPF record could not be correctly interpreted. |
Only “Pass” counts as an SPF pass for DMARC purposes — every other result above is treated as a fail.
Condition 2: identifier alignment
DMARC authenticates the Header.From domain — the domain in the visible “From” field a reader sees, and the field abuse most often targets. It requires that domain to be in alignment with whichever mechanism (SPF or DKIM) produced a pass:
- DKIM aligns when the domain that applied the signature matches the Header.From domain.
- SPF aligns when the envelope/return-path domain matches the Header.From domain.
Alignment can be checked in one of two modes, set per mechanism in your DMARC record (adkim= for DKIM, aspf= for SPF):
- Strict mode (
s) — the Header.From domain and the authenticating domain must match exactly. - Relaxed mode (
r, the default) — the two domains only need to share the same organisational domain. In practice this is the domain’s top-level domain plus one label (for example,mail.example.comandexample.comshare the organisational domainexample.com, so they align under relaxed mode). Use the Public Suffix List’s ICANN-only section to determine the correct top-level domain for this purpose.
Good to know
DMARC alignment is worth re-checking periodically even once you’re already enforcing p=reject. Mail infrastructure changes constantly — a new marketing platform, a changed vendor, a migrated mail server — and any of those can quietly break alignment for a sender that used to pass.
References & further reading
- RFC 7489 – DMARC: datatracker.ietf.org/doc/rfc7489
- RFC 7208 – SPF: rfc-editor.org/rfc/rfc7208
- RFC 6376 – DKIM Signatures: rfc-editor.org/rfc/rfc6376
- RFC 8601 – Message Header Field for Indicating Message Authentication Status: rfc-editor.org/rfc/rfc8601
