MX lookup
Enter a domain to list its MX records: the mail servers that accept its email, in the order they're tried. Common providers such as Google Workspace and Microsoft 365 are recognized.
You'll see the mail servers in the order senders try them, their addresses, the email provider, and any problems with fixes.
- Looks up public DNS records only
- Free, no sign-up
- Works on phone and desktop
How to look up MX records
- 1
Type a domain, such as example.com, or paste an email address.
- 2
Click Look up MX to list its mail servers in the order senders try them.
- 3
See which provider handles the mail and the addresses each server resolves to.
- 4
Fix anything flagged, such as a server that no longer exists, then look up again.
Features
Priority order
Mail servers sorted by preference, the order every sending server follows, with their IPv4 and IPv6 addresses.
Provider recognized
Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, iCloud, Cloudflare Email Routing, Mimecast, Proofpoint and more.
Mistakes flagged
MX records pointing at an IP address, an alias or a host that no longer exists, plus null MX and missing MX explained.
Public DNS only
Looked up through Cloudflare's resolver. Nothing is sent to the mail servers themselves.
What MX records do
MX (mail exchanger) records answer one question: where should email for this domain be delivered? When a server has a message for jane@example.com, it looks up the MX records of example.com, sorts them by preference, and connects to each in turn until one accepts the message. RFC 5321, the standard for SMTP, describes this process in section 5.1.
MX records only cover receiving. They say nothing about which servers may send mail as your domain; that is SPF's job, with DKIM and DMARC alongside it.
How to read MX records
A fictional company with its own mail server and a backup might publish:
example.com. MX 10 mx1.example.com. example.com. MX 10 mx2.example.com. example.com. MX 20 backup.example.net.
Senders split mail between mx1 and mx2, which share preference 10, and use the backup only when neither answers. The numbers are relative: 10 and 20 work exactly like 1 and 2. Each host name must have its own A or AAAA record with the server's address, which this lookup shows next to every server.
Most businesses use a hosted provider instead, and the host names reveal which one:
| Provider | MX host names look like |
|---|---|
| Google Workspace | smtp.google.com, or aspmx.l.google.com and alt1–alt4 on older setups |
| Microsoft 365 | example-com.mail.protection.outlook.com |
| Zoho Mail | mx.zoho.com, mx2.zoho.com, mx3.zoho.com |
| Proton Mail | mail.protonmail.ch, mailsec.protonmail.ch |
| Fastmail | in1-smtp.messagingengine.com, in2-smtp… |
| Cloudflare Email Routing | route1.mx.cloudflare.net to route3 |
Security gateways such as Mimecast, Proofpoint and Barracuda sit in front of the mailbox provider, so their names appear in the MX records instead of Microsoft's or Google's.
Null MX, implicit MX and domains without mail
A domain that never receives email should say so with a null MX: one record, 0 ., as defined in RFC 7505. Senders then reject mail to it immediately rather than retrying for days. Pair it with v=spf1 -all and a DMARC p=reject record so nobody can send as the domain either.
With no MX records at all, senders fall back to the domain's own A or AAAA address, called an implicit MX. That is usually a web server, so the mail waits in queues and eventually bounces. This lookup tells you which of these cases applies.
Common MX mistakes
- Pointing at an IP address.
10 192.0.2.25is invalid; create a name such as mail.example.com with an A record and point the MX at it. - Pointing at an alias. RFC 2181 forbids an MX host that is a CNAME. Use the name the alias points to.
- Leftovers from an old provider. MX records for two mailbox providers split your mail between them unpredictably.
- A host that no longer exists. Senders skip it, and if every host is broken, mail bounces.
- Forgetting the TTL. Lower it a day before switching providers, so the change spreads within minutes.
MX records and email authentication
Changing where you receive mail often changes how you send it too. After a move, update the SPF record so the new provider may send (check it with the SPF checker), publish the new provider's DKIM key (verify it with the DKIM checker), and confirm your DMARC report address still reaches a working mailbox with the DMARC checker. An mx term in your SPF record allows your receiving servers to send, which is only right if they really do send your mail; with hosted providers they usually don't.
Frequently asked questions
What is an MX record?
A DNS record that names a server accepting email for a domain, with a preference number. When someone emails you@example.com, their mail server looks up example.com's MX records and delivers to the server with the lowest number first.
What does the MX priority (preference) number mean?
Lower numbers are tried first; only the order matters, not the size of the numbers. Servers with the same number share the load at random. Higher numbers act as backups when the first choice is busy or down.
What is a null MX record?
A single MX record of "0 ." (preference 0, host a single dot), defined in RFC 7505. It says the domain accepts no email, so senders give up at once instead of retrying for days. Use it on domains that never receive mail.
What happens if a domain has no MX records?
Senders fall back to the domain's own A or AAAA address, the "implicit MX" of RFC 5321. If that address is a web server that doesn't accept mail, messages sit in queues and then bounce. Add MX records, or a null MX if the domain shouldn't get mail.
How do I change my email provider without losing mail?
Lower the MX records' TTL a day ahead, create the mailboxes at the new provider, replace the MX records with the new provider's, and keep the old mailboxes for a few days to catch mail sent before the change spread. Then update SPF and DKIM for the new provider.
Can an MX record point to an IP address or a CNAME?
No to both. RFC 5321 requires a host name, so an address like 192.0.2.1 is read as a name that doesn't exist. RFC 2181 says the host must not be an alias (CNAME); many senders cope, but some don't. Point the MX at a host with its own A or AAAA record.
More free tools
- Password GeneratorStrong random passwords and passphrases.
- Password Strength CheckerHow long a password would take to crack.
- Password Leak CheckIs your password in a known data breach?
- Encrypt a FileLock any file with a password (AES-256).
- File ChecksumVerify a download with SHA-256 or MD5.
- Link Safety CheckerSpot fake and dangerous links before you click.
- SPF CheckerValidate a domain's SPF record.
- DKIM CheckerFind and check a DKIM key by selector.
- DMARC CheckerSee and explain a domain's DMARC policy.