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

Google Workspace:

1 aspmx.l.google.com
5 alt1.aspmx.l.google.com
5 alt2.aspmx.l.google.com

Microsoft 365:

0 example-com.mail.protection.outlook.com

A domain that accepts no mail:

0 .

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 . — a lone dot in place of a hostname — is Null MX, defined in RFC 7505. It 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.

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.