DMARC Alignment Explained

The single concept that explains almost every confusing DMARC failure — why a message can pass SPF, pass DKIM, and still be rejected by your own policy.


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 FROM address given during the SMTP conversation, recorded in the Return-Path: header. This is what SPF checks. Bounces go here. Recipients never see it.
  • The DKIM signing domain — the d= value inside the DKIM-Signature header. 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:

text
MAIL FROM: <bounces@phisher.example> <- SPF checks this, and it PASSES From: "Billing" <billing@yourbank.com> <- the victim sees this

SPF 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:

  1. SPF itself must return pass (not neutral, softfail or none).
  2. 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:

text
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.

Forwarding breaks SPF alignment permanentlyWhen a message is forwarded, the forwarding server usually rewrites the envelope sender to its own address so bounces come back to it. SPF then evaluates the forwarder's domain, and SPF alignment is lost no matter how your record is configured. This is not fixable from the sending side — it is why DKIM matters.

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.

text
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 domainAuthenticated domainRelaxedStrict
example.comexample.comPassPass
example.commail.example.comPassFail
news.example.comexample.comPassFail
news.example.commail.example.comPassFail
example.comexample.co.ukFailFail
example.comsendingplatform.comFailFail
The public suffix matters, not the dot countexample.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:

text
# 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.com

Strict 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.

Strict alignment is the classic self-inflicted outageSetting 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 resultSPF alignedDKIM resultDKIM alignedDMARC
passyesfailPass
failpassyesPass
passnopassnoFail
passnononeFail
softfailyesnoneFail

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:

text
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.com

Read 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.

bash
# 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.eml

Where 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=s plus a signature from mail.example.com for a From: example.com message fails, though it would pass in relaxed mode.
  • Two different organizational domains. Sending as example.com while everything authenticates as example.net. No alignment mode can bridge that — the From domain has to change, or that domain has to sign.

How to Fix Misalignment

  1. Identify which side is misaligned. Read Authentication-Results from a real delivered message, or open your aggregate reports — every record states the SPF and DKIM domains next to the From domain.
  2. 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.
  3. Then fix SPF alignment by enabling a custom return path, which moves the envelope sender to something like bounce.example.com.
  4. Leave alignment relaxed unless you have a specific reason not to. Removing aspf=s / adkim=s resolves a surprising share of alignment failures outright.
  5. 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.

Related