MX Records and How Mail Is Routed

The one record that decides where mail goes

An MX record names the host that accepts mail for a domain. It is the only record type that does that job, and every message addressed to your domain begins with a lookup for it.

The record has two parts, defined in RFC 1035 and unchanged since: a preference value, which is a 16 bit integer, and an exchange, which RFC 1035 describes as a domain name specifying a host willing to act as a mail exchange for the owner name. IANA lists the type under value 15 with the terse meaning mail exchange. A zone can carry several MX records at the same name, and most working domains do.

Mail and web traffic are found by separate lookups. Browsers ask for address records; sending mail servers ask for MX records first. Pointing a domain at a new web host therefore redirects no mail at all.

An MX lookup is also the cheapest diagnostic in email. Ask any resolver for a domain's MX records and you learn which company handles its mail, whether the set is complete, and whether somebody left a previous provider's host sitting in the list.

Reading the preference number

The preference value is a number attached to each MX record, and the rule runs opposite to what the word suggests to most people: lower values are preferred. RFC 1035 states it in four words, Lower values are preferred. RFC 974, which defined MX handling in the first place, describes the number as indicating the order in which the mailer should attempt delivery, with the lowest numbered exchange tried first.

Any value from 0 through 65535 is legal. The habit of using 10, 20 and 30 leaves gaps, so a host can be added between two others later without renumbering the set.

Control panels make this harder than the specification does. Some label the field preference, following the RFC; some label it priority, which invites the reading that a bigger number means more important. Microsoft's documentation acknowledges the inconsistency, noting that some providers want a number while others offer a Low, Medium or High selection, and says plainly that mail goes to the exchange with the lowest preference number.

Two consequences follow. A record you meant as a fallback, numbered 1 while the main host carries 10, silently becomes the main host. And preference 0 outranks every other value in the zone, which makes it a poor choice for anything provisional.

Equal preference values, and the failover that is not there

Two MX records sharing a preference value do not form an ordered pair; they form a group. RFC 974 requires that every exchange at a given preference be tried before any exchange at a higher value, and says nothing about order inside the group, because there is no order to specify.

That is load sharing among equals, and it is the right configuration for two servers that both accept mail all of the time. Senders spread across them, and one that stops answering is simply passed over.

The misreading is to treat equal values as an ordered failover chain, or to treat different values as a substitute for one. A second MX at preference 20 is not a standby that DNS activates when the preference 10 host fails. It is a host senders try after the first failed to answer, and what happens next depends entirely on how that host is configured:

• If it accepts the mail and forwards it on once the main system returns, that is a queue and forward arrangement somebody deliberately built and maintains.
• If it accepts the mail but holds no configuration for your domain, messages are accepted and lost, which is the worst outcome available.
• If it refuses the connection, the sender queues and retries the whole set later, exactly as it would with no second record at all.

The advice to add a backup MX is common and mostly wrong. An exchange that knows nothing about your domain makes delivery worse rather than better.

What belongs in the exchange field

RFC 1035 defines the exchange as a domain name, and that one word settles several arguments. It rules out an IP address, a URL, a port and an email address, none of which are domain names. A control panel that accepts an address there is permissive rather than correct, and the mail that fails as a result fails at the sender, where you never see it.

It also rules out an alias. RFC 2181 is explicit: the domain name used as the value of a NS resource record, or part of the value of a MX resource record, must not be an alias. RFC 1912 puts it plainly, saying MX records shall not point to an alias defined by a CNAME because the result is unnecessary indirection.

The reason sits in the original definition. RFC 1035 notes that MX records cause type A additional section processing for the host named in the exchange, so the answering server is expected to attach that host's address records to the same response. An alias breaks the assumption, and senders recover from it differently, which produces mail that is delivered from some places and not others.

So the target should be a hostname carrying an address record published directly at that name, which is what Route 53's documentation tells administrators to specify.

A domain with no MX record still receives mail

A domain with no MX record is not a domain that refuses mail. Senders fall back to its address record and attempt delivery there, which is almost always worse than a clean refusal.

RFC 7505 describes the behavior as it exists: an SMTP client first looks up an MX record and, if none is found, falls back to an A or AAAA lookup. RFC 974 stated the same rule long before from the other direction, telling mailers to treat the absence as though the domain held one MX record with preference 0 pointing at the domain itself. The convention is called the implicit MX.

So a domain whose only address record points at a web server has, as far as every sending mail server is concerned, nominated that web server as its mail exchange. The connection is refused, the sender queues the message, and it keeps trying. RFC 7505 notes that delivery is attempted repeatedly for a long period, typically a week, before the sending server gives up. The person who wrote to you learns nothing for days.

For a domain that genuinely handles no mail, the remedy is a null MX: one record with preference 0 and an exchange written as a single dot. RFC 7505 defines it, and its effect is to make delivery attempts fail immediately rather than being retried, turning a week of silence into an instant bounce the sender can read. It belongs on parked domains, on defensive registrations, and on brand variants that only redirect to a main site.

Mail does not bounce, it queues

This is what makes an MX change unlike every other DNS change, and why lowering the TTL beforehand is worth the effort here even when it is ceremony elsewhere.

Change an address record with a long TTL and the symptom is loud: visitors land on the old server and say so. Change an MX record with a long TTL and there is no symptom. Senders holding the cached record deliver into the old system, where messages land in mailboxes nobody reads any more, or they reach a host that has stopped accepting mail and queue quietly for days. Nothing bounces, so nothing gets reported, and the problem surfaces when a customer asks why you ignored them.

The sequence that avoids it runs backwards from the change. Lower the TTL on the MX set, wait out the old TTL so every resolver holding the record has picked up the short value, and only then repoint the records. Keep the old system accepting well past the change, because the retry window is measured in days, and let the new records stand alone: Google tells administrators to remove any other MX records when moving to Google Workspace.

Two details catch people. Every MX record at one name shares a single TTL, since RFC 2181 requires all records in a set to carry the same value, so you cannot shorten one and leave the others long. And provider guidance is deliberately conservative — Google tells customers to allow up to 72 hours for new MX records to be recognized — which is that provider's own margin rather than a rule of DNS.

Everything above concerns mail arriving at your name. The sending direction reads a record you almost certainly cannot edit. When your server opens a connection to somebody else’s, the receiver knows the connecting IP address before it knows anything else, and the first thing it can ask about that address is the reverse DNS — the PTR record published in the reverse zone by whoever allocated the address to you. RFC 8601 defines the round trip formally as set membership: take the connecting IP, collect the names it maps to, resolve each of those names back, and the test succeeds if the original IP appears among the results. Two consequences catch people out. The forward half is an A and AAAA lookup, so a server sending over IPv6 needs the AAAA half of the pair to exist, not just the IPv4 half. And an address with no reverse entry at all does not fail the test — it produces a permanent error, because there was nothing to check. That is a different diagnosis with a different fix, and most checking tools collapse the two into one red mark.