MX Records: How Mail Finds Your Domain, and the Traps

An MX record tells the rest of the internet which server accepts mail for your domain. It is one line of DNS, it is the reason your email works, and it is the single most disruptive record to get wrong — because unlike a broken website, broken mail fails silently and you find out days later.

The mechanics are simple enough to cover properly in a few minutes. What is worth more time is the set of ways MX configuration goes wrong in practice, because most of them do not announce themselves and several of them happen during an otherwise routine hosting change.

Table of contents

• How a message finds you
• If there is no MX record
• The four ways this goes wrong
• Changing MX without losing mail
• Checking what is actually published
• How this fits the rest of the stack
• FAQ

How a message finds you

When someone sends mail to [email protected], their sending server does roughly this:

1. Take the part after the @ — example.com.
2. Query DNS for MX records on that name.
3. Get back one or more hostnames, each with a priority number.
4. Try the lowest priority number first, resolve that hostname to an address, and connect on port 25.
5. If it fails, try the next priority up. Keep going, and queue for a retry if all fail.

A typical record set looks like this:

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

Two details people consistently get backwards. Lower numbers are tried first — priority 10 beats priority 20, so the number is a preference rather than an importance ranking. And equal numbers mean load balancing: two records both at 10 receive roughly equal traffic, which is how providers spread inbound mail across servers.

The other rule that matters: an MX record must point at a hostname, never an IP address. A record containing an IP is invalid, and while some servers tolerate it, plenty do not — producing mail that arrives from some senders and not others, which is a genuinely miserable thing to debug.

If there is no MX record

Worth knowing because it explains a specific class of confusion.

With no MX record at all, the sending server falls back to the domain’s A record and attempts delivery to that address. That is the implicit MX rule, and it is why a domain with a website and no mail configuration can appear to accept mail — the web server refuses the connection on port 25, and the sender queues and eventually bounces.

The practical consequence: if your domain does not receive mail, say so explicitly rather than leaving it unconfigured. A null MX record does exactly that:

example.com.   MX   0   .

A single dot at priority zero means this domain accepts no mail. Senders get an immediate, clear rejection instead of a delayed bounce, and it removes a small avenue for abuse.

Pair it with an SPF record of v=spf1 -all and a DMARC policy of p=reject on any domain that neither sends nor receives. Those three lines are the correct configuration for a domain that only serves a website, and almost nobody sets them.

The four ways this goes wrong

1. Overwriting MX during a host migration. The most common and most damaging. You move hosting, the new provider’s DNS panel is populated with default records, and the MX entries pointing at your mail provider are not among them. The website works perfectly and mail stops. Always export the full zone before a migration and diff it afterwards.
2. Mixing providers. Two sets of MX records from two different mail providers, left over from a half-completed switch. Mail is delivered to whichever answers, so some messages land in the old mailbox and some in the new, apparently at random. Only one provider’s records should exist.
3. Pointing MX at a CNAME. MX must reference a hostname that resolves to an address directly. Pointing it at a CNAME violates the specification and breaks with a meaningful minority of senders.
4. Forgetting the rest of the mail records. MX handles inbound. Outbound reputation needs SPF, DKIM and DMARC, and a domain with correct MX but no SPF will find its mail landing in spam folders.

The migration case deserves the emphasis. It is the single most common way a business loses email, it happens during a change nobody associates with mail, and the failure is quiet — senders get bounces you never see, and you notice when someone asks why you ignored their message.

Changing MX without losing mail

A sequence that makes a mail provider switch safe.

1. Set up the new provider fully first — domain verified, mailboxes created, users able to log in. Do not touch DNS yet.
2. Lower the TTL on the MX records to five minutes or so, and wait for the old TTL to expire. If your TTL was four hours, that is a four-hour wait before the change becomes fast.
3. Change the MX records to the new provider’s values, removing the old ones entirely rather than leaving both.
4. Update SPF at the same time, since the sending hosts changed. Mail sent during the gap may fail authentication otherwise.
5. Keep the old mailboxes active for a couple of weeks. Some senders cache aggressively and some queue for days. Do not close the old account the same afternoon.
6. Send test mail in both directions from several external providers, and check it arrives in the inbox rather than spam.
7. Raise the TTL back once stable.

Also verify from outside your own network. Checking that you can email yourself proves almost nothing, because internal routing may not use the public MX at all.

Checking what is actually published

Read the live records rather than trusting the control panel, which shows intent rather than reality.

# The MX records as the world sees them
dig MX example.com +short

# Query a public resolver directly, bypassing local caching
dig MX example.com @1.1.1.1 +short

# The rest of the mail configuration
dig TXT example.com +short          # SPF lives here
dig TXT _dmarc.example.com +short   # DMARC policy

On Windows without dig, nslookup -type=mx example.com does the equivalent.

What to look for: exactly one provider’s hostnames, priorities that make sense, no IP addresses, and hostnames that themselves resolve. A trailing-dot mistake in a zone file is a classic — mail.example.com without the dot can become mail.example.com.example.com, which resolves to nothing.

How this fits the rest of the stack

The migration failure above is the one that costs most, and it happens because DNS and hosting get changed together while mail is an afterthought. The RunxBuild hosting calculator covers the hosting side across the service, database, storage and bandwidth. On RunxBuild the custom domain and its certificate are handled at deploy, so pointing a site is a single record change — which leaves your MX entries exactly where they were, rather than replaced by a default zone.

Useful related references:

• Self-Hosted Mail Server: An Honest Account of What You Are Taking On
• What Is an Email Domain? And the Three DNS Records That Decide If Mail Arrives
• DNS Record Cleanup: Find Stale Records, Audit Zones, and Remove
• Custom domains and certificates on RunxBuild

FAQ

What is an MX record?

A DNS record naming the mail server that accepts email for a domain, with a priority number. Sending servers query it, try the lowest priority number first, and fall back to higher numbers if that fails. It must point at a hostname, never an IP address.

Does a lower MX priority number mean less important?

The opposite — lower numbers are tried first, so priority 10 is preferred over 20. The number is a preference rather than a ranking. Two records with the same number share traffic roughly evenly, which is how providers load balance inbound mail.

What happens if a domain has no MX record?

Sending servers fall back to the domain’s A record and try to deliver there, which is the implicit MX rule. For a domain that only serves a website, that means a delayed bounce. Publish a null MX record — a single dot at priority 0 — to say clearly that the domain accepts no mail.

Why did my email stop working after changing hosting?

Almost certainly because the new provider’s DNS panel was populated with default records that did not include your MX entries. The website works and mail stops silently. Export the full DNS zone before any migration and diff it afterwards.

Can an MX record point to a CNAME?

No. MX must reference a hostname that resolves directly to an address. Pointing it at a CNAME violates the specification, and while some senders tolerate it, enough do not that you get mail arriving from some sources and not others.