11 June 2026 · 14 min read
Why a message can pass SPF and still fail DMARC
This is the single most confusing thing about DMARC, and it trips up nearly everyone who looks at their first report. You check your SPF record, it is valid. You check your DKIM signature, it verifies. And yet your DMARC checker report shows messages failing DMARC anyway. How can a message pass the underlying checks and still be rejected by the policy that sits on top of them?
The answer is alignment. DMARC does not simply ask "did SPF pass?" or "did DKIM verify?". It asks a stricter question: "did SPF or DKIM pass for the same domain that the human sees in the From header?". A message can have a perfectly valid SPF result and a perfectly valid DKIM signature, but if neither of those results is tied back to the visible From domain, DMARC treats the message as unauthenticated and applies your policy.
Alignment is the glue between the technical authentication layer and the domain a recipient actually reads. Get it right and DMARC protects your brand. Get it wrong and you will quietly fail legitimate mail, or worse, leave a gap that spoofers can drive straight through. This article explains exactly how SPF alignment and DKIM alignment work, what relaxed and strict mode change, and walks through worked examples of messages that pass and messages that fail, so you can read your own reports with confidence.
If you want the short version first: DMARC passes when at least one of SPF or DKIM both passes its own check and aligns with the From domain. One aligned pass is enough. Now let us unpack what that means.
The three domains DMARC cares about
Every email carries more than one domain identifier, and they do not have to match each other. To understand alignment you have to keep three of them separate in your head.
- The From header domain, also called the header-from or RFC5322.From. This is the address your recipient sees in their mail client, for example
newsletter@yourbrand.com. DMARC is anchored entirely to this domain. When we talk about a message "passing DMARC for yourbrand.com", we mean alignment was achieved against this visible domain. - The Return-Path domain, also called the envelope-from, MAIL FROM, or RFC5321.From. This is the bounce address used during the SMTP conversation. Recipients never see it. SPF authenticates this domain, not the From header.
- The DKIM signing domain, the
d=tag inside theDKIM-Signatureheader. This is whatever domain signed the message cryptographically. It can be your domain, your email platform's domain, or a subdomain.
Here is the crux. SPF checks the Return-Path. DKIM checks the d= domain. Neither of those checks looks at the From header at all. DMARC's job is to bridge that gap by comparing the SPF and DKIM domains back against the From header domain. That comparison is alignment.
A useful mental model: SPF and DKIM each authenticate a domain. DMARC insists that the domain they authenticated is the right domain, the one in the From line. If a sender authenticates sendgrid.net but the From line says yourbrand.com, the message is authenticated, just not for the brand it claims to be from. That is precisely the kind of mismatch DMARC exists to catch.
SPF alignment
SPF alignment compares the Return-Path (envelope-from) domain against the From header domain.
When a sending server connects, it announces a MAIL FROM address. The receiving server looks up the SPF record of that envelope domain and checks whether the connecting IP is authorised. That is ordinary SPF, and you can inspect any domain's record with the SPF checker. SPF on its own knows nothing about the From header.
For SPF to align under DMARC, two things must both be true:
- SPF itself returns a
passresult for the envelope-from domain. - The envelope-from domain matches the From header domain, under the alignment mode in force.
A classic failure case makes this concrete. Many email service providers set the Return-Path to their own bounce domain so they can process bounces. So you send a campaign and the headers look like this:
- From:
news@yourbrand.com - Return-Path:
bounces@esp-mail.com
SPF passes, because esp-mail.com lists the sending IP in its record. But the envelope domain esp-mail.com does not match the From domain yourbrand.com. SPF is authenticated but not aligned. As far as DMARC's SPF half is concerned, this message fails. If DKIM does not save it, the whole message fails DMARC.
This is the number one reason people see SPF failing in DMARC reports despite a green SPF result elsewhere. The SPF record is fine. The alignment is missing. The fix is usually to configure a custom Return-Path (sometimes called a custom bounce domain or custom MAIL FROM) on a subdomain of your own domain, for example bounce.yourbrand.com, so the envelope domain aligns with the From domain.
DKIM alignment
DKIM alignment compares the d= signing domain against the From header domain.
DKIM works by signing parts of the message with a private key and publishing the matching public key in DNS. The receiver recomputes the signature using the public key found at the selector and d= domain in the DKIM-Signature header. If the maths checks out, DKIM passes for that d= domain. You can verify a domain's published DKIM keys with the DKIM checker.
For DKIM to align under DMARC, again two things must both be true:
- The DKIM signature verifies (passes) for some
d=domain. - That
d=domain matches the From header domain, under the alignment mode in force.
Take the same campaign. Your email platform signs the message but uses its own signing domain by default:
- From:
news@yourbrand.com - DKIM
d=:esp-mail.com
The signature verifies perfectly. DKIM passes. But it passes for esp-mail.com, not yourbrand.com, so it does not align. DKIM is authenticated but not aligned, exactly the same trap as SPF.
The fix for DKIM is to set up a signature that uses your domain in d=. With most platforms this means adding a couple of CNAME records (so-called branded or authenticated DKIM) so that the message is signed with d=yourbrand.com. Once the d= domain matches the From domain, DKIM aligns and DMARC can pass on the DKIM side alone.
One important property: DKIM alignment survives forwarding far better than SPF. When a message is forwarded, the forwarding server's IP usually breaks SPF because that IP is not in your record. But the DKIM signature travels with the message body and headers, so as long as the forwarder does not mangle the signed content, DKIM still verifies and still aligns. This is why DKIM is the more robust of the two for DMARC, and why you should always aim to get aligned DKIM working rather than relying on SPF alone.
Relaxed versus strict alignment
DMARC does not force the domains to be identical. By default it allows a parent and subdomain relationship to count as aligned. This is controlled by two tags in your DMARC record:
aspfcontrols SPF alignment mode.adkimcontrols DKIM alignment mode.
Each can be set to r for relaxed (the default if you do not specify it) or s for strict.
Relaxed alignment
Under relaxed alignment, the two domains align if they share the same organisational domain, also called the registered domain. The organisational domain is the registrable part: yourbrand.com, not mail.yourbrand.com or eu.send.yourbrand.com. Relaxed mode ignores subdomain differences and only compares the bit you actually registered.
So with relaxed alignment, all of these align with a From domain of yourbrand.com:
yourbrand.com(exact match)mail.yourbrand.com(subdomain)bounce.eu.yourbrand.com(deeper subdomain)
But yourbrand.co.uk does not align with yourbrand.com, because they are different organisational domains. Nor does yourbrand-mail.com, despite the lookalike name.
Relaxed is the right default for almost everyone. It lets you put your Return-Path on bounce.yourbrand.com and your DKIM on mail.yourbrand.com while still aligning with a From address at the root yourbrand.com. Real-world mail sending almost always involves subdomains somewhere in the chain, and relaxed mode accommodates that without weakening the protection that matters.
Strict alignment
Under strict alignment, the domains must match exactly, character for character. A subdomain no longer counts.
With adkim=s, a From domain of yourbrand.com will only align with a DKIM d=yourbrand.com. A signature with d=mail.yourbrand.com fails to align even though it is your own subdomain. The same applies to aspf=s for the Return-Path.
Strict mode is useful when you have tight control over your sending and want to prevent any subdomain from being treated as equivalent to the parent. It is more brittle, though. A single platform that signs with a subdomain, or a Return-Path on a bounce subdomain, will fail alignment under strict mode that would have passed under relaxed. Unless you have a specific reason, leave both modes relaxed. When you build your record with the DMARC generator, it defaults to relaxed for exactly this reason.
The DMARC pass rule, stated precisely
Putting it together, a message passes DMARC if and only if:
SPF passes AND is aligned, OR DKIM passes AND is aligned.
It is an OR, not an AND. You only need one of the two mechanisms to both pass and align. This is the single most important sentence to internalise. A message can have broken SPF entirely, and still pass DMARC on the strength of an aligned DKIM signature. Equally it can have a failed DKIM signature and still pass on aligned SPF.
That OR is what makes a robust DMARC deployment achievable. You do not need every message to pass both. You need every legitimate stream to pass at least one, reliably. In practice the goal is usually aligned DKIM everywhere, with aligned SPF as a bonus, because DKIM survives forwarding and intermediaries.
Worked example 1: passes DMARC on DKIM alone
A marketing email sent through a properly configured platform.
- From:
news@yourbrand.com - Return-Path:
bounces@esp-mail.com - SPF: pass for
esp-mail.com - DKIM: pass for
d=yourbrand.com(branded signing configured) - DMARC record:
v=DMARC1; p=reject; adkim=r; aspf=r
Walk it through.
- SPF side: SPF passes, but for
esp-mail.com. The From domain isyourbrand.com. Under relaxedaspf=r, the organisational domainsesp-mail.comandyourbrand.comdiffer. SPF is not aligned. SPF half fails. - DKIM side: DKIM passes for
d=yourbrand.com. The From domain isyourbrand.com. Exact match, aligned under any mode. DKIM is aligned. DKIM half passes. - DMARC result: one aligned pass is enough. DMARC passes. Despite SPF being unaligned, the message is fully protected because DKIM carries it.
This is the target state for third-party senders: get the platform to sign with your domain, and SPF alignment becomes a nice-to-have rather than a hard dependency.
Worked example 2: passes DMARC on SPF alone
Transactional mail from your own server, no DKIM configured yet.
- From:
receipts@yourbrand.com - Return-Path:
receipts@yourbrand.com - SPF: pass for
yourbrand.com - DKIM: no valid signature
- DMARC record:
v=DMARC1; p=reject; aspf=r
Walk it through.
- SPF side: SPF passes for
yourbrand.com, and the From domain isyourbrand.com. Exact match, aligned. SPF half passes. - DKIM side: no signature to verify. DKIM half fails.
- DMARC result: SPF is aligned and passing, so DMARC passes. You should still add aligned DKIM, because this message would fail the moment it is forwarded (the forwarder's IP breaks SPF and there is no DKIM to fall back on), but right now it passes.
Worked example 3: fails DMARC despite SPF and DKIM both passing
This is the heartbreaker, and the exact scenario this article opened with.
- From:
news@yourbrand.com - Return-Path:
bounces@esp-mail.com - SPF: pass for
esp-mail.com - DKIM: pass for
d=esp-mail.com(default platform signing, not branded) - DMARC record:
v=DMARC1; p=reject; adkim=r; aspf=r
Walk it through.
- SPF side: passes for
esp-mail.com, From isyourbrand.com, different organisational domains under relaxed. Not aligned. - DKIM side: passes for
d=esp-mail.com, From isyourbrand.com, different organisational domains. Not aligned. - DMARC result: both checks passed their own authentication, but neither aligned with the From domain. Zero aligned passes. DMARC fails, and with
p=rejectthe message is rejected.
Everything was technically valid. SPF green. DKIM green. And the message was still rejected, because both were authenticating esp-mail.com while claiming to be from yourbrand.com. The fix is entirely about alignment: configure a custom Return-Path on a yourbrand.com subdomain (to align SPF) and branded DKIM signing with d=yourbrand.com (to align DKIM). Either one alone would have rescued this message.
Worked example 4: strict mode breaks an otherwise fine message
Same well-configured mail, but with strict DKIM alignment turned on.
- From:
news@yourbrand.com - DKIM: pass for
d=mail.yourbrand.com - DMARC record:
v=DMARC1; p=reject; adkim=s
Walk it through.
- DKIM side: passes for
d=mail.yourbrand.com. From isyourbrand.com. Under strictadkim=s, the domains must be identical.mail.yourbrand.comis not identical toyourbrand.com. Not aligned under strict. (Under relaxed it would have aligned, because they share the organisational domainyourbrand.com.) - DMARC result: if SPF does not align either, DMARC fails, purely because of the strict setting. Switching
adkimback torwould make this message pass. This is exactly why strict mode catches people out, and why relaxed is the sane default.
Worked example 5: subdomain From with relaxed alignment
Mail sent from a subdomain address, which is common for departmental or regional sending.
- From:
alerts@notify.yourbrand.com - Return-Path:
bounces@notify.yourbrand.com - SPF: pass for
notify.yourbrand.com - DMARC record on the organisational domain:
v=DMARC1; p=reject; aspf=r; sp=reject
Walk it through.
- Policy lookup: there is no DMARC record published at
notify.yourbrand.com, so receivers fall back to the organisational domain's record and apply the subdomain policysp=reject. - SPF side: SPF passes for
notify.yourbrand.com, and the From domain is alsonotify.yourbrand.com. Exact match. Aligned. SPF half passes. - DMARC result: DMARC passes, and the subdomain policy governs what would happen on failure. Note that alignment here is evaluated against the From domain
notify.yourbrand.com, not the organisational domain. The From header is always the anchor.
How to read alignment in your DMARC reports
Aggregate DMARC reports (the XML files generated by the rua= address in your record) spell alignment out for every sending source. For each row you get the From domain, the SPF result with its envelope domain, the DKIM result with its d= domain, and crucially the disposition and the alignment outcome for each mechanism. Reading raw XML by hand is grim, so paste reports into the DMARC report analyzer, which decodes them into readable rows.
When you investigate a failing source, ask the two alignment questions in order:
- Did SPF pass, and does the envelope domain share your organisational domain (relaxed) or match exactly (strict)? If passing but unaligned, you need a custom Return-Path.
- Did DKIM pass, and does the
d=domain share your organisational domain or match exactly? If passing but unaligned, you need branded DKIM signing with your domain ind=.
If both answers are "passed but unaligned", you have found a legitimate sender that DMARC is failing, and you must fix alignment before you tighten your policy. Moving to p=reject while a real mail stream is unaligned will reject that mail. This is the whole reason DMARC rollout is staged: start at p=none, watch reports, fix alignment for every legitimate source, then tighten. You can read the wider rollout path on the DMARC product page and check current published records any time with the DMARC checker.
Common alignment mistakes and their fixes
- Relying on SPF alignment alone. It breaks on forwarding and on any platform that uses its own bounce domain. Always pursue aligned DKIM as the durable mechanism. See the DKIM product page for the signing setup.
- Default platform DKIM with
d=set to the vendor's domain. Verifies but never aligns. Switch on branded or authenticated DKIM sod=is your domain. - No custom Return-Path. The envelope sits on the vendor's bounce domain, so SPF is unaligned. Configure a bounce subdomain on your own domain. The SPF product page covers this.
- Strict mode without a reason.
adkim=soraspf=swill reject mail signed or bounced from your own subdomains. Use relaxed unless you have a precise need. - Forgetting the subdomain policy. If you send from subdomains, set
sp=deliberately, because the organisational record governs subdomains that have no record of their own. The requirements guide covers what large mailbox providers now expect. - Confusing a valid SPF or DKIM result with a DMARC pass. They are different questions. Valid authentication for the wrong domain is still a DMARC failure.
The takeaway
DMARC alignment is not an extra hurdle bolted onto SPF and DKIM. It is the entire point. SPF and DKIM prove that some domain authorised a message. Alignment proves that the authorised domain is the one your recipient actually sees in the From line. Without alignment, a spoofer could authenticate their own throwaway domain and still slap your brand in the From header. Alignment is what closes that door.
The rules are simple once they click. SPF aligns when the envelope-from shares the From domain. DKIM aligns when the d= domain shares the From domain. Relaxed mode counts subdomains as a match; strict mode demands an exact match. And a message passes DMARC the moment either mechanism both passes and aligns. Aim for aligned DKIM on every stream, add aligned SPF where you can, keep both modes relaxed unless you have a real reason not to, and never tighten your policy until every legitimate source is aligned.
If you want to see where you stand right now, run your domain through the free DMARC checker and feed a few real reports into the DMARC report analyzer to spot any source that is passing authentication but failing alignment. And if you would rather not chase Return-Paths and d= domains across every vendor yourself, our done-for-you DMARC service configures aligned SPF and DKIM for each of your senders and takes your domain safely from p=none to p=reject with no mail outage, with emailed monitoring that alerts you the moment a new unaligned source appears. Browse the full free tool set or the glossary if a term here needs unpacking.