What’s the difference between internal and external MX records?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

If you've ever sent an email to a colleague and noticed it arrived instantly, while an email from a client takes a slightly different path through your spam filter first, that's split DNS in action. Internal and external MX records are the reason those two journeys look different.

Here's the core idea. Your domain has one set of MX records published publicly in DNS, visible to the entire internet. But inside your corporate network, your internal DNS server can serve up a completely different set of MX records that only your internal machines ever see. That's split DNS.

External MX records are what the rest of the world uses. When someone outside your organization sends you an email, their mail server looks up your domain's public DNS, finds the external MX record, and delivers to your perimeter server. That perimeter server is often a security gateway, spam filter, or cloud mail hygiene service. It screens the message before passing it on.

Internal MX records are what your own network uses. When an employee at captain@deepcurrent.io sends a message to lighthouse@deepcurrent.io, their internal mail client looks up the MX record via the internal DNS server. That internal DNS server returns a different answer pointing directly to the internal mail server. The message never leaves the corporate network, never touches the perimeter filter, and arrives faster.

This setup has real benefits. Internal mail stays private, skips unnecessary hops, and doesn't pile onto your security gateway's queue. For large organizations sending thousands of internal messages a day, that adds up.

But it comes with some gotchas worth knowing.

  • Authentication testing will mislead you. If you run an SPF or DMARC check from inside the network, you're testing against internal DNS. That result may not match what the outside world sees. Always test MX resolution from an external vantage point too.
  • Misconfigured internal DNS creates silent delivery failures. If your internal MX record points to a server that's down or misconfigured, internal mail stops routing correctly while external mail keeps flowing fine. This is one of the trickiest splits to diagnose because everything looks fine from the outside.
  • Consistency matters. Your internal and external configurations need to stay in sync when you make infrastructure changes. Updating one without the other is a classic source of "mail works for external senders but not internally" complaints.
  • Spam filtering gaps. If internal mail bypasses your perimeter filter, a phishing email from a compromised internal account travels straight to colleagues without any screening. That's a real security trade-off to discuss with your IT team.

If you're setting this up for the first time, the short version is: your external MX record handles everything arriving from the internet, and your internal MX record (served only to machines inside your network) handles traffic between your own users. Both need to be correct, and both need to be maintained together.

Not sure if your external MX record is resolving the way you expect? You can check it with our free Email Header Analyzer, or drop into the SOS hotline if something feels off and you want a second pair of eyes.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Map out your split DNS mail flow

We're setting up split DNS at company name and need help understanding how internal and external MX records will work together. Based on our setup below, can you walk through what our mail flow will look like, flag any consistency risks between our internal and external DNS, and list the top things we should test before going live? Our setup: - Internal mail server: hostname or IP - External MX / perimeter gateway: hostname - Internal DNS provider: e.g. Windows DNS, BIND, other - External DNS provider: e.g. Cloudflare, Route53 - Email platform: e.g. Microsoft 365, Exchange on-prem, Google Workspace - Current authentication records in place: SPF / DKIM / DMARC, yes or no Please give me: 1. A plain-language description of how a message travels internally vs externally in this setup 2. The three most common misconfiguration risks for split DNS environments like ours 3. A checklist of tests to confirm both paths are working correctly

Edit the yellow boxes, then send to the AI of your choice.