MX lookup.
MX records route incoming mail to a domain's mail servers. They do not authenticate outgoing mail. Look up a domain's MX hosts in the order senders try them.
What this check can tell you
The result lists each MX host with its preference, lowest first, and says what the answer means for receiving email: working hosts, no MX records, a null MX that refuses mail, or a host given as an IP address. To see how the same domain authenticates mail it sends, run the email authentication checker.
Limit: This reads the MX answer only. It does not connect to the mail hosts, so it cannot prove a server is up or accepting mail.
How to read the MX result
A table lists the hosts. The findings say what that answer means for receiving mail.
- Preference
- A number from 0 to 65535. Senders try the lowest first and fall back to higher numbers. Hosts that share the lowest number share incoming mail.
- Mail host
- The hostname that accepts mail. It needs its own A or AAAA record. This tool does not resolve it.
- MX records found
- Pass. A single host means no backup is listed. Several hosts at one preference share first position, and higher numbers are fallbacks.
- No MX records
- Warning. Senders fall back to the domain's own A or AAAA record. Most domains run no mail server there, so mail bounces or is delayed. The tool does not look up those addresses.
- Null MX
- Warning. The domain publishes
0 .and accepts no mail. That is intended for domains that should never receive it. - Host is an IP address, or a bad null MX
- Fail. An MX must name a host, not an IP. A null MX must have preference 0 and be the only MX record.
MX is for receiving, not sending
Your MX records can point at one provider while another sends your mail. A domain with mailboxes on one service can send app email through a different one. Whether receivers trust what you send depends on SPF, DKIM, and DMARC. Inspect the SPF record next if you are debugging outgoing mail.
MX still matters for sending in one place. Some sending services ask for an MX record on a return-path subdomain so bounces come back to them. Look up that subdomain here. If you want replies to reach your app instead of a mailbox, see inbound email.
An annotated set of MX records
Two primary hosts that share load and one fallback.
example.com. MX 10 mx1.mailhost.example.
example.com. MX 10 mx2.mailhost.example.
example.com. MX 20 backup.mailhost.example.What each part does
10- The preference. Both hosts share the lowest number, so senders pick between them.
20- A fallback. Senders try it only when both preference 10 hosts fail.
mx1.mailhost.example.- A hostname with its own A or AAAA record. The trailing dot makes it fully qualified.
0 .- Not in this example. Published alone, it is the null MX: the domain accepts no mail.
Common MX problems and fixes
- No MX records, but the domain should receive mail
- Publish your mail provider's MX hosts at the domain. Copy each host and preference exactly as the provider lists them.
- The old provider still gets mail after a move
- Remove the old MX records. Resolvers keep the previous answer until its TTL expires, so lower the TTL before a migration.
- MX points at a CNAME
- Point the MX at the final hostname, the one with A or AAAA records. This tool does not resolve targets, so confirm the host with a DNS query.
- MX is an IP address
- Create a hostname with an A or AAAA record for that IP and point the MX at the hostname.
- Mail to a subdomain bounces
- MX records are not inherited. Publish MX records on the subdomain, or a null MX if it should accept none.
- Null MX mixed with other records
- Keep either
0 .alone, or your provider's hosts. RFC 7505 makes the null MX the only record.