DMARC Alignment: Why SPF and DKIM Pass but DMARC Still Fails
You've got 100% SPF pass rates. DKIM is green across the board. And yet your DMARC aggregate report shows a 40% failure rate. Marketing campaigns are bouncing, your vendor's transactional emails land in spam, and the authentication headers make no sense.
The disconnect isn't a bug - it's a DMARC alignment problem, and it's the most misunderstood concept in email authentication.
The numbers tell the story: among the Fortune 500, 93.8% have DMARC published and 62.7% use p=reject. Drop down to the Inc. 5000 and adoption falls to 76.2%, with only 15.2% at p=reject. Globally, 47.7% of domains have valid DMARC records. Alignment - not adoption - is the bottleneck.
Quick Version
DMARC alignment means the domain in your visible
From:header must match the domain authenticated by SPF or DKIM.
- SPF alignment: the
Return-Pathdomain must match theFrom:header domain- DKIM alignment: the
d=tag in the DKIM signature must match theFrom:header domain- DMARC passes if either SPF or DKIM is both authenticated and aligned - you don't need both
Per RFC 7489 Section 3.1, this is "Identifier Alignment." The recommended default: relaxed alignment + subdomain segmentation. Isolate third-party senders on dedicated subdomains, prioritize DKIM alignment over SPF, and monitor aggregate reports before tightening policy.
What Is Identifier Alignment?
Authentication and alignment aren't the same thing. SPF can pass (the sending IP is authorized). DKIM can pass (the cryptographic signature verifies). But DMARC can still fail because neither authenticated domain matches the domain your recipient sees in the From: header.
RFC 7489 Section 3.1 defines this as Identifier Alignment - the spec checks whether the domain authenticated by SPF or DKIM is the same domain, or a subdomain of the same organizational domain, as the RFC5322.From address. In your headers, failure looks like this:
DMARC/ADKIM Fail: Header sender domain does not match DKIM header domain
DMARC/ASPF Fail: SMTP domain does not match header domain
One thing the RFC makes clear: "DMARC does not produce or encourage elevated delivery privilege of authenticated email." Passing DMARC doesn't guarantee inbox placement. It prevents unauthorized senders from using your domain. That's a defensive measure, not a deliverability boost.
How SPF and DKIM Alignment Work
SPF Alignment
SPF alignment compares the Return-Path (envelope-from) against the visible From: header.
Aligned:
Return-Path: bounce@marketing.example.com
From: news@example.com
With relaxed alignment, marketing.example.com and example.com share the same organizational domain - this passes.
Misaligned:
Return-Path: bounce@sendgrid.net
From: news@example.com
SPF passes for sendgrid.net, but the From: domain is example.com. Different organizational domains. DMARC fails on SPF alignment.
The forwarding problem compounds this: when someone forwards your email, the forwarder's server initiates a new SMTP transaction, and SPF checks the forwarder's IP against your SPF record - which fails. SPF alignment is inherently fragile for forwarded mail.
DKIM Alignment
DKIM alignment compares the d= tag in the DKIM-Signature header against the From: domain:
Aligned:
DKIM-Signature: d=example.com; s=selector1; ...
From: sales@example.com
Misaligned:
DKIM-Signature: d=vendor.gappssmtp.com; s=selector1; ...
From: sales@example.com
That second scenario is extremely common. If you haven't configured custom DKIM for Google Workspace, it signs with a gappssmtp.com domain by default. Microsoft does the same with onmicrosoft.com. Both cause misalignment even though DKIM verification passes.
DKIM's advantage over SPF: it survives forwarding, as long as the message body and signed headers aren't modified. This is why we always recommend prioritizing DKIM alignment for third-party senders.
Strict vs. Relaxed Alignment
The aspf and adkim Tags
Your DMARC record controls alignment mode with two tags - aspf for SPF and adkim for DKIM:
v=DMARC1; p=reject; aspf=r; adkim=s; rua=mailto:dmarc@example.com
Strict (=s) |
Relaxed (=r) |
|
|---|---|---|
| Tag value | aspf=s / adkim=s |
aspf=r / adkim=r |
| Matching rule | Exact domain match | Organizational domain match |
mail.example.com vs example.com |
❌ Fails | ✅ Passes |
example.com vs example.com |
✅ Passes | ✅ Passes |
| Default if omitted | No | ✅ Yes |
If you omit both tags, RFC 7489 defaults to relaxed for both.
The Organizational Domain
Relaxed alignment doesn't just compare raw domain strings. It resolves both domains to their "organizational domain" using the Public Suffix List, then compares those. The algorithm: take the domain, find the largest public suffix it contains (like co.uk or com), then keep one label to the left. So abc.service.co.uk resolves to service.co.uk.
Here's the nuance most guides miss: for deeply nested subdomains like support@abc.xyz.example.com, the receiver's DMARC lookup checks _dmarc.abc.xyz.example.com, then falls back directly to _dmarc.example.com - it skips intermediate subtrees entirely. There's no lookup at _dmarc.xyz.example.com. The receiver makes one or two DNS lookups, never more. You can't publish a DMARC record at an intermediate subdomain and expect it to be discovered. Your policy lives at the organizational domain level, with optional overrides at direct subdomains.
When to Use Each Mode
Use relaxed alignment if you send through any third-party ESP, use subdomains for different mail streams, or haven't audited every sending source. This is the right default for the vast majority of organizations.
Use strict alignment if you control every sending system end-to-end and want maximum spoofing protection on your exact domain. Even then, apply it selectively - strict DKIM on the root domain, relaxed SPF everywhere.
Here's the thing: most organizations should never go strict on SPF. Some ESPs can't support it at all. SendGrid uses delegated subdomain patterns for bounce handling - strict SPF alignment isn't possible, full stop. The recommended architecture is subdomain segmentation: put each third-party sender on a dedicated subdomain (marketing.example.com, transactional.example.com) and use relaxed alignment. This contains risk while keeping alignment achievable.
Fixing DMARC alignment keeps spoofed mail out. But if your contact data is bad, your own emails bounce - destroying the sender reputation you just worked to protect. Prospeo's 5-step email verification delivers 98% accuracy, so your outbound stays under 4% bounce rate.
Don't let bad data undo your authentication work.
Why Alignment Fails Even When SPF/DKIM Pass
Third-Party Sender Misalignment
This is the #1 cause we see. A vendor sends email using your From: domain, you add their IPs to your SPF record, maybe even set up their DKIM CNAMEs - and DMARC still fails.
The misconception: "If I include the vendor in SPF, alignment is handled." It isn't. SPF alignment checks the Return-Path domain, which the vendor typically controls. The fix is getting the vendor to DKIM-sign with your domain in the d= tag, not theirs.
One common pitfall: Constant Contact's initial CNAME values are sometimes wrong, and you won't discover the misalignment until you check headers manually. This r/sysadmin thread debugging Constant Contact alignment is a textbook example of the debugging cycle - multiple engineers going back and forth before realizing the DKIM signing domain was the culprit, not SPF.
Forwarding and Mailing Lists
Forwarding breaks SPF alignment because the forwarder initiates a new SMTP connection - the receiving server checks the forwarder's IP against your SPF record and fails. DKIM can survive forwarding, but mailing lists that add footers, rewrite subject lines, or re-encode content will break the DKIM signature.
SRS (Sender Rewriting Scheme) addresses the SPF problem by rewriting the envelope sender to a domain the forwarder controls. It's a practical fix for simple forwarding scenarios. ARC (Authenticated Received Chain) was designed to create a signed chain of custody through intermediaries, but an IETF draft recommends marking ARC (RFC 8617) as Obsolete after a decade-long experiment that never produced an internet-wide reputation system. Treat ARC as diagnostic only.
DNS Misconfigurations
Quick hits that cause silent failures:
- Multiple DMARC TXT records on the same domain - must be exactly one
- Malformed tags - typos in
p=,aspf=, oradkim=values - Misconfigured RUA URIs - if the reporting address domain differs from the DMARC domain, you need an authorization record at the receiving domain
Diagnosing Alignment Failures
Let's say you just turned on p=reject and your Mailchimp campaigns started bouncing. Here's the workflow we use:
- Send a test email to a Gmail or Outlook account from the suspected source
- Open full headers - in Gmail: three dots, then "Show original"
- Check
Authentication-Results- look forspf=pass,dkim=pass, and critically,dmarc=passordmarc=fail - Inspect
Return-Path- does this domain match yourFrom:domain or share the same organizational domain? (If you need a refresher on the envelope sender, see Return-Path.) - Inspect
DKIM-Signature: d=- does the signing domain match yourFrom:domain? (If you're unsure, follow a quick checklist to verify DKIM is working.) - Cross-check with multiple validators - SPF test tools can disagree. We've seen cases where learndmarc.com shows SPF failure while mail-tester.com shows a pass for the same record. (For syntax pitfalls, compare against a known-good SPF record example.)
The core principle: passing authentication without alignment won't satisfy DMARC. If dkim=pass but the d= domain is vendor.com while your From: is example.com, DMARC fails. The fix is always the same - get the signing domain aligned.
DMARCbis Changes in 2026
DMARCbis is expected to be published as a Proposed Standard in early 2026, upgrading DMARC from its current Informational status under RFC 7489. The biggest technical change: the Public Suffix List is being replaced by a DNS Tree Walk algorithm for determining organizational domains.
Several record tags are being removed (pct, rf, ri) and new ones added (np for non-existent subdomain policy, psd for public suffix domains, t for testing). The pct removal is notable - partial deployment via percentage sampling is going away.
What's not changing: forwarding and mailing lists remain unsolved. DMARCbis explicitly discourages p=reject when mailing lists are common recipients of your mail. Understanding how DMARC alignment works today is essential preparation for these protocol updates.
Authentication Is Half the Battle
DMARC alignment protects your domain from spoofing. It doesn't protect your sender reputation from bad data. If 15-30% of your outbound list contains invalid addresses - a common range for B2B lists that haven't been verified recently - those bounces tank your domain reputation regardless of how perfect your authentication stack is.
In our experience, teams that nail DMARC alignment but skip list hygiene end up right back where they started: poor inbox placement and confused about why. Prospeo handles that other half with 98% email accuracy and a 5-step verification process that includes catch-all handling and spam-trap removal, all on a 7-day data refresh cycle. Alignment protects your domain from spoofing. Verified data protects your sender reputation from bounces (and lowering your email bounce rate).
You're segmenting subdomains and tightening DKIM alignment to protect deliverability. Make sure the data feeding those mail streams is just as clean. Prospeo refreshes 300M+ profiles every 7 days - not the 6-week industry average - so you never send to stale addresses.
Your DMARC policy is only as strong as the data behind it.
FAQ
Does DMARC need both SPF and DKIM to align?
No. DMARC passes if either SPF or DKIM is both authenticated and aligned with the From: header domain. Having both provides redundancy since DKIM survives forwarding while SPF doesn't require cryptographic signing. For third-party senders, prioritize DKIM alignment because it's more resilient.
What's the default alignment mode if I don't set aspf or adkim?
Relaxed. Per RFC 7489, omitting these tags defaults to relaxed alignment, meaning subdomains of the organizational domain pass checks automatically. Most domains run on this default, and it's the right choice unless you have a specific reason to go strict.
How does DMARC alignment differ from SPF/DKIM authentication?
SPF and DKIM only verify that a message was authorized or signed by a specific domain - they don't check whether that domain matches the visible From: header. DMARC adds the alignment layer: at least one authenticated domain must match the sender domain the recipient sees. Without it, a phisher could pass SPF using their own domain while spoofing yours in the From: field.
Can I enforce p=reject without fixing alignment first?
You can, but you'll block your own legitimate mail. Start with p=none, review aggregate reports for alignment rates across all sending sources, and only move to p=reject after achieving near-100% alignment. It also helps to verify your outbound list is clean before tightening enforcement - bounces from invalid addresses complicate rollout analysis and make it harder to isolate alignment issues from data quality issues.