Glossary
What is an MX record?
An MX record is a DNS record naming the mail server that accepts email for a domain, with a priority number that orders the alternatives. Without one, a domain cannot receive mail — which is what verification checks after syntax.
Also known as Mail exchanger record · Mail exchange record · MX
How to read one
An MX record has two parts: a preference number and a hostname. Lower numbers are tried first, so 10 aspmx.l.google.com is preferred over 20 alt1.aspmx.l.google.com. Equal preferences are a load-balancing instruction — a sender should distribute between them. The record type is defined in RFC 1035 and the routing rules in RFC 5321 §5.
The hostname is usually the clearest signal of who actually runs a domain’s mail, whatever the brand on the website: *.google.com for Google Workspace, *.mail.protection.outlook.com for Microsoft 365, *.pphosted.com for Proofpoint in front of something else. That matters for verification because receiving platforms differ in how they answer probes — some confirm mailboxes, some defer first, some refuse to distinguish at all.
A hostname in an MX record must resolve to an address record. A name that points at a CNAME is not valid here, and an MX pointing at an IP literal is not valid either, even though both appear in the wild and some senders tolerate them.
Null MX, and what "no MX" really means
A domain that will never receive mail can say so explicitly. RFC 7505 defines a null MX: a single record with preference 0 and a root-label target, written 0 .. It is a positive statement — "this domain does not accept mail" — and a sender meeting one should fail immediately rather than retry for days.
That is different from a domain with no MX record at all, which under RFC 5321 falls back to the domain’s own address record. And both are different again from a DNS lookup that failed — a SERVFAIL or a timeout. The first two are answers; the third is the absence of one, and treating a resolver incident as "this domain is dead" marks live domains invalid for everyone using the tool that day.
How VerifyInbox handles it
MX resolution sits between the syntax check and the mailbox probe, and its three outcomes stay distinct. A domain with usable MX records continues to the probe. A domain with a null MX or no mail route at all is undeliverable, with the reason no_mx — or domain_not_found where the resolver said the domain does not exist, because "the domain is gone" and "the domain takes no mail" are different things to tell a customer. A DNS failure is unknown / dns_error and retryable, never undeliverable. Every result carries mxFound and the mxRecords array it resolved.
| What DNS said | Result |
|---|---|
| Usable MX records | Continues to the mailbox probe; mxFound: true |
| Null MX, or no mail route | undeliverable / no_mx |
| The domain does not exist | undeliverable / domain_not_found |
| SERVFAIL, timeout or resolver error | unknown / dns_error, retryable: true, not charged |
Looking one up
From a terminal: dig +short MX example.com or nslookup -type=mx example.com. Or use the MX record lookup, which also names the provider behind the hostnames, since that is usually the thing you actually wanted to know.
If you are checking a domain’s sending setup rather than its receiving setup, the MX record is not the relevant record — SPF, DKIM and DMARC are, and the SPF and DMARC checker reads those. The two sides are independent: a domain can receive mail perfectly and be wide open to spoofing.
See which mail servers accept mail for a domain, and who runs them. No account, and it runs now: MX record lookup
Related terms
Sources
- RFC 1035 — Domain Names: Implementation and Specification
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 7505 — A "Null MX" No Service Resource Record
Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.