MX Lookup
A domain's mail servers: priorities, IP addresses, PTR and setup errors.
MX record lookup: a domain's mail servers
MX records tell senders which servers accept mail for a domain and in what order. This tool queries the MX records, sorts them by priority, resolves each server to IPv4 and IPv6, looks up PTR records and the mail provider, and flags the mistakes that make mail disappear: MX pointing to an IP or a CNAME, servers with no address, private IPs, a null MX mixed with normal records.
How to Use
- Enter a domain (or an e-mail address — we take the part after @)
- Compare the servers and provider with where your mail actually lives
- Fix the listed errors, then check SPF, DKIM and DMARC
FAQ
What the MX lookup shows
An MX (Mail Exchanger) record tells senders which server accepts mail for a domain. This MX lookup queries the records, sorts them by priority, resolves each server to IPv4 and IPv6, fetches the PTR (reverse) name and recognises the mail provider from the host names. It then flags the mistakes that make mail bounce or vanish.
| Flag in the table | Meaning | Fix |
|---|---|---|
| does not resolve | The MX host has no A/AAAA records | Correct the MX name or give the host an A record |
| IP instead of name | An IP address was entered as the MX | Create an A record like mail.yourdomain and use it in the MX |
| CNAME | The MX points to an alias | Use the final name the CNAME points to |
| private IP | An address such as 10.x, 192.168.x, 127.x | Publish the server's public address |
| null MX | The domain declares it accepts no mail | Nothing, if the domain does not need e-mail |
How MX priority works
Senders pick the server with the lowest priority number and fall back to the next one if it is unreachable. Servers with equal priority share mail randomly. The numbers themselves do not matter: 1 and 5 behave exactly like 10 and 50. A classic setup:
example.com. 3600 IN MX 10 mx1.example.com. example.com. 3600 IN MX 20 mx2.example.com.
A backup MX makes sense for a self-hosted server. Hosted mail (Google Workspace, Microsoft 365) runs many servers behind one name, so a single MX record is normal there. Senders retry delivery for days even without a backup MX, so a short outage does not lose mail. What matters more: a backup MX must filter as strictly as the primary, or spammers will route through it.
Null MX: a domain with no e-mail
If a domain receives no mail (a landing page, a redirect domain, a technical domain), publish a null MX per RFC 7505 — a single record with priority 0 and a dot instead of a host:
example.com. IN MX 0 .
Senders bounce immediately with a clear error instead of knocking on the website's A address for days. A null MX must not be mixed with other MX records — the tool flags that. Full lockdown for a domain without mail is null MX, SPF v=spf1 -all and DMARC v=DMARC1; p=reject; verify them with the SPF checker and the DMARC checker.
No MX records: the implicit MX
With no MX at all, RFC 5321 tells senders to try the domain's own A/AAAA address. That is usually a web server that does not accept mail, so messages sit in queues and bounce days later. The tool lists those addresses separately. The fix is either your provider's MX records or a null MX.
Typical MX records of popular providers
| Provider | MX (per provider docs) |
|---|---|
| Google Workspace | 1 smtp.google.com (older setups use five records: aspmx.l.google.com and alt1…alt4) |
| Microsoft 365 | 0 yourdomain-tld.mail.protection.outlook.com (newer domains may get a name under mx.microsoft) — the admin center gives the exact name |
| Zoho Mail | mx.zoho.com, mx2.zoho.com, mx3.zoho.com (zoho.eu for the EU) |
| Proton Mail | 10 mail.protonmail.ch, 20 mailsec.protonmail.ch |
These values change, so copy them from your provider's setup guide and use this page to verify the result. If the detected provider is not where your mailboxes live, the MX records are left over from a previous service and mail is going there.
PTR and mail server reputation
A PTR record maps an IP address back to a name. It matters little for inbound MX, but if the same server also sends mail, receivers check that the IP has a PTR and that the name resolves back to the same IP. Without that, mail from a self-hosted server often lands in spam. The IP owner — your host or ISP — sets the PTR; check it in detail with reverse DNS and the address reputation with the blacklist check.
Checking MX from the command line
dig +short MX example.com nslookup -type=mx example.com
After an MX change the old record stays in resolver caches until its TTL (shown in the table) expires. Before migrating mail, lower the TTL in advance and keep the old mailbox running until everyone sees the new MX — the DNS propagation checker shows when that happens.
MX covers inbound mail only
Correct MX records make sure mail reaches you. Whether your own messages reach the recipient's inbox depends on SPF, DKIM and DMARC. Next, check SPF, DKIM and DMARC — links to all four checks sit above the result as well.