MX record

What an MX record does

An MX record pairs a hostname with a priority number. A sending server looks up the MX records for the recipient domain and connects to the hosts it finds, lowest priority number first.

MX records must point at hostnames, not at IP addresses. The named host then needs its own A or AAAA record for delivery to work.

What an MX record looks like

In a zone file an MX record is written as the domain name, a TTL, the class IN, the type MX, a priority number and the mail server’s hostname: example.com. 3600 IN MX 10 mail.example.com.

The trailing dot on the target matters. Without it most zone file formats append the zone’s own name, turning mail.example.com into mail.example.com.example.com — a hostname that resolves nowhere, and one of the quieter reasons a domain stops receiving mail.

Most DNS control panels hide the TTL and the class and ask only for a priority and a hostname. The record they publish is the same one.

How priority works

Lower numbers are tried first. A domain publishing priority 10 and priority 20 hosts will receive mail at the 10 while it is reachable, and only fall back to the 20 when it is not.

Records may share a priority. Sending servers distribute across equal-priority hosts, which is how providers spread inbound mail across several servers.

The numbers themselves have no meaning beyond their relative order. Using 10 and 20 rather than 1 and 2 is only a convention that leaves room to insert a host between them later.

What goes wrong

No MX records at all means the domain is not configured to receive mail. Some senders fall back to the domain's A record, but this behaviour should not be relied on.

An MX pointing at a hostname with no address record causes delivery failures, as does an MX pointing at an IP address rather than a name.

Publishing MX records does not authorise anything to send mail as your domain. That is what SPF, DKIM and DMARC do.

Checking the MX records for a domain

Any resolver can be asked directly: dig MX example.com +short returns the priority and hostname pairs, and nslookup -type=mx example.com does the same on Windows.

After a change, ask more than one resolver. What comes back is whatever that resolver currently holds in cache, not necessarily what the zone now says, so two resolvers disagreeing is the normal look of a change still propagating rather than a fault.

A lookup returning nothing does not always mean the records are missing. A resolver can be serving a cached negative answer, and how long it holds that is governed by the zone’s SOA minimum rather than by the TTL on the MX record you just published.

Saying a domain accepts no mail at all

A domain that will never receive email can say so explicitly with a null MX: one record at priority 0 whose target is a bare dot. RFC 7505 defines it, and a sender that understands it gives up immediately instead of queueing and retrying for days.

This is worth publishing on domains that only serve a website, and on parked or redirect-only domains. Without it a sender may fall back to the domain’s A record or keep the message queued, and the bounce arrives late and says less than it could have.

A null MX cannot sit alongside other MX records. Being the only one is the whole of what it means.