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 not example.com, so it does not align.
  • DKIM is signed by example.com‘s own key, and passes for example.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:

DKIM authentication results
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.

SPF authentication results
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.com and example.com share the organisational domain example.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