MX Lookup

What the MX Lookup checks

When someone sends you email, their server asks DNS for your domain's MX records. It then connects to the listed hosts, lowest priority number first. This tool runs the same lookup and checks the answer.

For each domain it reports:

• Each MX record, with its priority (preference) and target hostname.
• Whether each target resolves to an IPv4 (A) or IPv6 (AAAA) address.
• Common mistakes, such as an MX target that is an IP address, a CNAME, or a host that doesn't exist.
• Null MX (MX 0 .), which means the domain intentionally accepts no mail (RFC 7505).

How to read the results

• Pass. At least one MX record exists and every target resolves to an address.
• Warning. Mail can be delivered, but something is fragile. Examples: one of several MX hosts doesn't resolve, or every MX host is a single server with no backup when you expected redundancy.
• Fail. Senders can't deliver. Examples: no MX record and no fallback address, every MX target fails to resolve, an MX target is an IP address, or Null MX is mixed with other MX records.
• Not tested. The DNS query timed out or the domain's name servers didn't answer. Try again later.
• Not applicable. The domain publishes Null MX. It doesn't receive mail by design, so delivery checks don't apply.

About priorities

Lower numbers are tried first. Records with the same number share the load. A typical setup with two filtering hosts looks like this:

example.com.  MX  10 mx1.filter.example.net.
example.com.  MX  20 mx2.filter.example.net.

The numbers themselves don't matter, only their order.

Common problems and fixes

Old MX records left behind after a migration. If you move to a filtering service but leave your old mail server's MX in place, some senders will deliver to the old host and skip filtering. Remove every MX record that doesn't belong to the new path.

MX target is an IP address. This isn't valid. Create a hostname with an A record and point the MX at the hostname:

mail.example.com.  A   203.0.113.25
example.com.       MX  10 mail.example.com.

MX target is a CNAME. Mail standards say MX targets must not be aliases. Point the MX directly at the final hostname.

No MX record at all. If no MX exists, standard SMTP falls back to the domain's own A or AAAA record. That's rarely what you want. Either publish proper MX records or, if the domain shouldn't receive mail, publish Null MX.

Domain that doesn't receive mail. Publish Null MX on its own and lock down sending too:

example.com.          MX   0 .
example.com.          TXT  "v=spf1 -all"
_dmarc.example.com.   TXT  "v=DMARC1; p=reject;"

A domain set up this way isn't failing. It's telling senders clearly not to try.

Microsoft 365 or Google Workspace behind a filtering gateway. When your MX points to a filtering service, Microsoft 365 sees mail arriving from that service rather than from the original sender. Microsoft documents Enhanced Filtering for Connectors for this case, so Microsoft 365 can still evaluate the original sender's SPF, DKIM and DMARC. Google Workspace has an equivalent inbound gateway setting.

Limitations

• An MX lookup can't prove mail is filtered. It shows where senders are told to go, not what your mail server accepts. To stop senders bypassing your filter, restrict your mail server so it only accepts inbound mail from the filtering service's addresses.
• It doesn't test whether the server accepts connections on port 25, offers STARTTLS, or accepts mail for a given address.
• DNS answers are cached. A record you just changed may still show the old value until its TTL expires.
• It shows the public view of DNS. Internal or split-horizon DNS can return different answers inside your network.

Related

For a full picture of routing, authentication and transport security, run the Email Health Check. To understand why mail lands in junk even when MX is correct, read Why did this email land in spam?.