MX Record Lookup

What an MX record is

An MX record answers the question "where should mail for this domain be delivered". When a sending server sees the address john@example.com, it queries the MX records for example.com and gets back a list of mail server names with priorities. It then resolves those names to IP addresses and connects to the first one that responds.

Without MX records a domain accepts no mail. This is the first thing validation services check: if a domain has no MX, every address on it is undeliverable and there is no point looking further.

What the lookup shows

Besides the server list with priorities you get the IP addresses each name resolves to and the provider detected from those names, whether Google Workspace, Microsoft 365, Zoho and so on. It is a quick way to learn whose mail platform a company runs on before you contact them.

Two failure modes that a DNS panel will not reveal are checked separately: an MX pointing at a CNAME (forbidden by RFC 2181) and an MX whose hostname resolves to no address at all. In both cases the record looks fine in the panel while some mail never arrives.

Records used by popular providers

Here is what the records look like at the big mailbox providers, as pulled from DNS on September 17, 2026. For business plans the MX column shows the pattern the provider tells you to publish.

How to read the priorities

The number before each hostname is the priority, and lower means higher. A sender starts with the smallest number and moves on only when that server does not answer. The absolute values carry no meaning: 10/20 behaves exactly like 1/2.

Equal priorities on several records are not a mistake but load balancing, and the sender picks between them at random. That is precisely how Google Workspace is laid out, with two backup hosts sharing weight 5.

Which brings up the usual misconception about a "backup MX". An extra server with a higher number helps only if it can genuinely accept mail and later hand it to the primary. An empty backup that accepts messages and forwards them nowhere is worse than none at all: when the primary fails the sender gets a delivery confirmation and the mail vanishes. With no backup the sender simply waits and retries, because queues live for several days.

The mistakes we see most

• An IP address instead of a hostname. Only a domain name is valid in an MX. A record like 10 192.0.2.25 is rejected outright by some servers and treated as a name by others, which also fails to deliver.
• A hostname pointing at a CNAME. Forbidden by RFC 2181. Google and Microsoft cope with it, stricter servers do not, and the losses look random.
• A missing trailing dot. Most panels append the domain automatically, so mx.example.com without the dot becomes mx.example.com.example.com. The lookup surfaces this immediately, since the name resolves to nothing.
• Leftovers from a previous provider. Old MX records routinely survive a migration. They keep accepting a share of the mail, which then sits in a mailbox nobody opens.
• MX updated, SPF forgotten. Receiving mail and being authorised to send it are separate things. Changing mail provider means editing both records.

Null MX: a domain that takes no mail

A record of 0 ., with a single dot where the hostname should be, is Null MX as defined in RFC 7505. example.com, the domain reserved for documentation, is set up exactly this way. The record states explicitly that the domain accepts no mail, so senders fail immediately instead of holding the message in a queue for a week.

It belongs on every domain you never correspond from: parked domains, redirects, internal ones. Senders get a clear rejection at once, and the domain stops being a convenient return address for forgery. Null MX only works alone: placed alongside a normal MX record it becomes an invalid configuration.

MX checks inside email validation

In a uChecker list cleaning job the MX lookup is step two, right after syntax. We take everything after the @, ask DNS for its MX records, and the answer decides whether the address is worth an SMTP conversation at all.

• MX records come back. The domain takes mail, so the address moves on to the SMTP stage.
• There is no MX but the domain has an A record. RFC 5321 lets a sender deliver straight to that address in this case (the "implicit MX" rule), so we do not reject the address outright, we just trust it less.
• Neither MX nor A exists. Nobody is there to accept the message, and the address is dead.
• DNS says NXDOMAIN. The domain is not registered at all, which usually means a typo or a project somebody let lapse years ago.

Why this order? A DNS answer takes milliseconds, while an SMTP session can take several seconds and may run into greylisting, so throwing out dead domains before a single connection is opened saves most of the time on a large list.

Keep TTL in mind too. A domain registered an hour ago, or one that has just switched mail providers, can still resolve to old records until caches expire, and a borderline result is worth re-checking later.

Why MX alone is not enough for validation

An MX record means the domain is prepared to accept mail. It says nothing about a specific mailbox. A domain can be configured perfectly while the address on it was deleted a year ago. So an MX check is only the first filter: it removes typo domains and dead domains wholesale, and an SMTP check of the individual address has to follow.

The second wrinkle is catch-all. When a domain accepts mail at any address, the SMTP response is positive for a mailbox that does not exist. The only way to spot one is to probe a deliberately random address; in a uChecker report those addresses get their own status rather than being passed off as valid.