What an MX Record Actually Controls (and Common Misconfigurations)
An MX (Mail Exchange) record is a specific, narrowly scoped DNS record type with exactly one job: telling the rest of the internet which server is responsible for receiving email addressed to a given domain. It sounds simple, and the basic concept genuinely is, but a surprising number of email delivery problems trace back to a misunderstanding of exactly what MX records do and don't control.
What an MX Record Actually Specifies
An MX record contains two key pieces of information: the hostname of a mail server willing to accept email for the domain, and a priority value (a number, where lower numbers are actually tried first, somewhat counterintuitively) determining the order in which multiple mail servers should be attempted if more than one is listed. A domain can, and often does, have multiple MX records, providing redundancy — if the primary, lowest-priority server is unreachable, a sending mail server will automatically try the next one in priority order rather than simply giving up.
The Critical Distinction: MX Controls Incoming Mail Only
This is the single most common point of confusion: MX records control where email addressed to your domain is delivered — they have no bearing whatsoever on the servers used to send outbound email from your domain. A completely separate configuration (your mail client's or application's outbound SMTP server settings) governs sending, meaning it's entirely normal and common for a domain to receive mail through one specific mail server (as specified by MX) while sending outbound mail through an entirely different server or service, and changing one has zero automatic effect on the other.
Why This Confusion Causes Real Misconfigurations
A common mistake stemming directly from this misunderstanding: someone switches their outbound email provider (perhaps adopting a dedicated transactional email service for better deliverability, as discussed in the piece on self-hosted mail elsewhere on this blog) and assumes this also requires updating their MX records, when in fact MX records should remain entirely unchanged if incoming mail delivery is still meant to arrive at the same destination as before — the two configurations are genuinely independent, and touching MX records unnecessarily during an unrelated outbound-only change risks breaking incoming mail delivery for no actual benefit.
The Priority Value Mistake That Silently Breaks Redundancy
A second common misconfiguration involves the priority value specifically: administrators sometimes set multiple MX records with an identical priority value, intending this to function as load balancing across multiple servers. While technically valid and used this way by some large mail systems, this is meaningfully different from a genuine primary/backup redundancy setup, and administrators who intended backup redundancy but accidentally configured identical priorities can end up with mail being unpredictably split across servers that weren't actually prepared to handle mail independently and consistently, rather than one server reliably handling everything with a genuine, distinctly-prioritized fallback only engaged during an actual outage.
What Happens When MX Records Point to a Dead or Misconfigured Server
If an MX record points to a hostname that no longer resolves, or to a server that's no longer actually configured to accept mail (a common aftermath of a hosting migration where MX records weren't updated to reflect the new mail server's actual location), sending mail servers will typically retry delivery for some period — often several days — before giving up and returning a bounce message to the original sender, meaning the failure can go unnoticed by the domain owner for a surprisingly long time if nobody is actively checking, since no error appears on the receiving domain's own side at all; the silence is the symptom.
How Migrations Specifically Put MX Records at Risk
As discussed in the piece on hosting migrations elsewhere on this blog, MX records are one of the specific configuration items that sometimes gets overlooked during a migration, particularly when a migration tool or team focuses primarily on files and databases without a specific, deliberate check of DNS-level mail routing — a domain can migrate its website successfully while its email silently continues trying to route to a decommissioned old mail server, or fails outright, entirely unnoticed until someone specifically checks or a business-critical email fails to arrive.
Verifying Your Own MX Configuration
A simple command-line check (dig MX yourdomain.com, or any of several free web-based MX lookup tools) directly reveals exactly what's currently configured and can be compared against what's actually intended, particularly useful immediately after any hosting or email provider migration to confirm mail routing wasn't inadvertently left pointing at outdated infrastructure.
The Takeaway
MX records govern incoming mail routing specifically and exclusively — a narrower, more specific job than the confusion around them often suggests, and one that's frequently, silently broken during migrations or provider switches precisely because it's easy to assume it's connected to outbound mail configuration when it fundamentally is not. Verifying MX records directly and explicitly after any infrastructure change, rather than assuming they carried over correctly, closes a real, common gap.
Tags: DNS configuration, email routing, MX records