What does MX record priority actually do, and what commonly goes wrong?

The one rule that matters: lower goes first

Every MX record published for a domain carries two pieces of information: a hostname (the mail server) and a priority number, which RFC 1035 formally calls the “preference” value. The rule is simple but counterintuitive to anyone used to “priority 1” meaning “most important” in everyday software: in DNS, lower preference numbers are tried first. A domain publishing 10 mail1.example.com and 20 mail2.example.com tells every sending mail server to attempt mail1 first, and only fall back to mail2 if mail1 is unreachable — not simultaneously, and not in reverse. AdminKit’s MX lookup tool shows both the priority and hostname for every MX record a domain publishes, plus a second round of A/AAAA lookups for each listed host, so you can see at a glance whether a correctly listed host actually resolves.

Why domains list more than one MX host

Listing a primary host at a low priority and one or more backups at higher priorities is the standard way to build redundancy into mail delivery without needing a dedicated load balancer in front of the mail server itself. If the primary host is down, overloaded, or temporarily refusing connections, a well-behaved sending server retries against the next-highest-priority host rather than simply giving up and bouncing the message immediately. This is also why a backup MX host needs to be a real, working mail server for the domain — it genuinely gets used, just less often, and an organization that lets its backup rot (wrong configuration, expired certificate, no monitoring) can end up silently losing mail during exactly the outage the backup was supposed to cover for.

Ties: when two records share a priority

Two or more MX records can legitimately share the identical priority number. When that happens, RFC 1035 treats them as a single group with no preference between them — a sending server may pick either one, in either order, which functions as simple load balancing across the group rather than a strict primary/backup relationship. This is a deliberate design, not an error state, and it’s common for organizations that run two or more mail servers behind the same priority specifically to spread load rather than to express a fallback order.

What happens with no MX record

A domain is not strictly required to publish an MX record to ever receive mail. RFC 5321, the core SMTP specification, allows sending servers to fall back to a domain’s own A or AAAA record as an implicit mail host when no MX record exists — historically a convenience for very simple setups. In practice, this fallback is inconsistently implemented across different sending software, so relying on it is fragile: a domain that genuinely wants to receive mail reliably should publish explicit MX records rather than depend on every sender correctly implementing the fallback path.

The opposite problem: domains that should never receive mail

Plenty of domains — a marketing redirect, a domain parked for brand protection, a subdomain used only for static assets — never send or receive mail at all and should say so explicitly rather than leaving it ambiguous. RFC 7505 standardizes exactly this case: a single MX record with the target hostname set to . (the DNS root), known as a “null MX.” It tells any sending server attempting to deliver mail to that domain, unambiguously, that no mail service exists there at all, rather than leaving the sender to guess from an absent MX record whether it should try the A/AAAA fallback. Domains that will never handle mail are increasingly expected to publish this record as part of baseline DNS hygiene.

Common misconfigurations worth checking

• A backup MX host that no longer exists or no longer resolves — invisible until the primary fails, at which point mail silently has nowhere reliable to go.
• MX records pointing at a bare IP address instead of a hostname — not valid per the DNS MX format, which requires a hostname that is then separately resolved to an IP.
• Forgetting that a resolving MX hostname isn’t the same as working mail delivery — confirm the host is actually accepting connections and correctly authenticating mail, covered in SPF, DKIM and DMARC explained, rather than stopping at “the DNS lookup succeeded.”
• Leaving MX records in place on a domain that no longer sends or receives mail, instead of publishing an explicit null MX, which can leave the domain’s mail-handling intent genuinely ambiguous to senders and automated reputation systems alike.

Run AdminKit’s MX lookup first to see exactly what’s currently published and whether each host resolves, then use the DNS lookup tool if you need to check any other record type the same mail infrastructure depends on.