MX Records Explained: How Email Routing Actually Works

The Record That Decides Where Your Email Goes

When someone sends an email to your domain, the sending mail server doesn't just guess where to deliver it. It looks up a DNS record called an MX record — short for Mail Exchanger — and that record tells it exactly which server should receive the mail. Get your MX records wrong and email to your domain either bounces or disappears. Get them right and delivery is seamless and reliable.

How MX Record Lookups Work

The lookup process happens before a single byte of email is transferred. Here's the sequence:

1. The sending server extracts the recipient domain from the email address (e.g., example.com from user@example.com)
2. It performs a DNS MX query for that domain
3. DNS returns one or more MX records, each with a hostname and a priority value
4. The sending server connects to the MX host with the lowest priority number first
5. If that server is unreachable, it tries the next lowest priority

This happens in milliseconds, automatically, every time someone sends you an email. Your MX records are the foundation of inbound email delivery.

Reading an MX Record

An MX record has two key fields: the priority (sometimes called preference) and the mail server hostname. A typical MX record in a DNS zone file looks like this:

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

In this example, mail1.example.com has priority 10 and mail2.example.com has priority 20. Lower number means higher priority. Sending servers will always try priority 10 first, falling back to priority 20 only if the first is unreachable.

The actual numbers don't matter — what matters is the relationship between them. You could use 1 and 100, or 10 and 20, or 5 and 50. The sending server just picks the lowest number.

Multiple MX Records and Redundancy

Most production email setups use at least two MX records pointing to different servers. This isn't just best practice — it's essential for reliability. If your primary mail server goes down for maintenance, a network hiccup, or an unplanned outage, incoming email silently fails over to the secondary. The sender never knows anything went wrong.

Some email hosting providers automatically configure redundant MX records when you set up your account. If you're configuring DNS manually, verify that both records are in place and that the secondary server is genuinely capable of receiving mail — not just a placeholder entry.

Backup MX Servers

A backup MX queues incoming mail when the primary is unavailable and delivers it once the primary recovers. This is different from a load-balanced setup where both servers handle traffic simultaneously. With a true backup MX:

• The primary server handles all normal inbound traffic
• The secondary server sits idle unless the primary is unreachable
• Messages queued on the secondary are delivered to the primary once it comes back online

One important caveat: backup MX servers are increasingly targeted by spammers who deliberately try lower-priority MX records, betting that secondary servers have weaker spam filtering. If you run a backup MX, make sure it applies the same filtering rules as your primary — or use a provider that handles this automatically.

Common MX Record Mistakes

MX record errors are frustratingly common, especially after domain migrations or when setting up a new email provider. Watch out for:

• Pointing MX records to an IP address: MX records must point to a hostname, never directly to an IP. Create an A record for a hostname and point the MX record to that hostname.
• Forgetting to update after migration: When you switch email providers, the new provider gives you new MX record values. Until DNS propagates (which can take up to 48 hours), some mail will still go to the old server.
• Using a CNAME as an MX target: RFC standards prohibit MX records from pointing to a CNAME. Some DNS providers accept it, but behavior is unpredictable across sending mail servers.
• Leaving old MX records in place: After switching providers, remove the old MX records. Having both old and new records with different priorities can split inbound mail between two systems.

Verifying Your MX Records

You can check your MX records at any time using standard command-line tools:

dig MX example.com
nslookup -type=MX example.com

Both commands return the current MX records as seen from your network. If you've just made a DNS change, use a tool that queries from multiple geographic locations to verify propagation is complete worldwide — not just from your local resolver.

It's also worth checking that the A record for each MX hostname resolves correctly. An MX record pointing to a hostname with no A record means delivery fails even if the MX lookup itself succeeds.

MX Records and Email Authentication

Your MX records don't directly affect SPF, DKIM, or DMARC — those are separate DNS entries used for outbound authentication. But your MX records must be correct before inbound delivery can work at all, and inbound delivery is what allows feedback loops, abuse reports, and bounce notifications to reach you. Without working MX records, you're flying blind on your sending reputation.

If you're setting up DNS for a new domain, the MailDog DNS security guide covers a complete configuration checklist. For details on how MailDog's SMTP relay infrastructure interacts with MX routing and redundancy, the documentation covers the technical specifics. You can also reach out directly if you're configuring email for a new domain and want to get it right from the start. Additional DNS guides are available on the MailDog blog.