DMARC fails when SPF or DKIM pass for the wrong domain. The alignment rules, relaxed vs strict modes, and the ESP configuration that fixes it.
What Alignment Actually Is
DMARC is built on two existing authentication mechanisms SPF and DKIM but it adds a layer that neither of them provides: a check that the authenticated domain matches what the recipient sees.When a recipient gets a message, they see the From header. The From header contains a domain (newsletter@yourbrand.com). DMARC asks: did SPF or DKIM authenticate that domain? Not some other domain that happens to also be valid. The visible domain.This is the entire point of DMARC. SPF and DKIM existed for years before DMARC and were widely deployed, yet phishing remained trivial. The reason: SPF authenticates the envelope sender, not the visible From. DKIM authenticates whatever domain it was signed with, which may or may not match the From. Without alignment, an attacker could spoof your visible From while passing both SPF and DKIM for some other domain entirely.DMARC closes that gap. The visible domain is what matters. SPF or DKIM (or both) must pass for the visible domain, not some adjacent domain.This sounds straightforward. In practice, alignment is where most DMARC implementations break.
The Two Identifiers DMARC Cares About
A DMARC verdict comes from comparing the visible From-domain against two other identifiers in the message:
1. The Return-Path domain (used for SPF alignment)
2. The DKIM signing domain (the d= parameter in the DKIM-Signature header)
If either matches the visible From-domain (under the alignment mode rules below), DMARC passes. Both do not need to match. One is sufficient.
This OR logic is generous on purpose. ESPs and forwarders frequently break SPF alignment in ways that are hard to fix. As long as DKIM alignment holds, DMARC passes. That redundancy is what makes DMARC deployable in real-world infrastructure where some authentication will always be misaligned.
Strict vs. Relaxed Alignment
DMARC supports two alignment modes for each authentication mechanism:
Relaxed (r) - the default. The authenticated domain matches if it is the same organizational domain as the From-domain, including any subdomain.
Examples that pass relaxed alignment for From: newsletter@yourbrand.com:
- DKIM
d=yourbrand.com✓ - DKIM
d=mail.yourbrand.com✓ - DKIM
d=tx.send.yourbrand.com✓
Strict (s) - requires an exact domain match.
Same examples under strict alignment:
- DKIM
d=yourbrand.com✓ (exact match) - DKIM
d=mail.yourbrand.com✗ (subdomain, not exact) - DKIM
d=tx.send.yourbrand.com✗ (different subdomain)
Strict is configured in the DMARC record:
adkim=s requires strict DKIM alignment. aspf=s requires strict SPF alignment. Either or both can be set independently.
When to use strict: Banking, government, and other domains where precise control over signing is operationally feasible and the security model demands it. Strict alignment makes subdomain delegation harder which is the point. If you do not have a specific reason to use strict, do not.
When to use relaxed: Almost everyone else. Relaxed is the default. Relaxed allows the subdomain architecture covered in Sending from Subdomains to work cleanly, and it provides effectively the same protection against external spoofing.
Why "SPF Pass" Is Not Enough
This is the single most common confusion in DMARC troubleshooting. A sender opens an aggregate report, sees spf=pass next to a failed DMARC entry, and concludes that DMARC is broken.
It is not broken. SPF passed for the envelope sender, which is bounces.espprovider.com. The visible From is newsletter@yourbrand.com. The two domains are not aligned. SPF authenticated something, but not the thing DMARC needed authenticated.
Looking at the underlying message:
SPF passed. DKIM passed. DMARC failed. Why?
- SPF authenticated
bounces.espprovider.com. The From-domain isyourbrand.com. No alignment. - DKIM signed with
d=espprovider.com. The From-domain isyourbrand.com. No alignment. - DMARC needed one of those to align with
yourbrand.com. Neither did.
The fix is not "make SPF stricter" or "fix DKIM" both are passing. The fix is to bring at least one of them into alignment with the From-domain.
Fixing SPF Alignment: Custom Return-Path
The Return-Path (also called the envelope sender or MAIL FROM) is what SPF authenticates. By default, ESPs set the Return-Path to a bounce-tracking domain on their own infrastructure. That is what causes the alignment failure.
The fix is a custom Return-Path on your own domain. Most ESPs support this through a feature variously called "custom domain," "verified domain," "branded sending domain," or similar. The mechanism: the ESP delegates a subdomain of yours (typically bounce.yourbrand.com, pm-bounces.yourbrand.com, or similar) and uses that as the Return-Path.
Setup typically requires:
- Add a CNAME record pointing the bounce subdomain to the ESP's tracking infrastructure.
- Verify the configuration via the ESP's domain setup UI.
- Confirm with a test send that the Return-Path now reads
bounce.yourbrand.com(or your chosen name) instead of the ESP's default.
After this is configured, SPF authenticates bounce.yourbrand.com. Under relaxed alignment, that aligns with yourbrand.com. SPF alignment passes. DMARC passes if SPF passes.
The exact CNAME or DNS records vary by ESP. Sending domain setup is a documented feature of every major provider; if your ESP does not offer it, escalate or migrate.
Fixing DKIM Alignment: Domain-Aligned Signing
DKIM alignment is fixed by signing with a key whose d= parameter matches your domain. The signing identity needs to be under your control, not the ESP's.
The mechanism: the ESP generates a key pair, you publish the public key in your DNS under a selector at your domain, and the ESP signs outbound mail with the corresponding private key using d=yourbrand.com (or a subdomain thereof).
Practical setup:
- The ESP gives you a DNS record to publish, typically:
- Publish the record. Verify with
dig. - The ESP detects the published record and switches to signing with
d=yourbrand.com s=esp1. - Confirm with a test send that the DKIM-Signature header now includes
d=yourbrand.com.
After this is configured, DKIM authenticates yourbrand.com directly. Alignment is automatic. DMARC passes regardless of whether SPF aligns.
For senders running subdomain architecture, the same mechanism applies per subdomain. news.yourbrand.com gets its own selector and key:
DKIM signs with d=news.yourbrand.com, aligning with messages sent from newsletter@news.yourbrand.com.
For more on the mechanics of selector management, see DKIM Key Rotation: A Practical Guide for Production Environments.
You Need One, Not Both
This bears repeating because it changes the troubleshooting approach: DMARC passes if either SPF or DKIM aligns. You do not need both.
In practice, DKIM alignment is more reliable than SPF alignment because DKIM survives forwarding while SPF often does not. A message forwarded through a corporate gateway or mailing list will frequently fail SPF (because the forwarder's IP is not in your SPF record) but pass DKIM (because the body and headers were not modified, so the signature still validates).
The recommended setup:
- DKIM alignment as primary. Configure ESP DKIM signing under your domain. This handles forwarded mail correctly.
- SPF alignment as secondary. Configure custom Return-Path. This handles the cases where DKIM fails (rare in well-configured infrastructure).
- Both aligned gives you redundancy. One aligned gives you DMARC compliance.
If you are choosing where to invest configuration effort, fix DKIM alignment first.
How to Diagnose Alignment Failures
DMARC aggregate reports are the diagnostic source. Each report entry shows the result of SPF and DKIM authentication and the final DMARC verdict. Alignment failures look like this in the XML:
1<row>
2 <source_ip>198.51.100.50</source_ip>
3 <count>1247</count>
4 <policy_evaluated>
5 <disposition>none</disposition>
6 <dkim>fail</dkim>
7 <spf>fail</spf>
8 </policy_evaluated>
9</row>
10<auth_results>
11 <dkim>
12 <domain>espprovider.com</domain>
13 <result>pass</result>
14 </dkim>
15 <spf>
16 <domain>bounces.espprovider.com</domain>
17 <result>pass</result>
18 </spf>
19</auth_results>Read this carefully: the underlying authentication results are pass for both SPF and DKIM. The policy evaluation is fail for both. The reason is alignment—the authenticated domains (espprovider.com and bounces.espprovider.com) do not match the From-domain (which is implied to be yourbrand.com based on which DMARC report this is).
This pattern is the signature of an alignment problem. SPF and DKIM are working as designed. They are just authenticating the wrong identity for DMARC's purposes.
A Typical Migration: From "DMARC Pass" to "DMARC Aligned"
A common scenario: a sender publishes DMARC at p=none, sees aggregate reports showing reasonable pass rates, and assumes everything is fine. They move to p=quarantine. Suddenly, marketing campaigns start landing in spam. The aggregate reports they had been ignoring would have told them this was coming.
The actual sequence I have walked customers through:
- Identify alignment failures. Pull aggregate reports for the past 30 days. Filter for entries where SPF or DKIM passed but DMARC failed. That is the alignment-broken volume.
- Identify the source. The IPs and authenticating domains in those entries point to specific ESPs or sending tools. List them.
- Configure alignment per source. For each ESP, set up custom Return-Path (SPF alignment) and domain-keyed DKIM (DKIM alignment). The ESP's documentation walks through this; if not, support tickets are usually quick.
- Verify with test sends. From each source, send a test campaign. Check the headers in Gmail's "Show original" or via mail-tester.com. Confirm
dmarc=passwith alignment. - Monitor reports. After a week, the alignment failures in aggregate reports should drop to near zero. If a source still appears, return to step 3 for that source.
- Move policy to enforcement. Once alignment failures are below 1% of total mail, moving to
p=quarantine(or eventuallyp=reject) is safe.
This sequence typically takes 2-4 weeks of calendar time, mostly waiting for aggregate report cycles. The actual configuration work is hours.
Frequently Asked Questions
Why does DMARC pass for some of my mail and fail for other mail from the same domain?
My DKIM is signing with d=[mydomain.com](http://mydomain.com). Why is DMARC still failing?
Can I have multiple DKIM signatures on a single message?
Does ARC affect DMARC alignment?
What if my ESP only supports SPF alignment, not DKIM signing?
How do I know if my alignment is relaxed or strict?
Is there any case where strict alignment is recommended for typical senders?
Key Takeaways
- DMARC fails not when authentication fails, but when authentication succeeds for the wrong domain. This is alignment.
- DMARC passes if either SPF or DKIM aligns with the visible From-domain. You do not need both.
- DKIM alignment is more reliable than SPF alignment because DKIM survives forwarding. Fix DKIM alignment first.
- Relaxed alignment (the default) accepts subdomains. Strict alignment requires exact matches. Use relaxed unless you have a specific reason not to.
- The fixes are configuration, not reauthentication: custom Return-Path on your domain (SPF) and ESP DKIM signing under your domain (DKIM).
- Alignment failures show up clearly in DMARC aggregate reports. The pattern is spf=pass and dkim=pass at the auth level but fail at the policy level.
- Most senders publish DMARC at p=none, see "passing" aggregate reports, and move to enforcement without checking alignment. The campaign-in-spam moment that follows is preventable.
DMARC without alignment is theater. DMARC with alignment is the protection the standard was designed to deliver. The difference is configuration.
Related articles
DKIM Key Rotation: A Practical Guide for Production Environments
How to rotate DKIM keys in production without breaking signatures. Dual-selector strategy, 2048-bit key sizes, and the rotation cadence that actually works.
One-Click Unsubscribe (RFC 8058): Implementation Pitfalls Most Senders Miss
RFC 8058 one-click unsubscribe is mandatory for bulk senders. The five implementation mistakes that fail compliance and how to test your endpoint properly.
The ARC Header: How Forwarding Breaks DMARC and What You Can Do
Forwarders break DMARC by modifying messages in transit. ARC (RFC 8617) preserves authentication results across hops. How it works, who supports it, and the limits.