Troubleshooting DMARC failures
Work from a real message to the authentication or alignment problem behind it.
Start with one real message
Collect the original headers of an affected message from a mailbox you control. Note the visible From domain, the sending service, and the receiver’s trusted authentication results. A forwarded screenshot rarely contains enough detail.
Look for Authentication-Results added by the receiving system. Headers can also be inserted by senders, so do not trust an arbitrary result line merely because it says “pass”.
SPF passes, but DMARC fails
Check the domain SPF authenticated. It may be a service provider’s bounce domain rather than your domain. If that domain does not align with the visible From domain, SPF does not contribute a DMARC pass.
Inspect DKIM next. A valid signature using an aligned domain can independently satisfy DMARC. Your sending provider may support a custom signing domain, custom return-path domain, or both. Follow that provider’s setup instructions.
SPF reports an error
Common causes include multiple SPF policies at one DNS name, malformed syntax, and excessive DNS-dependent processing. The SPF limit concerns mechanisms and modifiers that trigger DNS lookups, including nested evaluation; counting only the visible include entries is not enough.
Use an SPF analysis tool to trace the record. Review obsolete services before adding more authorisations. An SPF change applies to the domain being checked, which might differ from the address a recipient sees.
DKIM does not validate
Find the signature’s d= domain and s= selector. The receiver uses these to locate the key at selector._domainkey.domain.
Check that the key is published at the correct name and that the sending service has enabled signing. Some providers use a CNAME delegation rather than a TXT record you manage directly.
A key can exist while a signature still fails. Message content may have changed after signing, the wrong key may be published, or a key rotation may be incomplete. Test a newly sent message and compare the original headers with the sending provider’s documentation.
Direct mail passes, forwarded mail fails
Forwarding can change the connecting server and break SPF. DKIM can survive forwarding when the signed parts remain intact, but mailing lists or gateways may modify those parts.
This is why forwarding behaviour needs real-message testing. Do not assume that every DMARC failure in an aggregate report represents malicious traffic, and do not broadly authorise a forwarder without understanding the sending path.
The DNS check looks correct
Check what the receiver actually observed and when. Cached records, recently rotated keys, and changes to a sending service can make tests taken at different times disagree.
Record your evidence: message time, From domain, envelope domain, DKIM domain and selector, relevant DNS values, and the receiver’s result. That gives your administrator or provider a concrete starting point.
Before sharing headers or reports with an external tool, remove unrelated personal information and consider the provider’s privacy policy. Never upload private signing keys.
Sources
Sources reviewed .