MX lookup

How to use it

1. Type the part of the email address after the @ in Domain name (for example example.com) and press Check, or pick an example next to Try:.
2. Read the verdict line, then the table: Priority, Mail server, IP addresses and Provider.
3. Scroll to Whole email setup to see whether SPF, DKIM and DMARC are in place too; each line opens its own checker with the domain filled in.
4. Press Copy as text to paste the result into a support ticket, or Copy link to share it.

What the result shows

The checker asks Cloudflare's public resolver (1.1.1.1) for the domain's MX records and sorts them by priority. For the first three mail servers it also looks up their IPv4 (A) and IPv6 (AAAA) addresses. A red No address! means that host name doesn't resolve, so senders can't deliver to it and have to move on to the next server.

The provider is recognised from the server's host name. A dash means the name isn't on our list, often a company's own server or a web host's mail service.

How priority works

RFC 5321, the SMTP standard, says lower numbers are preferred. Servers with the same number share the load: senders must pick among them at random. Only the order matters, so priorities 1 and 5 behave exactly like 10 and 50.

Two records that make the second server a backup:

example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.

Google Workspace needs a single record: priority 1, value smtp.google.com.

No MX record, or a null MX

With no MX record at all, RFC 5321 tells senders to treat the domain's own address (its A or AAAA record) as an implicit mail server. That usually points to a web server that doesn't accept mail, so messages bounce after the sender gives up retrying.

A domain that never receives email should say so with a null MX (RFC 7505): one record with priority 0 and a single dot as the host, example.com. IN MX 0 .. It must be the only MX record. Senders then fail at once instead of retrying for hours or days. Add v=spf1 -all in the /spf-checker to state that the domain sends no mail either.

Mistakes this lookup reveals

• An MX that names an alias. RFC 2181 (section 10.3) says the host in an MX record must not be a CNAME. Use the server's real name.
• The domain added twice. Some DNS panels append your domain to whatever you type, which turns mx1.example.com into mx1.example.com.example.com. The table then shows No address!. Google's setup guide notes that some registrars need a final dot, others don't.
• Old servers left behind. After moving provider, MX records of the old one can still take part of the mail. Remove them once the new provider is set up.

Limits of this check

This is a DNS check only. It doesn't connect to the mail servers, because Cloudflare Workers can't open connections on port 25, so a listed server can still be down or refuse mail. Answers are cached for one minute.

Questions

Why does the MX lookup show Proofpoint or Mimecast instead of Google or Microsoft?

The MX record names the first server that receives mail for the domain. Companies often put an email security gateway there, in front of their mailbox provider, so the mailboxes themselves can be hosted somewhere else.

How long does an MX change take to work?

Resolvers may keep the old record for up to its TTL. Google's setup guide tells Workspace customers to allow up to 72 hours. Check the new value with the /dns-propagation-checker.

Do I need more than one MX record?

Not necessarily: Google Workspace asks for a single MX record. A second record only helps if it points to a real, maintained backup server.

Does the MX record affect the mail I send?

No. MX is only for receiving. Which servers may send for your domain is set by SPF and DKIM: check them with the /spf-checker and /dkim-checker.

Why do only three servers get IP addresses?

The whole email check runs within a fixed budget of DNS queries, so addresses are looked up for the three preferred servers, where a dead entry matters most.