MX records: how the internet finds your mail server

Every DNS record covered elsewhere in this series — SPF, DKIM, DMARC — governs outgoing mail: how a receiving server decides whether to trust something your domain sent. MX (Mail Exchange) records do the opposite job. They tell the rest of the internet where to actually deliver mail addressed to your domain. When someone emails you@yourcompany.com, their outgoing server looks up yourcompany.com's MX records to find out which server is responsible for receiving that mail.

An MX record has two fields: a numeric priority (also called preference) and a hostname, written as 10 mail.example.com. — note the trailing dot, which marks the hostname as fully qualified in DNS syntax. A domain can publish several MX records at once, each with its own priority.

Lower priority numbers win. Mail always tries the lowest-numbered record first — e.g. 10 mail-primary.example.com. before 20 mail-backup.example.com. — and only falls back to a higher-numbered one if the preferred host can't be reached. Two records sharing the exact same priority number are treated as equally preferred, and a sending server is free to pick between them (commonly at random, for basic load distribution).

RFC 7505 defines a "null MX": a domain publishes exactly one MX record, priority 0, pointing at a single dot — written as 0 . — to explicitly declare "this domain accepts no mail whatsoever." It's a documented, intentional standard, not a mistake, commonly used by domains that exist purely to host a website or an API with no email use at all.

The most common real-world MX problem isn't a missing record at all — it's a dangling one. The MX record exists and points to a hostname, but that hostname itself no longer resolves to an A or AAAA record, usually left behind after a company switches email providers and forgets to clean up the old reference. Mail addressed to the domain can bounce or silently hang, even though a record technically exists and looks fine at a glance.