MX record lookup
Enter a domain. We return its mail exchangers in priority order and resolve each hostname to an address, which is where dead entries show themselves.
What the MX records give away about a domain
The hostnames tell you who runs the mail, and that matters more than it looks. A domain pointing at aspmx.l.google.com is on Google Workspace. One pointing at mail.protection.outlook.com is on Microsoft 365. Both of those providers block verification probes from cloud addresses, so knowing the host tells you in advance how hard the domain will be to check.
A domain on Yahoo's infrastructure is a different problem. Yahoo accepts every recipient during the SMTP conversation by design, to stop people harvesting valid addresses, then bounces later if the mailbox is not real. Any verifier claiming a definite verdict there is guessing.
Priority numbers are where people read meaning that is not there. Lower goes first, the gaps are arbitrary, and equal numbers share the load. A backup exchanger on a higher number is only useful if it actually queues and forwards, and plenty of them were set up once and never tested.
| What you see | Who runs it | What it means for checking |
|---|---|---|
| aspmx.l.google.com | Google Workspace | Probes from cloud addresses are blocked |
| mail.protection.outlook.com | Microsoft 365 | Answers inconsistently and throttles hard |
| mta*.am0.yahoodns.net | Yahoo | Accepts every recipient, then bounces later |
| No MX, only an A record | Someone's own server | Delivery depends on port 25 being open there |
| No MX and no A record | Nobody | Undeliverable, every address at the domain |
Host patterns as published by each provider, checked September 2026.
An exchanger that does not resolve
This is the fault worth looking for, and a plain MX listing hides it. An MX record points at a hostname, and that hostname needs an A record of its own before anyone can connect to it. When it has none, a sender cannot open a connection and falls through to the next exchanger.
With a working backup that costs you a delay nobody notices. With only one exchanger it costs you the mail. We resolve each host for exactly this reason, and a missing address is flagged rather than left for you to spot.
Questions people ask
How many MX records should a domain have?
Whatever the mail provider tells you to publish. Google Workspace now uses one, Microsoft 365 uses one, and older setups often list five. More records is not more reliable if they all point at the same place.
Does an MX change take effect immediately?
No. Resolvers cache the old answer until its TTL expires, so mail keeps arriving at the previous host for that long. Lower the TTL a day before a migration and raise it again afterwards.
Why does a subdomain have no MX record?
Because MX records do not inherit. Mail to anything@news.example.com needs its own MX at news.example.com, and without one the sender falls back to that subdomain's A record rather than the parent's mail servers.
Can I tell how big a company is from its MX records?
Not really. A thousand-person company and a one-person company both show a single Google entry. The records describe the provider, not the organization behind them.
The MX lookup is step two of five
After the records comes the SMTP conversation, where the receiving server either accepts an address, rejects it, or refuses to say. We report all three.