What an MX record contains
An MX record has two parts: a priority number and the hostname of a mail server. Lower priority numbers are tried first, and equal numbers are load balanced. A domain usually publishes several records so that mail still flows when one server is down. The hostname must itself resolve to an IP address through a separate A or AAAA record, and it cannot be a bare IP.
You can look them up with the dig command on macOS and Linux or nslookup on Windows. The output below is what a typical Google Workspace domain publishes.
$ dig +short MX acme.com
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.What happens when there is no MX record
If a domain publishes no MX records, RFC 5321 says a sending server should fall back to the domain's A record and attempt delivery there. In practice that rarely works, because a web server on port 80 does not speak SMTP on port 25. A domain with a website but no MX records almost always means nobody set up email for it.
There is also an explicit way to say a domain never accepts mail: a single MX record with priority 0 and a hostname of just a dot, the null MX defined in RFC 7505. Verifiers treat both cases as undeliverable with reason no_mx_record.
Common configuration mistakes
Most MX problems come from copying a provider's instructions imperfectly. The symptoms are usually a stream of bounces reported by senders, or verification results showing the domain check passing while the MX check fails.
- The MX hostname points at a server that has no A record, so it cannot be reached.
- The MX hostname points at a CNAME, which the standard forbids and some servers reject.
- Old records from a previous provider were left in place alongside the new ones.
- The trailing dot was omitted, so the record resolves to mail.acme.com.acme.com.
- Records were updated but DNS caches still serve the old values until the TTL expires.
Why a valid MX record does not prove a mailbox exists
An MX record is a statement about the domain, not about any address on it. It says acme.com accepts mail at these servers. It says nothing about whether jane@acme.com is a real mailbox, whether it is full, or whether the server will accept it. That question can only be answered by connecting to the MX host and asking during an SMTP session.
This is why an email verifier treats MX as one stage in a pipeline. VeriDock returns the resolved mx hostnames and the detected provider in the domain field of every response, then goes on to probe the mailbox and report deliverable, undeliverable, risky, or unknown.
MX answers where mail goes. SMTP answers whether this particular mailbox will take it.
Key takeaways
0/4Try it on a real address
Run syntax, DNS, MX, disposable, and role checks on any address. No signup needed.
Enter an address and press Check.
Runs real syntax, DNS and mail-server checks.
This demo checks syntax, domain, mail server, disposable and role-address rules. Sign up free for live mailbox checks.
Frequently asked questions
Verify addresses with one API call.
250 free checks every month, recurring. Unknown results are never billed.