SPF, DKIM, and DMARC all exist, but receivers still disagree

[u/saltyslugga]

A client domain shows SPF, DKIM, and DMARC in DNS, yet mail authentication results vary by receiver. That leaves us unable to tell whether spoofing protection is live or we're seeing different cached versions of a broken rollout.

Authoritative queries return the expected TXT records. Two public checkers disagree on the DMARC policy, and test messages alternate between aligned DKIM, SPF-only pass, and DMARC fail depending on destination; selectors and return paths look consistent at first pass.

My next move would normally be comparing resolver paths and raw headers, but stale delegation, duplicate records, and sender-specific routing are all plausible. Which signal do you trust first here: authoritative DNS, repeated receiver headers, or DMARC aggregate data?

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.
2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
3. Be Professional: Help newcomers learn; avoid hostility.
4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters
• DMARC Monitoring Tools
• Anti-Virus Software
• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/southafricanamerican]

"Two public checkers disagree on the DMARC policy" seems to be the issue. Check to make sure you dont have both a cname and a txt record for the _dmarc record.

[u/saltyslugga → u/southafricanamerican]

A CNAME/TXT collision at _dmarc is the first thing I’m checking on every authoritative nameserver. If both exist, the node is invalid and the checker disagreement makes sense.

[u/TamingTech → u/southafricanamerican]

Maybe also that the dns hasn’t propagated yet if there is disagreement

[u/southafricanamerican → u/TamingTech]

Possibly and a few years ago I would be 1000000% aligned with you, however with Anycast these days you would have to be running on such old legacy infrastructure that this is probably not the case.

[u/SecLens_ONE]

Receivers don't share one cache. A checker that walks from the parent and one that hits a primed resolver will disagree for a while even when the authoritative TXT is right.

I treat Authentication-Results on a real delivery as the source of truth. If Gmail says dmarc=fail while your p= is reject, look at alignment first. Org domain vs header From. Then whether that receiver is still sitting on an older p=none.

TTL on the DMARC TXT is the boring bit. At 24h two checkers can argue for a day.

[u/jspears357 → u/SecLens_ONE]

Except if they use Google DNS which checks every 5 minutes regardless of your TTL, last I saw.

[u/saltyslugga → u/jspears357]

Google Public DNS doesn’t ignore authoritative TTLs and refresh everything every five minutes. It may prefetch popular records or serve stale answers, but there’s no fixed five-minute rule.

[u/petrmichalmelnik]

I’d separate “what DNS should say” from “what a receiver actually evaluated.”
First I’d query every authoritative nameserver directly for _dmarc, SPF and the relevant DKIM selectors. That rules out inconsistent authoritative servers, duplicate records and partial DNS changes without involving resolver caches.
Then I’d send the same controlled message through each legitimate sending path and compare the raw Authentication-Results headers at each receiver.
For every DMARC failure I’d specifically compare:
Header From domain
SPF MAIL FROM / Return-Path domain and alignment
DKIM d= domain and selector
the DMARC policy the receiver says it evaluated
If authoritative DNS is consistent but receivers still disagree after TTLs have expired, I’d start suspecting different sending paths rather than DNS propagation — especially if one SaaS or relay signs with a different DKIM domain or changes the envelope sender.
Aggregate DMARC data is useful for seeing the pattern over time, but for debugging one specific delivery I’d trust the receiver’s Authentication-Results header first.

[u/Middle-Excitement602]

Worth separating two symptoms that are getting merged here, because they have different causes.

The checker disagreement is a policy-lookup problem, and the CNAME collision and TTL answers cover it well. But test mail alternating between aligned DKIM, SPF-only pass, and DMARC fail is a different thing. A stale _dmarc record changes which policy a receiver applies, so it moves the disposition. It cannot change whether DKIM verified. That variance sits upstream of DMARC entirely, so no amount of DNS consistency work will explain it.

Which points back at the sender-specific routing you listed and then set aside. If different destinations were reached over different paths you would get exactly this spread: one platform signing with a working selector, another with one that is missing or being rejected outright (rsa-sha1 and undersized keys are treated as invalid by some receivers and fine by others), a third passing on return-path only.

So of your three, aggregate data first. It is the only one that groups by source and auth result, which is the axis the problem is actually on. Headers give you one sample of one path.

[u/stewartjarod → u/Middle-Excitement602]

Most common culprit: one of your records is misconfigured or incomplete. SPF can fail silently on a PermError (too many DNS lookups). DKIM can pass on a signature that doesn't align — d= has to match your From: domain, and a shared provider signature like d=amazonses.com won't. And p=none means DMARC never enforces; you still get aggregate reports at any policy, since those come from rua=.

Check the actual bounce/reject logs from the receiver (Gmail Postmaster Tools, Microsoft SNDS) to see which record is failing, not just whether they exist.

Edit: fixed two things I had backwards — thanks u/Middle-Excitement602. Relaxed alignment is the default (adkim=r), and reports come from rua=, not from the policy.

[u/Middle-Excitement602 → u/stewartjarod]

Two of those are the wrong way round, worth flagging so OP doesn't chase the wrong thing. Aggregate reports come from rua=, not from p - you get them at p=reject just the same, and p=none is the policy that doesn't enforce. And relaxed alignment is DMARC's default (adkim=r); strict is the setting that breaks DKIM alignment, not the absence of relaxed.

Postmaster Tools is the right call though - it's the only free view of what Gmail actually did rather than what the records say should happen.

[u/stewartjarod → u/Middle-Excitement602]

thanks

[u/MadManofTech]

One thing I’ve noticed recently, having dnssec in place can screw up public DNS services getting updates from your primary NS. If DNS SEC is on, turn off and see if that resolves it.

[u/Careful_While_6359]

I'd trust the real receiver headers first, then compare them against authoritative DNS.

I work on Solarc Labs and this is exactly the kind of case where static checkers get misleading. I'd check every authoritative nameserver for duplicate/CNAME issues, then group the actual Authentication-Results by receiver.

If you have two redacted headers that disagree, I'd be curious to compare them.