MX Records Demystified: What Happens When You Hit Send

I got a call last week from a company whose email was completely dead. First thing I checked: their MX record. Still pointing at a server they decommissioned three years ago.

MX stands for Mail Exchanger. It's the DNS record that tells the world where to send your email. No MX record, no delivery. End of story.

I've lost count of how many times I've debugged "email is broken" and found an MX record that expired right alongside the Bush administration. DNS will happily serve stale data forever if you let it.

How Email Routing Actually Works

Here's the flow when someone sends an email to user@example.com:

The sending server asks DNS: "What are your MX records for example.com?"

DNS returns a list of hostnames with priority numbers.

The sender connects to the lowest-numbered (highest priority) host on port 25.

If that host is unreachable, it tries the next lowest number.

If all hosts are unreachable, it queues the message and retries later.

Most MTAs retry for 48 to 72 hours before bouncing. That's why a mail server can go down for a few hours and nobody notices. Push it past that window and messages start bouncing.

Priority Levels, Not Preference

This trips people up constantly. Lower number = higher priority.

example.com.  3600  MX  5   primary.mail.example.com.
example.com.  3600  MX  10  secondary.mail.example.com.
example.com.  3600  MX  20  backup.mail.example.com.

Priority 5 is tried first. If it's down, priority 10 gets the traffic. Priority 20 is your last resort. Standard practice is to leave at least 5-10 points between priorities so there's a clear failover order.

One thing a lot of people don't realize: if your priority 5 server is up but slow, the sender still tries it first. MX priority isn't a load balancer. It's a failover mechanism. For actual load balancing, you set multiple records at the same priority and let the sender pick randomly (which most MTAs do).

Real-World Configurations

Google Workspace

Google publishes five MX records for redundancy and load distribution:

Priority 1 is the primary. If it's unreachable, the sender randomly picks between ALT1 and ALT2 at priority 5. If both of those fail, it hits ALT3 or ALT4 at priority 10.

Microsoft 365

example.com.  3600  MX  0  example-com.mail.protection.outlook.com.

Microsoft gives you a single MX with priority 0. Their redundancy is handled on the backend. You get one target, but Microsoft runs a massive cluster behind it.

Self-Hosted

example.com.  3600  MX  10  mail.example.com.

If you're running your own mail server, keep it simple. One MX record pointing to your server's hostname. Add a secondary only if you have a backup MX configured.

The IP Address Trap

MX records must point to a hostname, not an IP. RFC 974 requires it. Put an IP in an MX record and legitimate MTAs will reject it.

I still see people doing this:

example.com.  3600  MX  10  192.0.2.1

That's wrong. Do this instead:

example.com.  3600  MX  10  mail.example.com.
mail.example.com.  3600  A  192.0.2.1

The MX record points to mail.example.com, and the A record resolves that hostname to the IP. Two records, clean and RFC-compliant.

The A Record Fallback

If a domain has no MX records at all, RFC 5321 says the sending server should fall back to the domain's A record. Some MTAs do this, some don't. Never rely on it. Always publish explicit MX records.

What I Check When Email Goes Dark

Someone calls and says "I'm not getting email." Here's what I run through.

No MX Records Found

Run our MX Lookup tool. If it returns nothing, that's your problem. Most DNS providers include default MX records when you register a domain, but if you switched DNS providers or cleaned up your zone file, they might be gone.

Wrong MX Target

You migrated from Google to Microsoft but the MX record still points to Google. Update it. Use the DNS Propagation Checker to confirm the change is live.

Intermittent Delivery

Multiple MX records where some point to dead servers. The sending server tries the lowest priority first, but if that fails and the backup is also broken, the message bounces. Test each MX target independently.

High Priority Server Down

If only your backup MX works but the primary is down, email will be delayed while the sender waits for the primary connection to time out. Most MTAs wait 30-60 seconds per attempt. That delay adds up.

MX Record Points to a Dead Host

The hostname in your MX record either doesn't exist in DNS or doesn't have an A record. This is embarrassingly common. Verify that each MX hostname has a corresponding A or AAAA record.

MX Migration: Don't Burn Your Bridges

When switching email providers, keep your old MX records alongside the new ones. Here's the process:

Publish the new MX records with higher priorities (10, 20, etc.) than your current ones.

Wait 48-72 hours for the DNS changes to propagate.

Monitor email flow. You should see traffic gradually shift to the new provider.

Once traffic has stopped hitting the old servers, remove the old MX records.

Keep the old provider active for another 30 days to catch any stragglers.

I've seen migrations where someone deleted the old MX records at 2 PM on a Friday and the entire company lost email until Monday. DNS propagation doesn't care about your weekend plans.

Verify Your Setup

Use our MX Lookup tool to check your current MX records and the DNS Propagation Checker to confirm they're visible globally.