Why DMARC fails when SPF passes: alignment explained
SPF checks the envelope sender, which your recipients never see. DMARC asks whether that domain matches the From address they do see.
On this page
SPF authenticates the envelope sender (MAIL FROM), and DKIM authenticates the domain in the signature (d=). DMARC passes only when at least one of them passes for a domain that aligns with the visible From address. A service that sends with its own bounce domain and its own DKIM domain passes SPF and DKIM but fails DMARC. The fix is to have it sign DKIM with your domain or use your domain for its envelope sender.
Three domains in one message
Every message carries up to three domains that can differ:
- From (RFC 5322.From): the address your recipient sees,
[email protected]. - Envelope sender (RFC 5321.MailFrom, also called return-path or bounce address): where bounces go. SPF checks this one.[3]
- DKIM signing domain: the
d=in the DKIM-Signature header, whose key is published atselector._domainkey.domain.[4]
Microsoft’s documentation puts the gap plainly: SPF and DKIM “don’t require the domains in the following email addresses to ‘align’ (match)”.[1] DMARC is what adds that requirement.
What alignment means
DMARC passes if SPF passes *and* its domain aligns with From, or DKIM passes *and* its domain aligns with From. One is enough; it fails only if both fail.[1]
- Relaxed (the default): same organisational domain. RFC 9989: “When the Author Domain has the same Organizational Domain as an Authenticated Identifier, the two are said to be in relaxed alignment.”[2] So
bounces.example.comaligns withexample.com. - Strict (
aspf=soradkim=s): the names must match exactly.
| From | Envelope sender or d= | Relaxed | Strict |
|---|---|---|---|
| [email protected] | example.com | Pass | Pass |
| [email protected] | bounces.example.com | Pass | Fail |
| [email protected] | example.onmicrosoft.com | Fail | Fail |
| [email protected] | mailer-service.example | Fail | Fail |
The classic case
A newsletter or CRM tool sends as [email protected], but uses its own bounce domain and signs with its own domain. SPF passes (for the tool’s domain), DKIM passes (for the tool’s domain), and DMARC fails because neither aligns with example.com. Microsoft’s troubleshooting table lists exactly this: “SPF passes for adatum.com but DMARC fails”, resolved by DKIM signing with your domain or changing the MAIL FROM to your domain or a subdomain.[1]
How to see it
In a received message, the Authentication-Results header shows smtp.mailfrom=, header.d= and header.from=. Compare the first two with the third.[1]
In DMARC aggregate reports, look at the gap between raw results and evaluated results: auth_results/spf/result = pass with policy_evaluated/spf = fail means SPF passed but did not align.[1]
Check your alignment
Upload a DMARC report to see each sender’s SPF and DKIM alignment, or check your domain’s records.
Fixes, best first
- DKIM with your domain at the service. Most services offer “authenticate your domain” or “custom DKIM”: you add CNAME or TXT records, and they sign with
d=example.com. DKIM survives forwarding better than SPF. - A custom envelope sender. Some services let you set a bounce domain such as
bounce.example.com, which aligns under relaxed mode. - A subdomain for the service. Send as
news.example.comwith its own SPF, DKIM and DMARC.
Forwarding and mailing lists
When mail is forwarded, the forwarder’s server sends it on, so SPF for your domain no longer passes; if a mailing list edits the subject or body, DKIM breaks too. ARC (RFC 8617, experimental) lets intermediaries record the authentication results they saw so the final receiver can take them into account.[5] It is the receiver’s choice to trust it, which is another reason DKIM with your own domain is the first fix.
Sources
- Set up DMARC to validate email in Microsoft 365 · Microsoft LearnChecked 5 Oct 2026
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (May 2026) · IETF / RFC EditorChecked 5 Oct 2026
- RFC 7208: Sender Policy Framework (SPF) (Apr 2014) · IETF / RFC EditorChecked 5 Oct 2026
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (Sep 2011) · IETF / RFC EditorChecked 5 Oct 2026
- RFC 8617: The Authenticated Received Chain (ARC) Protocol (Jul 2019, Experimental) · IETF / RFC EditorChecked 5 Oct 2026