MX lookup

What an MX lookup shows

MX records answer one question for every server on the internet: where should mail for this domain be delivered? A typical Google Workspace domain answers like this:

1   aspmx.l.google.com      → 142.250.27.26
5   alt1.aspmx.l.google.com → 142.250.153.26
5   alt2.aspmx.l.google.com → 74.125.200.27
10  alt3.aspmx.l.google.com → 142.251.9.26
10  alt4.aspmx.l.google.com → 173.194.77.27

Five hosts, three priority tiers. Senders try priority 1 first, spread across the 5s when it fails, and reach the 10s only when everything above is down. This lookup performs the same resolution a sending server would, then goes one step further: it resolves every exchange hostname to its A and AAAA records, because an MX pointing at a name that resolves to nothing is a dead end that a bare MX query never reveals.

The four problems this lookup flags

No MX records at all. Senders fall back to the domain's A record under RFC 5321 §5.1 — and the machine behind a website's A record almost never runs a mail server. Mail to the domain bounces after days of retries. If the domain is meant to receive mail, this is the first thing to fix; if it is not, publish a null MX instead so senders fail fast.

A single MX host. Not fatal — sending servers queue and retry for days when the only host is down, so brief outages lose little. What a lone MX removes is your margin during longer incidents: a provider outage, an expired certificate, a botched migration. A second host at a higher priority number costs nothing and buys a fallback.

An MX pointing at an IP literal. The standard requires a hostname. Some receiving software tolerates the IP form; enough of it refuses that delivery becomes inconsistent in ways that are miserable to debug. The fix takes two records: an A record for a name, an MX pointing at the name.

An exchange that doesn't resolve. The MX record survives, the server behind it is gone. Common after migrations, when someone removes the old mail host's A record but forgets the MX pointing at it. Every sender honoring priorities keeps knocking on a door that no longer exists before trying the next host.

MX records and deliverability

MX is the receiving half of your mail setup, but it still touches your sending reputation in two ways. First, many receivers check that a sending domain can itself receive mail — a domain with no MX and no fallback looks like a throwaway, and some filters score it accordingly. Second, your MX hosts reveal your mail architecture: a quick lookup tells anyone which provider hosts your inbound mail, which is why this tool is as useful for reconnaissance on a vendor as for auditing your own DNS. Run it against any of the email services we review and you can see whose infrastructure actually answers.

What MX records do not decide is inbox placement for the mail you send. That comes down to authentication, reputation, and content — the first of which you can verify right now with the email authentication checker, and the last of which we measure directly with seed-list tests documented in our methodology.

A clean MX result plus verified SPF and DMARC covers the DNS layer of your mail setup. From there, deliverability is earned per campaign — see how the major platforms score in our deliverability rankings.

Frequently asked questions