MX Lookup

An MX record (mail exchanger) is a DNS resource record that names a host willing to accept SMTP mail for a domain. It has been part of DNS since RFC 1035 in 1987, and its delivery semantics are specified by RFC 5321. Each record carries exactly two values: a preference number, universally called priority, and the hostname of a mail server.

MX records are what let an email address and a website live in different places. example.com can have an A record pointing at a web host in one network while its MX records point at Google Workspace or Microsoft 365 in another. A sending mail server never looks at the A record of a domain that publishes MX records.

Lower is better. A sending server sorts the MX records by preference and attempts delivery to the lowest number first, moving to the next value only when every host at the current value is unreachable. Priority 10 is tried before priority 20, and priority 0 is tried before both.

Only the order of the numbers matters. The size of the gap between them carries no meaning at all, so 10 and 20 behave identically to 1 and 2, or to 5 and 500. The convention of using multiples of ten exists only so that a new server can be slotted between two existing ones without renumbering the zone.

Two MX records that share a preference value are equal, and a sending server picks between them at random, which is how mail providers spread inbound load across a pool. Google Workspace publishes five hosts at preferences 1, 5, 5, 10 and 10 for exactly this reason. Microsoft 365 usually publishes a single host at preference 0, and relies on that host being an anycast address rather than on DNS for redundancy.

Neither is allowed. RFC 2181 section 10.3 states that the name in an MX record must be a canonical hostname with an address record, and must not be an alias. Sending servers that follow the rule strictly will treat a CNAME target as a configuration error and refuse to deliver. Others chase the alias and succeed. Inconsistent delivery across senders is the classic symptom.

An IP address in an MX record is invalid for a different reason: the field is defined as a domain name, so a literal like 203.0.113.10 is interpreted as a hostname, gets the zone origin appended, and fails to resolve. There is no bracket syntax that makes it work, and no widely deployed mail server that accepts it.

The MX target must also have a real address record for the address family the sender is using. An MX host with only an AAAA record is unreachable from an IPv4-only sending server, which is a genuinely common cause of one-way mail failures.

A backup MX is a secondary mail server published at a higher preference number than the primary. When the primary is unreachable, senders deliver to the backup, which queues the mail and relays it to the primary once it recovers.

For most domains the answer today is no. SMTP already has a queue: a sending server that cannot reach any MX host holds the message and retries, typically for four to five days before giving up, as RFC 5321 recommends. An outage shorter than that costs you delayed mail rather than lost mail, which is all a backup MX buys you anyway.

A third-party backup MX can actively make things worse. Spammers target the secondary precisely because it usually lacks the recipient list, the content filtering and the reputation data of the primary, so it accepts mail for non-existent users and then generates backscatter when the primary rejects it. If you run one, it must perform the same recipient validation and filtering as the primary, or it becomes the weakest link in the domain's mail security.

The pattern worth copying is redundancy inside a single provider: several MX hosts at the same or adjacent preferences, all of which can accept and store mail. Google Workspace, Microsoft 365 and Fastmail all publish that shape. For a domain that should never receive mail at all, publish a null MX instead. That is one record, example.com. IN MX 0 ., defined by RFC 7505, and it makes senders fail immediately rather than retry for days.