Why SPF DKIM DMARC Pass DNS Checks But Receivers

You have checked everything. The SPF record resolves correctly. DKIM is signed and the public key is published. DMARC policy is set and aligned. All the DNS checks pass. Then you send a test email and the results are contradictory: Gmail passes DKIM, Microsoft fails alignment, a third receiver reports SPF-only pass, and a fourth silently drops the message without explanation.

The DNS records have not changed since you checked them. The setup was not broken at the time of DNS checking. So why do receivers disagree?

The answer is that DNS correctness and receiver-side correctness are two different things. DNS tells you what should happen. Receiver results tell you what did happen, from that receiver's perspective, at the moment they processed your message. The gap between those two views is where the problem lives.

Why Receivers Disagree Even When DNS Is Correct

Stale DNS cache at the receiver. Email receivers cache DNS records. Some honor TTLs strictly. Others hold onto old records longer than the TTL specifies, especially under load. If a receiver is still using a cached SPF record that predates your recent change, they evaluate your messages against an outdated authorized IP list. The same applies to DKIM selector records and DMARC policy records. Your DNS is current. Their cache is not.

Selector record timing. DKIM selectors live at a subdomain like selector1._domainkey.yourdomain.com. If you rotate DKIM keys and publish a new selector record but the old selector is still active in some receiver's cached configuration, that receiver tries to verify against the old public key and fails. The selector system was designed for key rotation, but the timing of that rotation is not coordinated across receivers.

Email forwarding strips signatures. When a message is forwarded, the forwarding server may re-wrap the message or change the return path. This can strip the DKIM signature entirely, because DKIM signatures are computed over the message body and certain headers. Any modification along the forwarding chain invalidates the signature. The original sender's authentication was valid. The forwarded message's authentication is not.

Intermediate relay behavior. Some security gateways, spam filters, and mailing list servers re-inject mail with a different envelope sender. This breaks SPF alignment even though the original SPF record was correct for the original sending IP. The relay is not spoofing. It is legitimately forwarding on behalf of the original sender, but the RFC requires alignment between the RFC5321.MailFrom domain and the RFC5321.From domain for DMARC to pass.

Alignment mode mismatch. DMARC has two alignment modes: relaxed and strict. Relaxed alignment considers subdomains as valid. Strict alignment requires the organizational domain to match exactly. If you set strict alignment expecting precise domain matching, a receiver that interprets your policy as relaxed alignment may pass mail you intended to reject. Conversely, if you are using relaxed alignment but a receiver interprets your record as requiring strict alignment, they may fail messages you expected to pass.

How to Diagnose Which Receiver Is Right

Step 1: Read the Authentication-Results header. Every email that passes through a standards-compliant receiver includes an Authentication-Results header. This tells you exactly what that receiver evaluated and what result they reached. It lists the SPF result, the DKIM result, and the DMARC result from that receiver's perspective. Collect these headers from messages received at multiple destinations and compare them side by side. Differences tell you exactly where the disagreement is.

Here is what a clean Authentication-Results header looks like:


Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1;
       spf=pass (google.com: domain of sender@yourdomain.com designates 192.0.2.1 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Note the key fields: dkim=pass, spf=pass, dmarc=pass, and the header.from value that must align with your domain.

Step 2: Check selector records directly. If DKIM is failing at a specific receiver but passing elsewhere, query the selector record they are using. Find the selector name from the Authentication-Results header (it appears in the header.i= field). Query that specific subdomain directly:


dig TXT selector1._domainkey.yourdomain.com

Compare what you get back with what you expect. If the receiver is using a selector you have already retired, the query returns nothing or a different key than the one your mail system is currently signing with.

Step 3: Use DMARC aggregate reports to find silent failures. This is where monitoring tools like DMARCFlow make a real difference. Instead of collecting Authentication-Results headers from individual messages across multiple destinations, aggregate reports give you a structured daily view of which receivers processed your mail, how many messages passed or failed authentication, and which IP addresses they saw sending for your domain. If a receiver is silently dropping mail, the aggregate report shows a sudden drop in message volume from that receiver, often with a high failure rate. This is often the first signal that a receiver has started silently dropping your mail due to an authentication mismatch.

What to Do About It

For stale DNS cache: You cannot force a receiver to flush their cache. Set TTLs that are not too short (too short causes other problems) and verify changes during a low-traffic window. If a major receiver is serving stale records more than 48 hours after your change, wait. Most cache expiry issues resolve within a few hours to a couple of days.

For selector record issues: Keep old DKIM keys active for at least 72 hours after rotating to a new selector. Some receivers cache selector records longer than their TTL suggests. During that window, both the old and new selectors should be valid so mail does not break during the transition.

For forwarding: If your users forward mail to external addresses and you see DMARC failures for forwarded messages, the fix is usually at the forwarding side. SRS (Sender Rewriting Scheme) rewrites the envelope sender when mail is forwarded so that DMARC alignment passes. If the forwarding is happening from your infrastructure, you need SRS at your mail server.

For intermediate relays: If a security gateway or mailing list server is re-injecting mail with a different envelope sender, the sender domain may need to be added to your SPF record if it is a legitimate forwarding service you control. For third-party services you do not control, ARC (Authentication Received Chain) headers let intermediate servers preserve authentication results through a chain of relays.

For alignment mode mismatch: Check your DMARC record. If you intend strict alignment, make sure your record says adkim=s. If you want relaxed alignment, use adkim=r. Most organizations start with relaxed alignment. If you are moving to strict alignment, do it gradually and monitor aggregate reports for failures before enforcement.

How DMARCFlow Helps

DMARCFlow surfaces receiver-level disagreement in one view. The aggregate report dashboard shows per-receiver pass/fail rates, message volume trends, and alignment results. When a receiver starts failing DMARC unexpectedly, you see it in the dashboard before you would notice individual messages going missing. You can also set up alerts for sudden drops in message volume from specific receivers.

This is more efficient than collecting Authentication-Results headers from individual messages and trying to correlate them manually across multiple destinations. DMARCFlow does the monitoring work so you can focus on fixing the problems it surfaces.

FAQ

Q: Why does my email pass SPF DKIM DMARC in DNS checks but fail at some receivers?
A: The most common causes are receiver-side DNS caching of old records, selector record propagation delays, forwarding that strips signatures, or intermediate relays that modify headers. Check authentication headers in the received message to see what each receiver actually evaluated.

Q: How do I check what a specific receiver actually evaluated?
A: Look at the Authentication-Results header in the raw email. It shows the SPF DKIM and DMARC result that specific receiver reached. Compare it across multiple receivers to find the disagreement.

Q: Can forwarding break DMARC even if everything is configured correctly?
A: Yes. Forwarding can strip the DKIM signature and re-align the return path, causing DMARC alignment to fail even though the original authentication was valid. This is a common cause of silent mail loss.

Q: How long do I need to keep old DKIM selectors active after rotating keys?
A: At least 72 hours. Some receivers cache DKIM selector records longer than their TTL suggests. Keeping the old selector active during a transition window prevents mail from breaking during key rotation.

Q: What is the difference between SPF alignment and DKIM alignment under DMARC?
A: SPF alignment checks whether the domain in the RFC5321.MailFrom (envelope sender) matches the domain in the RFC5321.From header. DKIM alignment checks whether the domain in the DKIM signature's d= tag matches the RFC5321.From domain. Both must pass alignment for DMARC to pass. Relaxed alignment allows subdomains. Strict alignment requires an exact match.