MX Lookup
Which servers receive mail for a domain — and can senders actually reach them?
Look up mail servers
Looking up…
Mail servers
About the MX Lookup
Senders deliver e-mail to the servers listed in a domain’s MX records, trying the lowest preference number first. This lookup lists them in that order, resolves every server’s IPv4 and IPv6 addresses, checks each address’s reverse DNS and whether it resolves back (forward-confirmed reverse DNS), and tells you which provider handles the mail — Google Workspace, Microsoft 365, Zoho, Proton, Fastmail and many more, or a security gateway such as Mimecast or Proofpoint in front of them.
It also catches the configurations that make mail bounce or vanish: a null MX that refuses all mail (RFC 7505), no MX at all (senders then fall back to the domain’s web server), MX targets that are aliases or IP addresses, servers that do not resolve, private addresses, and MX records split between two providers after a migration.
How to use it
- Enter a domain (
example.com) or an e-mail address ([email protected]). - Press Look up MX. The summary says who receives the mail and how many servers there are.
- Check each server: its preference, addresses, reverse DNS and any warning.
- Use Copy report or CSV for one row per address, or continue to the SPF, DMARC and DKIM checkers.
Examples
google.com
10 smtp.google.com — Google Workspace
Google Workspace now tells customers to publish a single MX, smtp.google.com; the older ASPMX records still work (Google’s setup guide).
example.com
MX 0 . — null MX: senders reject mail to it at once
icloud.com
mx01.mail.icloud.com → CNAME iscream-smtp-prod.v.aaplimg.com (warning: RFC 2181 §10.3)
Most senders follow the alias, but the standards say an MX must point straight at a host with addresses.
Common uses
- Checking that a switch to a new mail provider is complete — and that no old MX record is left behind.
- Finding out which provider a company uses before migrating it, or before contacting its postmaster.
- Debugging bounces such as “host not found” or “no route to host” for one recipient domain.
- Confirming that a parked domain refuses mail with a null MX.
How senders use MX records
- Servers are tried from the lowest preference up; equal values share the load at random (RFC 5321 §5.1).
- With no MX records, senders use the domain’s own A/AAAA address as an “implicit MX” — usually a web server, so mail is lost or bounces after days of retries.
- A null MX (
MX 0 .) says the domain receives no mail; senders give up at once with a 556 error (RFC 7505). It must be the only MX record. - An MX must name a host with address records: not an IP address, and not an alias (CNAME) (RFC 2181 §10.3).
Reverse DNS and FCrDNS
For every address the lookup asks for its reverse DNS name (PTR) and checks that this name resolves back to the same address — forward-confirmed reverse DNS. Receiving mail does not need it. Sending does: Gmail requires the IP addresses that send to it to have a PTR record whose name resolves back to the address (Google’s sender guidelines), so check it for servers that both receive and send.
How the provider is recognised
From the MX host names, which belong to the provider: smtp.google.com and *.aspmx.l.google.com (Google Workspace), *.mail.protection.outlook.com and the newer *.mx.microsoft (Microsoft 365), *.zoho.com/.in/.eu (Zoho Mail), mail.protonmail.ch (Proton), *.messagingengine.com (Fastmail), route*.mx.cloudflare.net (Cloudflare Email Routing), *.pphosted.com (Proofpoint), *.mimecast.com (Mimecast) and others. A security gateway filters mail and passes it on, so the mailbox provider behind it is not visible in DNS.
Limitations
- DNS shows where mail is delivered, not whether a mailbox exists: the lookup never connects to the servers or sends anything.
- Browsers cannot open SMTP connections, so the servers’ availability, TLS and greeting are not tested.
- Answers come from Cloudflare’s resolver and may be cached for up to their TTL after a change.
- Provider names are recognised from known host names; mail servers run by the domain itself or by smaller hosts are shown as hosts only.
Privacy
The domain, its mail server names and their addresses are looked up from your browser through Cloudflare’s DNS-over-HTTPS resolver (Google’s as a fallback). An e-mail address you enter is reduced to its domain in your browser; the part before @ is never sent anywhere. MySmartCoPilot’s servers are not involved.
Frequently asked questions
What does the MX preference (priority) mean?
Senders try the server with the lowest number first and move to higher numbers only if it cannot be reached. Servers with the same number are used in random order to spread the load. The numbers themselves do not matter, only their order.
Do I need more than one MX record?
Providers such as Google Workspace and Microsoft 365 give you one name that is served by many machines, so one record is enough. If you run your own server, a second MX at another site avoids delays while the first is down — senders queue and retry for days, so mail is rarely lost either way.
Why does it say “implicit MX”?
The domain has no MX records, so senders deliver to its A/AAAA address instead (RFC 5321 §5.1). If that is a web server, mail bounces or disappears. Publish MX records for your mail provider — or a null MX if the domain should not receive mail.
Is an MX record pointing to a CNAME a problem?
It breaks the rules (RFC 2181 §10.3 and RFC 5321 §5.1) and costs extra lookups, but most senders follow the alias anyway. Point the MX at the final host name to be safe.
Can I see whether a mailbox exists?
No. That would require connecting to the mail server, which browsers cannot do — and many servers accept every address and bounce later. The lookup only shows where mail for the domain goes.