How to check MX records

When email to a domain bounces or silently disappears, the MX records are the first thing to check. They are the part of DNS that tells the world which servers accept mail for a domain, and a single wrong entry can stop delivery entirely.

What an MX record contains

Each MX record has two parts: a priority number and a mail server hostname. A domain usually publishes several:

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

The priority decides order, and lower wins. Sending servers try the lowest number first and fall back to higher ones if it is unreachable. Equal priorities are used round-robin to spread load. The numbers themselves are arbitrary; only their relative order matters, which is why people leave gaps like 10 and 20 to make room for inserting a server later.

The rules that trip people up

MX points to a name, never an IP. The hostname must then have its own A or AAAA record. An MX pointing straight at an address is invalid and many servers will reject it.
No MX means fall back to the A record. If a domain has no MX at all, senders may try the domain's A record directly. Relying on this is fragile; always publish an explicit MX.
The target should not be a CNAME. The mail standard says MX hosts must resolve to an address directly, not through an alias. Some servers tolerate it, many do not.

Debugging delivery

If mail is failing, check in this order: does the domain have MX records at all, do their hostnames resolve to an address, and is the priority order what you expect after a recent migration. A common outage is switching email providers and leaving an old, higher-priority MX in place, so mail keeps flowing to a server that no longer accepts it.

You can pull a domain's full MX set, with priorities, using the MX Lookup tool. Once mail is routing correctly, the next layer to verify is authentication, which the SPF, DKIM and DMARC guide walks through.