Why does DMARC authentication fail when SPF and DKIM pass, and how can it be fixed?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2025
Updated 19 May 2026
11 min read
DMARC fails when SPF and DKIM pass because DMARC does not only ask whether SPF or DKIM passed. It asks whether at least one of those passing results aligns with the visible From domain. If SPF passes for a bounce domain, DKIM passes for a vendor domain, and the message From header uses a different domain, DMARC still fails.
The fix is to make either SPF or DKIM pass with alignment to the domain in the From header. In most real cases, I fix this by getting DKIM alignment right first, then using SPF alignment as a secondary path when the sending service supports it cleanly.
Fast answer: A message can show SPF pass and DKIM pass, but DMARC fail, when both passing domains are different from the visible From domain.
Best fix: Sign mail with DKIM using the same organizational domain as the From header, or configure the envelope sender so SPF aligns.
Common trigger: Forwarding, SRS rewriting, on-behalf-of sending, subdomain policies, and shared vendor sending setups create mismatched authentication domains.
The direct reason DMARC fails
DMARC evaluates the domain in the visible From header. That is the domain a recipient sees in their mail client. A raw SPF pass or DKIM pass is not enough. The pass must belong to a domain that aligns with that visible From domain.
For relaxed alignment, which is the default, the organizational domain must match. A message From email.example.com can match DKIM d=example.com. For strict alignment, the domains must match exactly unless the receiver applies local handling. That difference matters when subdomains send through multiple systems.
The rule to remember
DMARC passes when SPF passes with alignment, or DKIM passes with alignment. It fails when SPF and DKIM pass for domains that do not match the visible From domain.
This is why a header can look contradictory at first glance. The header says SPF passed. It also says DKIM passed. Then DMARC says fail. There is no contradiction if SPF authenticated one domain, DKIM authenticated another domain, and neither is the policy domain DMARC is checking.
DMARC alignment compares the visible From domain with SPF and DKIM domains before making a pass or fail decision.
What passing SPF really means
SPF authenticates the envelope sender domain, not the visible From domain. In headers, that domain often appears as smtp.mailfrom or the Return-Path domain. That domain is used for bounce handling. It can be a vendor domain, a forwarding domain, or an SRS rewritten domain.
A forwarded message is the classic example. The forwarder receives a valid message, rewrites the envelope sender with SRS, and sends it onward. SPF passes for the forwarder because the forwarder's IP is authorized by the forwarder's SPF record. DMARC still fails if that SPF domain does not match the original visible From domain.
Header pattern where SPF passes but does not help DMARCtext
In that pattern, SPF passes for forwarder.example. The visible From domain is news.brand.example. Those domains do not match, so SPF does not satisfy DMARC.
SPF pass: The connecting IP was allowed by the envelope sender domain's SPF record.
SPF alignment: The envelope sender domain matches the visible From domain at the required alignment level.
DMARC result: SPF only helps DMARC when both SPF pass and SPF alignment are true.
What passing DKIM really means
DKIM authenticates a cryptographic signature. The domain DMARC cares about is the DKIM d= domain, not the selector and not the domain in the return path. A message can carry multiple DKIM signatures. One can pass for a forwarding service, one can pass for a sending platform, and neither can match the visible From domain.
When I troubleshoot this, I look for a DKIM result like dkim=pass and then immediately check header.i or d=. If that authenticated identity belongs to a vendor or forwarder, the pass is technically valid but useless for DMARC alignment.
DKIM passes
Signature: The message body and signed headers match the DKIM signature.
Domain: The signing domain can be a vendor, platform, forwarder, or brand domain.
Limit: A valid signature does not automatically satisfy the brand's DMARC policy.
DKIM aligns
Identity: The DKIM signing domain matches the visible From domain.
Default: Relaxed alignment accepts the same organizational domain.
Outcome: A passing aligned DKIM signature is enough for DMARC to pass.
DKIM alignment is usually the most dependable fix because it survives forwarding better than SPF. A forwarder can change the envelope sender and break SPF alignment, but a DKIM signature continues to pass if the message content and signed headers are not modified.
A real-world header pattern
The header pattern behind this problem usually has several domains involved. One domain appears in the visible From address. Another appears in the SPF envelope sender. One or more domains appear in DKIM signatures. DMARC then checks whether any passing SPF or DKIM domain aligns with the visible From domain.
Header item
Example
What it means
Visible From
brand.test
The DMARC policy domain.
SPF
fwd.test
SPF passed for another domain.
DKIM 1
vendor.test
A platform signature passed.
DKIM 2
relay.test
A relay signature passed.
DMARC
fail
No passing domain aligned.
The exact names vary, but this is the structure I look for.
A strict subdomain policy can make this more obvious. If the organizational domain publishes sp=reject, then unauthenticated or misaligned subdomain mail gets the same strict treatment. That is correct behavior, but it exposes sloppy sender configuration quickly.
Do not relax policy first
Changing p=reject or sp=reject can stop rejection, but it does not fix authentication. First prove which domain failed alignment, then decide whether policy staging is needed.
How to fix it
The practical fix is to choose the domain that should represent the sender, then configure at least one authentication path to match it. For most marketing, product, and transactional mail, I want DKIM aligned because it is more stable through forwarding and less dependent on the final connecting IP.
Confirm: Read the visible From domain and identify the exact DMARC policy being applied.
Compare: Check whether the SPF envelope sender domain aligns with the From domain.
Inspect: Check every passing DKIM signature and compare each signing domain with the From domain.
Configure: Set up custom DKIM for the sending service using the same organizational domain.
Validate: Send a fresh test message and confirm DMARC passes on the receiver's final Authentication-Results header.
If the domain is already at reject, do not assume the policy is wrong. A reject policy is often doing exactly what it should. The problem is usually that a sender was added without custom DKIM, a forwarding path rewrote the envelope sender, or a subdomain was used without a matching authentication setup.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
For a focused DNS check, use the DMARC checker to confirm the record syntax and policy tags before changing sender configuration.
When forwarding causes the failure
Forwarding creates a confusing version of this issue because the forwarded message can carry both old and new authentication signals. SPF usually becomes about the forwarder. DKIM can remain about the original sender, but only if the forwarder does not modify signed content. ARC can help receivers evaluate the earlier authentication state, but it does not turn a misaligned message into an aligned one by itself.
A forwarding path where SPF changes, DKIM survives, and DMARC checks alignment at the final receiver.
If you control the original sender, the best fix is still aligned DKIM. If you control the forwarder, preserve DKIM signatures by avoiding subject tagging, footer injection, and content rewriting. If you control neither side, the receiver's local ARC handling and spam filtering decide the final outcome.
For deeper examples, the most useful next step is forwarded email analysis, because the apparent sender and the technical sender often diverge after forwarding.
When subdomain policy is the issue
Subdomain policy is another common reason the failure feels surprising. A parent domain can publish sp=reject, which tells receivers to apply reject to subdomains unless those subdomains publish their own DMARC records. If a sender uses a subdomain in the From address and does not have aligned SPF or DKIM, DMARC fails under that subdomain policy.
Policy-first reaction
Change: Remove strict subdomain enforcement to stop immediate rejection.
Risk: Misconfigured or spoofed subdomain mail gets less protection.
Use case: Temporary staging while a known sender is being fixed.
Alignment-first fix
Change: Configure aligned DKIM or SPF for the subdomain sender.
Benefit: Legitimate mail passes while spoofed mail remains protected.
Use case: Long-term production setup for brand and subdomain mail.
A temporary subdomain DMARC record can be reasonable while you stage a fix. For example, a specific sending subdomain can publish monitoring mode while the parent remains protected. I treat that as a short-lived exception with a clear owner, not as the final state.
Temporary subdomain monitoring recorddns
_dmarc.email.example.com. 3600 IN TXT (
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
)
How I read the headers
When a failure report or raw message looks inconsistent, I reduce it to four questions. I do not start by changing DNS. I first identify which authenticated identity DMARC used, which domains passed, and which one should have aligned.
Question
Look for
Fix
From?
header.from
Confirm policy domain.
SPF?
mailfrom
Use aligned bounce domain.
DKIM?
header.i
Use aligned signing domain.
Policy?
p / sp
Stage only if needed.
Use this compact checklist before editing DNS.
Suped's product is useful here because the platform groups the same failure pattern across reports instead of making you inspect one XML file at a time. In DMARC monitoring, the concrete workflow is to find the failing source, check whether SPF or DKIM passed, then open the issue detail to see the alignment problem and the specific DNS or sender-side fix.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
That matters when a team has several senders, agencies, and product systems using the same domain. Suped's issue detection, real-time alerts, Hosted DMARC, Hosted SPF, SPF flattening, and blocklist monitoring keep the authentication work in one place. The practical advantage is fewer ambiguous failures and faster ownership of each fix.
DMARC record changes that help
Record changes help when they make policy behavior explicit or reduce operational mistakes. They do not replace sender configuration. If SPF and DKIM pass for unrelated domains, no DMARC tag can magically make them match.
Use relaxed alignment: Keep adkim=r and aspf=r unless there is a clear security reason for strict alignment.
Add reporting: Use rua so aggregate reports show which source and domain combination is failing.
Stage policy: Use pct only when moving toward enforcement, not as a substitute for fixing alignment.
Separate subdomains: Publish a subdomain DMARC record when one subdomain needs a different rollout path.
Production DMARC record after senders are aligneddns
When building a new record, a DMARC record generator is useful for producing a valid TXT record, but the sender-side alignment still has to be configured in each mail platform.
Policy readiness by aligned volume
Use aligned authenticated volume as the signal for policy movement.
Monitor
0-89%
Unknown senders or repeated alignment failures.
Quarantine staging
90-98%
Most legitimate sources are aligned.
Reject ready
99-100%
All known legitimate sources are aligned.
Where teams get stuck
The hard part is rarely the DMARC record itself. It is the inventory of legitimate senders and the hidden domain choices each sender makes. A CRM, billing system, support desk, newsletter platform, and product mailer can all send as the same brand while authenticating different technical domains.
Best practical order
Inventory: List every service that sends mail using the domain.
DKIM: Enable custom DKIM for every sender that supports it.
SPF: Align bounce domains only where the sender supports custom return paths.
Policy: Move toward quarantine and reject after reports show legitimate mail passing.
If you need a broad check across DMARC, SPF, and DKIM, the domain health checker gives a quick read before digging into mail headers and aggregate reports.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Views from the trenches
Best practices
Check the visible From domain before trusting any SPF or DKIM pass result in headers.
Prefer aligned DKIM for sender setup because it survives forwarding more reliably.
Use subdomain policy staging only with a named owner and a fixed review deadline.
Common pitfalls
Teams often treat any SPF pass as DMARC success, even when the bounce domain differs.
Multiple DKIM signatures can hide the fact that no signature aligns with the From domain.
Removing sp=reject can mask a sender problem instead of fixing the authentication path.
Expert tips
Read Authentication-Results from the final receiver, not only ARC or earlier relay results.
Map every sending source to its DKIM d= domain and envelope sender domain before policy changes.
Keep policy exceptions narrow so temporary DMARC staging does not become permanent.
Marketer from Email Geeks says DMARC can fail even when the header shows SPF and DKIM pass, because the passing domains can belong to relays or vendors instead of the From domain.
2018-05-24 - Email Geeks
Marketer from Email Geeks says forwarded mail should be checked against the final receiver's Authentication-Results header, since ARC results can describe an earlier authentication state.
2018-05-24 - Email Geeks
The fix in plain terms
DMARC fails in this scenario because SPF and DKIM pass for the wrong domains. The receiver is enforcing the visible From domain's policy, and neither passing authentication result proves that domain authorized the message.
The clean fix is aligned DKIM for every legitimate sender, aligned SPF where custom return paths are available, and reporting that shows which source still fails. Relaxing policy can be useful during a controlled rollout, but it should not be the primary fix when a sender simply needs proper DKIM or return-path configuration.
Suped's product is the best overall DMARC platform for most teams handling this workflow because it surfaces the source, the failed alignment path, and the steps to fix it, while also monitoring SPF, DKIM, DMARC policy, hosted records, and blocklist or blacklist signals in one place.
