MX Lookup

An MX record (mail exchanger record) tells sending mail servers which hosts accept email for a domain. Each MX record has a priority number and a mail server hostname, and senders try the lowest number first. The hostname must have its own A or AAAA record. It cannot be a CNAME or an IP address.

MX has been part of DNS since RFC 1035 in 1987, and its delivery rules are specified by RFC 5321. The priority number is called preference in the RFCs. MX records are what let an email address and a website live in different places. A domain 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.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.
                        |        |
                    priority   target hostname (never a CNAME, never an IP)

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, so 10 and 20 behave the same as 1 and 2, or 5 and 500. The convention of using multiples of ten exists 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. This is how mail providers spread inbound load across a pool. Google Workspace publishes five hosts at preferences 1, 5, 5, 10 and 10 for that 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.

The MX hostname usually identifies the provider, and where it does not, the IP addresses behind it do. Resolving each MX target and reading the ASN that announces its addresses is the reliable way to answer this question. A domain can point its MX at a hostname in its own zone and still have every message handled by a third party.

The Mimecast, Proofpoint and Email Security.cloud rows in that table are security gateways, not mailbox hosts. When the MX points at one of them, inbound mail is filtered there and then relayed to the real mailbox provider, which DNS does not reveal. In that case the ASN behind the MX addresses tells you the filtering vendor, and the domain's SPF record is usually the better clue to who runs the mailboxes.

A plain MX listing stops at the hostname. DNSX resolves every MX target to its A and AAAA records and annotates each address with its city, country and announcing ASN, so the mail flow is visible end to end in one view.

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. The usual symptom is mail that arrives from some senders and not from others.

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 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 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, and delayed rather than lost is all a backup MX buys you.

A third-party backup MX can make delivery worse. Spammers target the secondary 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, publish a null MX instead of a backup.

A null MX record is a single MX record with preference 0 and a target of a single dot, defined by RFC 7505. It tells sending servers that the domain accepts no email at all, so they reject the message immediately instead of queueing it and retrying for days. Without it, a domain with no MX record still receives delivery attempts at its A or AAAA address under the implicit MX rule in RFC 5321, and a web server on that address will leave the sender retrying until the queue expires. Publish a null MX on parked domains, on web-only subdomains and on any domain that is used in a From address but never receives replies. Pair it with an SPF record of v=spf1 -all so the domain can neither send nor receive.

; Null MX (RFC 7505): this domain accepts no mail
example.com.  IN  MX  0  .

Both nslookup and PowerShell's Resolve-DnsName can query MX records on Windows, and both accept a resolver address so you can compare a public resolver with your local one. Run a second query for the MX hostname to confirm it has an A or AAAA record, since neither tool follows the target for you.

nslookup -type=MX example.com
nslookup -type=MX example.com 8.8.8.8
Resolve-DnsName example.com -Type MX
Resolve-DnsName mail1.example.com -Type A

macOS ships with dig, so an MX query works from Terminal without installing anything. The +short option prints just the preference and hostname for each record, and an @ resolver address asks a specific public resolver instead of the system one.

dig MX example.com +short
dig @1.1.1.1 MX example.com +short
dig A mail1.example.com +short

On Linux, dig comes from the bind-utils package on Fedora and RHEL and the dnsutils package on Debian and Ubuntu. The host command from the same package gives a one-line answer per record. The DNSX API returns the full mail flow, with every MX host resolved and annotated, as JSON.

dig MX example.com +short
host -t MX example.com
curl "https://api.dnsx.dev/dns/mx/gmail.com?flow=1" | jq .