How can split-brain DNS cause email delivery problems?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Your internal team sends an email, your internal tests pass, everything looks fine. Then someone outside your organization reports they never got it, or that it landed in spam. You dig in and can't reproduce the problem. If your company runs split-brain DNS, that's often exactly what's happening.
Split-brain DNS means you have two separate DNS views: one that's visible inside your network and one that's visible to the public internet. That setup is intentional and useful for lots of reasons. But email authentication and routing both depend entirely on what the receiving mail server sees when it queries DNS. And the receiving server is almost always outside your network.
Where it breaks down for email
SPF failures that look like passes. Your Sender Policy Framework (SPF) record lists the IP addresses that are allowed to send email for your domain. If your internal DNS has a different SPF record than your public DNS, your internal checks will pass. But when Gmail, Outlook, or any external mail server checks your SPF after receiving a message, they're querying your public DNS. If that record is out of date or misconfigured, the check fails externally even though everything looked fine from inside.
DKIM verification falling apart. When an external server receives your email, it fetches your DKIM public key from DNS using a selector lookup (something like selector1._domainkey.yourdomain.com). If your internal DNS resolves that selector to a different key than your public DNS does, the signature won't match and verification fails. The email didn't change in transit. The key just didn't match what the receiver found.
MX records pointing to unreachable servers. If your internal DNS has MX records pointing to internal mail servers, external senders can't reach those servers at all. They're behind your firewall. The external sender's MX lookup hits your public DNS (which hopefully has the right record), but if someone has accidentally updated the wrong DNS view, inbound mail starts timing out or bouncing.
Testing that lies to you. This is the sneaky one. You test from inside your network, everything works. Your internal DNS resolves correctly. You ask a colleague to check, they're on the same VPN, same result. The problem only surfaces when someone outside your network actually receives your email. That gap between "works in testing" and "fails in production" is one of the classic signs of a split-brain DNS mismatch.
How to actually diagnose it
The key is to query your public DNS records from outside your network, not from inside. A few ways to do that:
- Use a public DNS lookup tool from a machine that's not on your corporate network or VPN. Google's DNS (
8.8.8.8) or Cloudflare's (1.1.1.1) will give you what the world sees. - Compare your internal resolver output against those public results for your SPF record (
TXTon your root domain), your DKIM selectors, and your MX records. - If the results differ, you've found your split.
Still you can also run your domain through our free SPF checker or DKIM record lookup, which query public DNS and show you exactly what external receivers will see. If those results don't match what your internal team sees, that's your diagnosis right there.
For the fix itself, the most reliable approach is keeping all email authentication records (SPF, DKIM, DMARC) identical in both DNS views. There's no good reason they should differ. Once you've confirmed that, check out how to keep your internal and external DNS views consistent to make sure it doesn't drift again.
If you're stuck or the records look right but delivery is still failing, our SOS hotline is free. Sometimes these configurations are tangled enough that a second pair of eyes helps.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
