DMARC alignment is the rule that the domain a recipient sees must match the domain that actually authenticated. SPF and DKIM each prove something about a message, but neither one looks at the From: header — the only address a human ever reads. Alignment is the bridge. It is also the reason for the most common complaint in email authentication: "my message passes SPF, so why does DMARC say dmarc=fail?" The answer is almost always that SPF passed for the wrong domain.
The Three Domains in Every Email
A single message carries at least three separate domain identifiers, and they are allowed to differ from one another. Understanding which is which is the whole of alignment:
- The envelope sender — the
MAIL FROMaddress given during the SMTP conversation, recorded in theReturn-Path:header. This is what SPF checks. Bounces go here. Recipients never see it. - The DKIM signing domain — the
d=value inside theDKIM-Signatureheader. This is the domain whose private key signed the message. Recipients never see it either. - The header From domain — the domain in
From:, displayed in every mail client. This is the identity being protected, and the only one a phisher cares about forging.
DMARC does not add a new authentication mechanism. It adds a comparison: did SPF or DKIM pass for a domain that matches the one in From:? That comparison is alignment.
Why Alignment Has to Exist
Without it, SPF and DKIM are trivially defeated. Consider an attacker who owns phisher.example and publishes a perfectly valid SPF record for it. They send:
MAIL FROM: <bounces@phisher.example> <- SPF checks this, and it PASSES
From: "Billing" <billing@yourbank.com> <- the victim sees thisSPF passes with flying colours, because the attacker really is authorised to send for their own domain. DKIM can pass too, signed with the attacker's own key. Yet the message displays as coming from your bank. SPF and DKIM were never designed to protect the visible sender — they authenticate domains the user cannot see.
DMARC closes this gap by asking the additional question: does the authenticated domain relate to yourbank.com? Here it does not, so DMARC fails and the policy applies. This is the entire security value of DMARC, and it lives entirely in the alignment check.
SPF Alignment
SPF alignment compares the Return-Path domain with the From domain. Two conditions must both hold:
- SPF itself must return
pass(notneutral,softfailornone). - The Return-Path domain must align with the From domain.
This is where third-party senders cause trouble. Many marketing and transactional platforms use their own bounce domain by default:
Return-Path: <bounce-8842@mail.sendingplatform.com> SPF: pass (for sendingplatform.com)
From: <news@example.com> DMARC SPF alignment: FAIL
Return-Path: <bounce-8842@em.example.com> SPF: pass (for em.example.com)
From: <news@example.com> DMARC SPF alignment: PASS (relaxed)The fix for the first case is a custom return path — often called a "custom bounce domain", "dedicated sending domain" or "via removal" in vendor documentation. It moves the envelope sender onto a subdomain you control, which then aligns.
DKIM Alignment
DKIM alignment compares the d= domain in the signature with the From domain. Again, both conditions must hold: the cryptographic verification must succeed, and the signing domain must align.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
From: news@example.com
-> DKIM alignment: PASS
DKIM-Signature: v=1; a=rsa-sha256; d=sendingplatform.com; s=k1; ...
From: news@example.com
-> DKIM alignment: FAIL (signature is valid, but signed by the wrong domain)Note the second case carefully: the signature is cryptographically valid. Nothing is broken. It simply proves that sendingplatform.com sent the message, which says nothing about whether they were entitled to use your From address. DMARC correctly refuses to count it.
DKIM alignment survives forwarding, because the signature travels with the message body and headers. A message that only has aligned SPF will fail DMARC after one hop through a mailing list; a message with aligned DKIM usually still passes. That asymmetry is the practical reason to configure both.
Relaxed vs Strict
Alignment can be evaluated in two modes, set independently for SPF and DKIM.
Relaxed (the default) compares organizational domains. The organizational domain is found by walking up from the public suffix — the entry in the Public Suffix List, such as .com or .co.uk — and taking one label more. Any subdomain therefore aligns with its parent.
Strict requires the two domains to be byte-for-byte identical after normalisation. Subdomains do not align with the parent, and the parent does not align with its subdomains.
| From domain | Authenticated domain | Relaxed | Strict |
|---|---|---|---|
| example.com | example.com | Pass | Pass |
| example.com | mail.example.com | Pass | Fail |
| news.example.com | example.com | Pass | Fail |
| news.example.com | mail.example.com | Pass | Fail |
| example.com | example.co.uk | Fail | Fail |
| example.com | sendingplatform.com | Fail | Fail |
example.co.uk and other.co.uk do not align, even though they share two labels — co.uk is a public suffix, so the organizational domains are example.co.uk and other.co.uk. Alignment is computed against the Public Suffix List, never by counting dots.The aspf and adkim Tags
Alignment mode is controlled by two optional tags in your DMARC record. Both default to r (relaxed) when omitted:
# Relaxed for both — the default, and what almost everyone should use
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
# Explicitly relaxed (identical in behaviour to the record above)
v=DMARC1; p=reject; aspf=r; adkim=r; rua=mailto:dmarc@example.com
# Strict SPF alignment, relaxed DKIM
v=DMARC1; p=reject; aspf=s; rua=mailto:dmarc@example.com
# Strict for both — subdomains no longer align with the parent
v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.comStrict mode is narrower, not stronger in any meaningful security sense. Relaxed already blocks every unrelated domain — an attacker cannot obtain anything.example.com without controlling example.com. Strict only adds value if you specifically distrust your own subdomains, which is rare and usually better handled with the sp= tag.
aspf=s or adkim=s alongside p=reject breaks every legitimate sender that signs or bounces from a subdomain — which is how most ESPs and many self-hosted setups work. If you are not certain you need strict, leave both tags out.One Aligned Pass Is Enough
DMARC evaluates as a logical OR. The message passes if either of these is true:
- SPF passed and the Return-Path domain aligns, or
- DKIM verified and the
d=domain aligns.
Everything else is a DMARC failure. A message with SPF pass but no alignment, plus a valid DKIM signature from an unaligned domain, fails DMARC despite having two green authentication results. This is exactly the combination that produces bewildered support tickets — the headers look full of passes.
| SPF result | SPF aligned | DKIM result | DKIM aligned | DMARC |
|---|---|---|---|---|
| pass | yes | fail | — | Pass |
| fail | — | pass | yes | Pass |
| pass | no | pass | no | Fail |
| pass | no | none | — | Fail |
| softfail | yes | none | — | Fail |
The fifth row is worth a second look: SPF softfail is not pass, so alignment never gets considered. Alignment only rescues a mechanism that already succeeded.
Reading Alignment in Message Headers
Open any received message, view its full source, and find the Authentication-Results header. Receivers report the domain each mechanism evaluated, which is all you need to diagnose alignment by eye:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounce-991@mail.sendingplatform.com
designates 198.51.100.24 as permitted sender)
smtp.mailfrom=bounce-991@mail.sendingplatform.com;
dkim=pass header.i=@sendingplatform.com header.s=k1;
dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.comRead it as three facts. smtp.mailfrom is sendingplatform.com; header.i (the DKIM identity, from d=) is also sendingplatform.com; but header.from is example.com. Neither authenticated domain matches the From domain, so dmarc=fail — and with p=reject, the message is discarded. Both mechanisms passed and the message still died.
# Pull the relevant identifiers out of a saved .eml file
grep -iE '^(Return-Path|From|Authentication-Results|DKIM-Signature)' message.eml
# Or extract just the DKIM signing domain
grep -io 'd=[a-z0-9.-]*' message.emlWhere Alignment Usually Breaks
- An ESP on its own bounce domain. The single most common cause. SPF passes for the vendor, not for you. Configure a custom return path on a subdomain you own.
- DKIM signed with the vendor's key. The signature is valid but
d=is theirs. Publish the vendor's DKIM selector as a CNAME under your own domain so they can sign as you. - Forwarding and mailing lists. SPF alignment is lost at the first hop. Aligned DKIM is what carries the message through; lists that rewrite the From header (a common workaround) sidestep DMARC entirely.
- Strict mode with subdomain senders.
adkim=splus a signature frommail.example.comfor aFrom: example.commessage fails, though it would pass in relaxed mode. - Two different organizational domains. Sending as
example.comwhile everything authenticates asexample.net. No alignment mode can bridge that — the From domain has to change, or that domain has to sign.
How to Fix Misalignment
- Identify which side is misaligned. Read
Authentication-Resultsfrom a real delivered message, or open your aggregate reports — every record states the SPF and DKIM domains next to the From domain. - Prefer fixing DKIM. Aligned DKIM survives forwarding, so it is the more durable of the two. For most platforms this means adding CNAME records for their selectors under your domain and enabling signing as your domain in their dashboard.
- Then fix SPF alignment by enabling a custom return path, which moves the envelope sender to something like
bounce.example.com. - Leave alignment relaxed unless you have a specific reason not to. Removing
aspf=s/adkim=sresolves a surprising share of alignment failures outright. - Confirm before enforcing. Watch aggregate reports until every legitimate source shows an aligned pass, then move the policy up.
You can inspect the current record — including whether aspf and adkim are set — with the DMARC Lookup tool, and build a corrected one with the DMARC Generator.
Frequently Asked Questions
Why does my email pass SPF but fail DMARC?
Because SPF passed for the envelope sender domain, not for your From domain. Check the Return-Path: header — if it points at your provider's bounce domain rather than your own, SPF is authenticating them. Enable a custom return path with your sending platform, or rely on aligned DKIM instead.
Should I use relaxed or strict alignment?
Relaxed, in nearly every case. It is the default, it blocks every unrelated domain just as effectively, and it does not break subdomain-based senders. Strict is only appropriate when you genuinely need to prevent a subdomain from authenticating for the parent domain — and even then, sp= is usually the better control.
Does the DKIM selector affect alignment?
No. Alignment looks only at d=. The selector (s=) determines which public key is fetched from DNS, so a wrong selector causes a verification failure — but that is a DKIM failure, not an alignment failure. A signature can verify perfectly and still be unaligned.
Can a subdomain align with the parent domain?
Under relaxed alignment, yes, in both directions: mail.example.com aligns with example.com and vice versa, because both reduce to the organizational domain example.com. Under strict alignment, neither direction aligns.
Why does alignment break when my email is forwarded?
The forwarding server rewrites the envelope sender to its own address so that bounces return to it, which means SPF now evaluates the forwarder's domain and alignment is lost. Nothing on your side prevents this. A valid, aligned DKIM signature travels with the message and keeps DMARC passing.
Does the display name in the From header matter for alignment?
No. Only the domain part of the From address is compared. A message from "Your Bank" <noreply@phisher.example> is evaluated against phisher.example. Display-name spoofing is a real attack, but DMARC does not address it — the domain is all it sees.