How can I ensure my internal and external DNS views are consistent for email?

You've set up split-brain DNS, your internal network resolves records one way, and the rest of the internet resolves them another. That's fine for a lot of things. For email authentication, it's a quiet disaster waiting to happen if your SPF, DKIM, or DMARC records drift out of sync between the two views.

The core rule is simple: authentication records must be identical in both views. MX records can differ intentionally (internal mail routing is a legitimate reason to point internally vs. externally), but SPF, DKIM, and DMARC need to match exactly. If an external receiving server queries your SPF and gets a different answer than your internal resolver would, you've got a problem that can cause authentication failures, rejected mail, or confusing delivery results that are very hard to diagnose.

Here's how to actually verify and maintain that consistency.

Step 1. Query both views manually

The quickest way to spot a mismatch is to run the same DNS lookup from two different vantage points. From inside your network, use dig or nslookup pointing at your internal resolver. Then run the same query from outside (a VPN exit node works, or ask a colleague on a different network to run it for you).

For SPF, query your TXT record at the root of your sending domain. For DKIM, query [selector]._domainkey.[yourdomain.com] as a TXT record. For DMARC, query _dmarc.[yourdomain.com]. Compare the full string values, not just whether a record exists. Even a single extra IP address or a missing include: mechanism in one view is enough to cause failures.

Step 2. Use an external tool to check the public view

Your internal tests tell you what your network sees. External tools tell you what the world sees. You can check your SPF record and DKIM record with RME's free checkers. Run those, then compare the output against what your internal dig query returned. If they match, you're good. If they don't, that mismatch is exactly what will cause authentication failures in a split-brain setup.

Step 3. Document intentional differences

Not every difference is a bug. If your internal MX points at an on-premises mail relay and your external MX points at your cloud provider, that's intentional. Write it down somewhere your team will actually see it (a DNS change runbook, a wiki page, anywhere). The goal is that when someone updates a record six months from now, they know which differences are deliberate and which are accidents.

Step 4. Build a lightweight audit habit

Now you don't need a full automation pipeline to stay consistent. A simple script that runs dig TXT yourdomain.com @your-internal-resolver and compares the output to a public resolver (like 8.8.8.8) is enough. Run it after any DNS change and save the output. If the outputs differ for SPF, DKIM, or DMARC, that's your alert to investigate before it causes a delivery problem.

For teams that change DNS frequently, a scheduled weekly comparison script (even just a bash one-liner that diffs the two outputs and emails you if they differ) catches drift before it causes pain. Bonus points if you wire it to a Slack alert.

A note on what to test from each side

When testing from inside your network, pretend you're the receiving mail server. Does it see a valid SPF record that covers your sending IPs? Does the DKIM selector it would look up resolve? When testing from outside, does a real receiving server (like one run by Gmail or Outlook) see the same answers? Sending a test message and checking the headers in the received email is the gold standard here. The Authentication-Results header will tell you exactly what the receiving server resolved and whether it passed.

If you're stuck and can't figure out why authentication is failing, our free Email Header Analyzer can help you read what the receiving server actually saw. Or if it's urgent, the SOS hotline is free and we'll walk through it with you.