How do you read an MX lookup result?

A result has two layers, not one

An MX lookup answers two separate questions at once, and reading the result correctly means keeping them apart. The first layer is the MX record itself: which hostnames a domain has designated as mail servers, and in what priority order. The second layer, which a plain MX query doesn’t give you, is whether each of those hostnames currently resolves to an IP address at all. RFC 1035 defines the MX record as holding only a preference number and a hostname — never an address — so AdminKit’s MX lookup tool runs a second round of A/AAAA lookups against each returned host (up to 5) specifically to close that gap, showing at a glance whether a correctly-listed host can actually be reached, not just whether it appears in the record.

Reading the priority column

Each row in the result pairs a hostname with a priority (preference) number, and the rule is always the same: lower numbers are tried first. A domain listing 10 mail1.example.com and 20 mail2.example.com is telling every sending server to attempt mail1 first and fall back to mail2 only if mail1 is unreachable. Two or more hosts sharing the identical priority number form a single, equally-ranked group instead — a sending server may try either one, in either order — which is how organizations spread load across more than one mail server without declaring a strict primary/backup relationship. The mechanics of ties, fallbacks and the “null MX” convention for domains that handle no mail at all are covered in more depth in what MX record priority actually does; this guide focuses on reading the result you’re looking at right now rather than re-deriving that logic.

When a listed host doesn’t resolve

The single most useful thing the second A/AAAA round tells you is the difference between a host that’s merely listed and one that’s actually reachable. A host with no A or AAAA record cannot receive an SMTP connection, full stop — a sending server has no address to connect to, regardless of how correctly its priority is configured. This shows up in two very different ways depending on which host is affected:

• The only host, or the lowest-priority host, doesn’t resolve. Mail delivery is broken right now, not just at risk. Fix the missing record immediately.
• A higher-priority backup host doesn’t resolve. Delivery looks fine today because the primary is still working, but the redundancy you think you have doesn’t exist — the day the primary fails, there is nowhere for mail to fall back to. This is the more dangerous case precisely because nothing looks wrong until the moment it matters.

Reading a result during a mail provider migration

A lookup run mid-migration often shows something that looks like a mistake but usually isn’t: both the old and new provider’s mail hosts, or only the old ones, days after you believed the change was complete. Every DNS record carries a TTL controlling how long a resolver may cache it before re-checking the authoritative answer, so a result can briefly lag the real, current record until that TTL expires everywhere it was cached — see DNS propagation and TTL explained for how long that realistically takes. Before assuming a migration failed, re-run the lookup after the old TTL has had time to expire, and confirm you’re checking the exact domain or subdomain the new provider told you to point mail at.

An empty result isn’t automatically a problem

Not every domain is supposed to handle mail. A marketing redirect, a domain reserved purely for brand protection, or a subdomain used only for static assets can legitimately have no MX record at all. RFC 5321 does let some sending software fall back to a domain’s own A/AAAA record as an implicit mail host when no MX record exists, but that fallback isn’t consistently implemented across senders, so it’s fragile to rely on either way — for a domain, by design. RFC 7505 standardizes a cleaner way to express that intent explicitly: a single MX record pointing at . (the DNS root), known as a null MX, telling any sender unambiguously not to bother trying. An empty MX result on a domain that’s never meant to send or receive mail is fine as-is; an empty result on a domain you expect to receive mail is the actual problem worth investigating, and is a strong sign no one has configured mail routing for it yet.

What this result doesn’t confirm

A resolving A/AAAA record next to a mail host confirms only that the host exists on the network — nothing about whether it’s actually running a mail server, listening on port 25, or willing to accept a given message. That requires a live SMTP connection, which this lookup deliberately doesn’t attempt. Once you’ve confirmed mail is routing to the host you expect, the next question is usually whether messages sent through it will be trusted rather than rejected or marked as spam, which is a separate authentication layer covered in SPF, DKIM and DMARC explained. Run AdminKit’s MX lookup first to confirm routing, then check authentication separately rather than assuming one implies the other.