MX Records: How Email Routing Finds the Right Server

You send an email to someone at example.com. Within seconds it arrives. The mechanism behind that delivery — the part that decides which server actually receives the message — is the MX record.

Most people encounter MX records exactly once, when setting up a new mail provider and following instructions to "add these two MX records." That's enough to get email working. But understanding what the records actually do helps when something goes wrong, and it makes a change alert a lot easier to evaluate.

What MX records actually do

When a mail server needs to deliver a message to [email protected], it has to find where to send it. It doesn't guess or use the A record for example.com — it looks up the MX records for the domain.

MX stands for Mail Exchanger. Each MX record names a mail server that accepts incoming email for the domain. The sending mail server connects directly to that server over SMTP and delivers the message.

This is different from how web traffic works. Visiting example.com in a browser uses the A record. Sending email to [email protected] uses the MX records — the two don't have to point at the same place, and usually don't.

Priority numbers and what they mean

Every MX record includes a priority number:

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Lower numbers mean higher priority. In this example, sending servers should try mail1.example.com first. mail2.example.com only gets used if the first server is unreachable or refuses the connection.

The specific numbers don't matter — only their relative order does. 10 and 20 mean the same thing as 1 and 2, or 5 and 100. The convention of using multiples of 10 leaves room to insert new records in between later.

When two MX records share the same priority, sending servers will distribute connections between them equally, which is the intentional exception used for load balancing across identical servers.

Why most domains have more than one MX record

Multiple MX records are primarily about redundancy.

When you add your company's email to Google Workspace or Microsoft 365, they give you two or three MX records pointing at different servers with different priorities. If the primary server is temporarily unavailable — maintenance, an outage, a network issue — the sending server falls back to the next one and delivers the message there instead.

Without a backup MX server, a sender who hits a downed primary has nowhere to go. Depending on their retry logic, they may try again in a few hours or bounce the message immediately. With a backup MX, the message gets queued and delivered without the sender ever knowing there was a problem.

When MX records legitimately change

The normal reasons MX records change:

Migrating to a new email provider. Moving from one mail host to another requires swapping out MX records to point at the new provider's servers. This is the most common reason for an MX change and should coincide with a deliberate migration.

Adding or removing a backup MX provider. Some organizations add a secondary mail host for redundancy beyond what their primary provider offers. Adding or removing one appears as an MX record change.

Adjusting priority values. Changing priorities — for example, demoting a server from primary to backup — modifies the record without changing which servers are listed.

Adding email filtering. Some spam filtering and security services sit in front of your mail provider: you point your MX records at the filtering layer, which inspects and forwards clean messages to your actual mail server. Adding or switching these services changes your MX records.

What an unexpected MX record change means

An MX change outside of a planned migration redirects all incoming email for your domain to a different server.

Unlike an A record change that breaks one endpoint, a changed MX record affects every email sent to every address at your domain — without interrupting your website, breaking links, or triggering any user-visible errors. Email either silently arrives at a server you didn't intend, or stops arriving at all.

This is what makes MX changes one of the higher-severity alerts. The most obvious malicious scenario: an attacker who gains access to your DNS can point your MX records at a server they control and intercept inbound email — password reset links, two-factor codes, invoices, internal communications.

Even without malicious intent, an accidental MX change is immediately disruptive. A mistyped hostname, a deleted record, or a provider misconfiguration can cause email to fail silently for hours before anyone notices.

How to check your MX records

To see what MX records a public resolver currently returns for a domain:

dig MX example.com

To query a specific resolver, bypassing your local cache:

dig @8.8.8.8 MX example.com

The response will list the mail server hostnames and their priorities. To verify those hostnames resolve correctly:

dig A mail1.example.com

If dig isn't available, dnschecker.org will show MX records from multiple global locations without installing anything.

How email authentication relates (but is separate)

MX records control where incoming email goes. They say nothing about whether outgoing email from your domain is legitimate.

That's handled by a different set of DNS records — SPF, DKIM, and DMARC — which let receiving servers verify that messages claiming to be from your domain were actually sent by you. If you're dealing with email landing in spam rather than routing problems, those records are what to look at. There's a separate article on why email ends up in spam and how SPF, DKIM, and DMARC work.

How DNS monitoring fits in

MX record changes are one of the quieter ways for something to go wrong: no obvious error page, no broken link, just email not arriving — or arriving somewhere it shouldn't.

OneDollarDNS monitors MX records alongside every other record type and alerts you when anything changes. And since a broken MX record means email to your domain may not arrive, it's worth routing alerts somewhere other than that inbox — Team Notifications lets you receive alerts via Slack, Discord, webhook, or a separate email address so a critical change reaches you regardless.