DNS
MX lookup
See where a domain receives mail, in priority order, with the faults that stop it.
Free, no accountLive check
Result
The verdict appears here once you press Look up MX records.
What this is
This MX lookup reads the mail exchanger records a domain publishes, puts them in the order a sending server actually tries them, names the provider behind them where it can be recognised, and checks each host for the two faults that quietly stop mail: an alias where a host should be, and a host with no address.
An MX record is how a domain says which servers accept its mail. Each record has a priority and a host: a sending server collects them all, sorts them by priority with the lowest number first, and tries them in that order until one accepts the message. Two records with the same number are tried in no particular order, which is how a provider spreads mail over several machines.
The records belong to the domain in the email address, not to the mail server. That is why changing mailbox provider is a change to your own DNS: the new provider gives you MX records to publish, and until they are published mail keeps going to the old one.
How to read the result
The table is the delivery order, top to bottom. "Resolves to" is what each host actually points at, which is where two faults show up: a host that is an alias (a CNAME) is forbidden as an MX target by RFC 2181 and some senders refuse it, and a host with no address cannot be connected to at all.
A green verdict means the records are published and every host resolves. It does not mean mail is being accepted - nothing here connects to a mail server, deliberately, because a tool that opens connections to strangers’ mail servers gets its address blocked.
Common mistakes
What goes wrong most often, and how to tell.
- Pointing an MX record at a CNAMEAn MX target must be a name with its own address record. Pointing it at an alias is forbidden by RFC 2181 and is refused outright by some senders, so mail from those senders never arrives while mail from others does - which is the hardest kind of fault to diagnose.
- Pointing an MX record at an IP addressAn MX record holds a hostname. An address in that field is invalid, and a sender that follows the specification will not deliver to it. Give the address a hostname and point the record at that.
- Leaving the old provider’s records in placeAdding the new provider’s MX records without removing the old ones leaves mail arriving at both, apparently at random, depending on which priority each sender reaches first. Remove the old records in the same change.
- Reading priority as preference strengthThe lowest number is tried first, so 10 beats 20. It is not a weight or a percentage, and a bigger number is not a stronger preference.
Questions
What people ask about this tool.
- It is the order in which a sending server tries the hosts, lowest first. A host at priority 10 is tried before one at 20, and the higher number is only reached when the lower one cannot be contacted. Hosts sharing a number are tried in no particular order.
- Usually yes, by accident: RFC 5321 says a sender with no MX record to work from falls back to the domain’s address record. It works, but nothing says which host should take mail and there is no second host, so it is worth publishing a real MX record.
- That is the older Google Workspace set, with aspmx.l.google.com at priority 1 and four alternates. Google now publishes a single smtp.google.com record instead. Both work; the single record is simpler, and mixing the two sets is the mistake to avoid.
- A single record of "0 ." which says the domain receives no mail at all (RFC 7505). It is the right thing to publish for a domain you only use for a website, because a sender that honours it rejects a message immediately instead of retrying for days.
Use it from the API
The same check, as one request.