How to Fix SPF, DKIM, and DMARC Problems
Authentication repairs go wrong when someone edits the root-domain DNS before checking the message that failed. Start with one received copy from the affected provider. It tells you which server sent the mail, which return-path SPF checked, which DKIM selector signed it, and whether either identity aligned with the visible From domain.
Begin with the receiver evidence
Save the complete raw headers, then find the trusted Authentication-Results field added by the final receiver. Record the source IP, envelope sender, visible From domain, DKIM d= domain and s= selector, SPF result, DKIM result, DMARC result, Message-ID domain, and timestamp.
A DNS checker can confirm what is published now. It cannot prove which route, identity, or key the production message used.
Check SPF on the domain that was actually evaluated
SPF normally evaluates the SMTP envelope sender, not the visible From address. Query the exact domain reported by the receiver. Check for one effective SPF policy and trace every DNS-querying mechanism in the active path.
dig +short TXT example.com
dig +short TXT bounce.example.comMultiple SPF records can return a permanent error. Obsolete includes can consume lookups, and SPF evaluation permits no more than ten DNS-querying terms. Flattening can create another operational problem if provider addresses change and the flattened list does not.
SPF can pass and still fail DMARC. The authenticated envelope domain also has to align with the visible From domain.
Verify the DKIM signature that reached the receiver
Read d= and s= from the delivered DKIM-Signature, then query that selector:
dig +short TXT selector._domainkey.example.comConfirm the public key exists and matches the signer used by every active node or region. During rotation, publish the new key before signing with it and keep the old key available while messages using it can still be verified.
If the key is correct but verification fails, look for modification after signing. Footers, security gateways, mailing lists, line-ending changes, and broken MIME processing can alter signed fields or the body. Compare a copy before the intermediary with the final received message. Replacing a correct DNS key will not repair content changed in transit.
As with SPF, a valid DKIM signature only helps DMARC when its d= domain aligns with the visible From domain.
Read DMARC as an alignment result
RFC 9989 defines the current DMARC protocol. Query the applicable record and review the policy, subdomain policy, reporting destinations, and alignment modes.
dig +short TXT _dmarc.example.comDMARC passes when at least one authenticated path passes and aligns: SPF through the envelope sender or DKIM through the signing domain. A p=none record asks for monitoring and reports; it does not turn a failed message into a pass. Use those reports to find legitimate sources before moving policy to quarantine or reject.
The fixes that waste the most time
- Adding a second SPF record instead of repairing the existing policy.
- Checking the root domain when the message uses a subdomain return-path.
- Calling SPF aligned because the SPF verdict says pass.
- Rotating a DKIM key in DNS without updating every signer, or switching signers before DNS is ready.
- Testing from a different provider, application, region, or stream than the one that failed.
- Moving directly to
p=rejectwhile legitimate senders are still unknown. - Changing SPF, DKIM, DMARC, routing, and content together, then treating a good test as proof of which edit worked.
Before you call it fixed
Send a controlled message through the same application, node, route, and provider path as production. Keep the final header showing the intended SPF and DKIM identities, an aligned DMARC pass, the DNS answers, source IP, selector, route, test time, and change made. Then watch production reports, deferrals, and bounces for drift. The repair is complete when another operator can reproduce the evidence, not when the control panel turns green.
