Updated on 19 Jun 2026: We updated this guide for RFC 9989 terminology, DMARC reporting changes, and practical sender ownership checks.
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 has identifier alignment 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 production setups, fix DKIM alignment first because it survives forwarding better, then use SPF alignment as a second path when the sending service supports a custom Return-Path cleanly. When several ESPs send as the same domain, treat each ESP as a separate sender with aligned DKIM, a known Return-Path, and the same single DMARC policy record for the domain.
- 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 has alignment.
- Common trigger: Forwarding, SRS rewriting, on-behalf-of sending, subdomain policies, default vendor DKIM, and multiple ESPs sharing one From domain create mismatched authentication domains.
The direct reason DMARC fails
DMARC evaluates the domain in the visible From header, also called RFC5322.From or the body From address. Current DMARC terminology calls this the Author Domain. DMARC calls the passing SPF and DKIM domains Authenticated Identifiers. A raw SPF pass against RFC5321.MailFrom or a raw DKIM pass against d= is not enough. The pass must belong to a domain that has alignment with that Author Domain.
The Sender header can explain who sent a message on behalf of another party, but DMARC does not use it for policy. Fixing Sender alone will not repair a From-domain alignment failure.
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 authenticated domain and the Author Domain must be identical. Under RFC 9989, organizational domain discovery uses DNS Tree Walk, so explicit DMARC records on active Author Domains reduce surprises during policy lookup.
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.
Infographic showing DMARC alignment between the visible From domain, SPF domain, DKIM d= domain, and final DMARC 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. Receivers can also evaluate SPF for HELO, but DMARC relies on SPF validation of the MAIL FROM identity. A HELO-only SPF pass does not satisfy DMARC alignment.
The MAIL FROM domain is used for bounce handling. Editing the root SPF record will not fix a sender that uses a separate bounce subdomain. It can be a vendor domain, a forwarding domain, an SRS rewritten domain, or a branded bounce subdomain. If several ESPs send for the same visible domain, each checked MAIL FROM hostname still needs one valid SPF answer, not several SPF TXT records at the root or one DMARC record per sender.
Also check DNS at the exact MAIL FROM hostname. If that hostname is a CNAME with a TXT record at the same name, a CNAME chain, or a final target with multiple SPF TXT records, different receivers can return SPF none, temperror, or permerror. If the SPF path returns permerror because of the 10 DNS-lookup limit, it cannot carry DMARC even when DKIM still passes. Fix the checked hostname or CNAME target before trusting SPF alignment.
That distinction also explains a common receiver-dashboard mismatch. Message headers can show spf=pass for the Return-Path while aggregate authentication data looks weak because the receiver is grouping mail by the visible From domain and checking aligned results across real traffic.
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
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounces@forwarder.example; dkim=pass header.i=@mailer.vendor.example; dmarc=fail header.from=news.brand.example
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.
- HELO limit: A HELO SPF pass can help filtering, but DMARC uses the MAIL FROM identity for SPF alignment.
- Return-Path fix: Use a branded bounce subdomain under the same organizational domain instead of adding unrelated vendor IPs to the root SPF record.
- 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.
The DKIM DNS record follows the same identity. Receivers look for the public key at selector._domainkey under the d= domain, so a vendor-supplied selector belongs under the signing domain the sender actually uses. In a multi-ESP setup, each platform should get its own selector or provider CNAME. The selector can differ, but the d= domain still has to align with the visible From domain for DMARC.
When troubleshooting this, 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 matches
- 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 has alignment with the visible From domain.
|
|
|
|---|---|---|
Visible From | brand.test | The DMARC policy domain. |
Sender header | service.test | Helpful context, not the DMARC policy identity. |
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 to check.
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 unless the subdomain publishes its own DMARC record. Under the current standard, np can also describe handling for non-existent subdomains.
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 identify the sender, then configure at least one authentication path to match it. For most marketing, product, and transactional mail, DKIM alignment comes first because it is more stable through forwarding and less dependent on the final connecting IP. For domains with multiple ESPs, start by mapping each platform to its DKIM d= domain and MAIL FROM domain before editing DNS. Classify each source as legitimate, unauthorized, or needing investigation before changing policy.
Do not create one DMARC record for each sending platform. Publish one DMARC policy record for the Author Domain, then give each legitimate sender its own aligned DKIM setup, branded Return-Path, or sending subdomain. Multiple DMARC records at the same host can make DMARC invalid instead of making multiple senders work.
- Confirm: Read the visible From domain and identify the exact DMARC policy being applied.
- Compare: Check whether the SPF envelope sender domain matches the From domain.
- Trace SPF DNS: Confirm the exact Return-Path hostname and any CNAME target return one clean SPF answer.
- Inspect: Check every passing DKIM signature and compare each signing domain with the From domain.
- Assign: Map the failing source to a business owner so the DNS or sender-side change is made in the right system.
- 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.
Check record placement before changing policy. DMARC belongs at _dmarc for the visible From domain, DKIM belongs at the selector hostname under the d= signing domain, and SPF belongs at the Return-Path domain used in the SMTP MAIL FROM identity. Copying every record to the root domain can still leave the failing mail stream misaligned.
Example DMARC record while testing alignmentdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com; " "adkim=r; aspf=r" )
A p=none policy is valid monitoring, not an authentication failure. Use it to collect aggregate reports while you identify unaligned senders, then move to quarantine or reject only after legitimate traffic has aligned SPF or DKIM.
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, a root SPF record was edited while the Return-Path used another domain, 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.
Flowchart showing forwarded email, SPF changes, DKIM survival, and the DMARC alignment decision.
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. Mailing lists have the same failure shape when they add prefixes or footers, because the original DKIM signature can break while SPF belongs to the list server.
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 existing 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. 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 to read the headers
When a failure report, receiver dashboard, or raw message looks inconsistent, reduce it to four questions. Do not start by changing DNS. First identify which authenticated identity DMARC used, which domains passed, and which one should have aligned. Treat Sender as context only, not as a DMARC pass/fail identity.
RFC 9990 now defines DMARC aggregate reporting. If you are reading aggregate RUA reports instead of a raw header, compare policy_evaluated results with the auth_results block. The auth_results block can show raw SPF or DKIM pass for a vendor domain, while policy_evaluated.dkim or policy_evaluated.spf still shows fail because DMARC is recording the aligned result for the Author Domain.
Receiver dashboards add another layer because they aggregate many messages. SPF and DKIM can look steady while DMARC moves if the daily source mix changes, a small failing sender sends a larger batch, or the dashboard groups several subdomains under one view. Compare one high-success day with one low-success day, then group the aggregate report rows by source IP, MAIL FROM domain, DKIM d= domain, and Author Domain before changing DNS.
|
|
|
|---|---|---|
From? | header.from | Confirm policy domain. |
SPF? | mailfrom | Use aligned bounce domain. |
DKIM? | header.i | Use aligned signing domain. |
Policy? | p / sp / np | Stage only if needed. |
Use this compact checklist before editing DNS.
Suped's product is useful here because DMARC monitoring groups the same failure pattern across reports instead of making you inspect one XML file at a time. 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 or blacklist monitoring keep the authentication work in one place. The practical value is faster ownership of each fix and fewer ambiguous failures.
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 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 testing: Under RFC 9989, pct is removed. Use t=y as a policy testing signal when moving toward quarantine or reject.
- Separate subdomains: Publish a subdomain DMARC record when one subdomain needs a different rollout path.
- Protect unused names: Use np when you need a policy for non-existent subdomains under the current DMARC rules.
- Handle failure reports carefully: Use ruf and fo only when there is a process for sensitive header data; rua reports are enough for most alignment work.
Production DMARC record after senders are aligneddns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=reject; sp=reject; np=reject; " "rua=mailto:dmarc@example.com; adkim=r; aspf=r" )
Because receiver handling can vary, use t=y as a staging signal, not as a promise that failing mail will be delivered. Remove it after aggregate reports show that legitimate traffic has aligned SPF or DKIM.
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, product mailer, shipping notice system, invoice tool, and review platform can all send as the same brand while authenticating different technical domains.
This is where the business cost appears. Every third-party sending service, product system, support tool, website form, and internal server can introduce a new Return-Path or DKIM d= domain. Name an owner for sender intake and report review so a p=none monitoring setup turns into fixes instead of an unread report archive.
Best practical order
- Inventory: List every service that sends mail using the domain.
- DKIM: Enable custom DKIM for every sender that supports it.
- SPF: Use branded 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.
?
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 matches 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. Policy staging 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 fits this workflow when teams need to connect DMARC failures to source ownership. It surfaces the sending 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.
