MX Lookup: Check MX Records

An MX record is a DNS entry that names the mail server responsible for accepting email on behalf of a domain. It exists because the domain in an email address and the machine that stores the mailbox are almost never the same thing. When a sending server has a message for jane@acme.com, it asks DNS for the MX records of acme.com, gets back a hostname such as aspmx.l.google.com, resolves that to an IP, and delivers there.

Every MX record carries two fields.

Exchange. The hostname of the mail server, for example alt1.aspmx.l.google.com.

Priority. A number that decides the order servers are tried, lowest first.

A domain can publish several MX records, which is how mail providers build in redundancy. A domain can also publish none, in which case it simply cannot receive mail, and any address at it will bounce.

Type the domain into the tool above and press look up. It queries public DNS and returns every MX record with its priority, the provider those hostnames belong to, and whether the domain publishes an SPF record. You can paste a full email address instead of a domain and it will use the part after the @.

On the command line the same query is dig MX example.com on macOS and Linux, or nslookup -type=mx example.com on Windows. Both return the raw records without the provider identification or the SPF check, and both are answering exactly the same public DNS question this tool asks.

There is nothing private about it. DNS is designed so that any mail server on the internet can find out where to deliver your mail, which is why an MX lookup needs no permission, no account, and no relationship with the domain.

Priority is the order in which sending servers try your mail servers, and lower wins. A record with priority 1 is attempted before one with priority 5. The absolute values are meaningless on their own, only the ordering matters, which is why some providers number 1, 5, 10 and others 10, 20, 30.

Lowest priority first. The sending server tries the lowest number it can reach.

Equal priorities share load. When two records carry the same value, senders distribute between them, which is how providers spread inbound traffic.

Higher numbers are the fallback. They are tried only when the lower ones do not answer, which is what keeps mail flowing during an outage rather than bouncing.

A Google Workspace domain is the canonical example: aspmx.l.google.com at priority 1, then a pair of alt records at 5, then another pair at 10. If you see a single MX record with no backup, the domain has no redundancy, and mail sent during any outage of that host is deferred or lost.

Read its MX hostnames. Mail providers route inbound mail through their own infrastructure, so the hostnames give the provider away immediately.

Google Workspace. Records ending in aspmx.l.google.com or googlemail.com.

Microsoft 365. Records ending in mail.protection.outlook.com.

Security gateways. Hostnames from Proofpoint (pphosted.com), Mimecast, Barracuda, or Cisco sit in front of the real mailbox provider and filter everything on the way in.

Everything else. Zoho, Fastmail, Proton, Amazon SES and around a dozen others each have recognizable patterns.

The tool above names the provider for you rather than making you recognize the hostnames. It is useful information for outbound: a domain fronted by a security gateway filters far more aggressively than a plain Google Workspace tenant, and knowing that before a campaign explains a lot of otherwise mysterious non-delivery.

It means the domain cannot receive email. Not that it is filtering you, not that the mailbox is full: there is no server anywhere accepting mail for that name, so every message to every address at it will bounce.

There are three usual explanations. The domain is parked, registered but never configured. The domain is used only for a website, with mail handled on a different name entirely. Or the domain has been abandoned and its DNS has been stripped back.

For an outbound team this is one of the cheapest disqualifications available. A lead whose email domain has no MX records is not a lead, and no amount of copy will change that. Cleanlist runs this check automatically on every address in a list, alongside mailbox-level verification, so dead domains never reach a sequencer in the first place.

A lookup on a Google Workspace domain returns something like aspmx.l.google.com at priority 1, alt1 and alt2 at 5, and alt3 and alt4 at 10. Here is what each part is telling you.

The hostname. Where mail is delivered. This is the field that identifies the provider.

The priority. Which host is tried first, lowest number first. Equal numbers mean load is shared between them.

The count. More records mean more redundancy. A single MX record with no backup means an outage on that host stops inbound mail entirely.

The SPF record. Not an MX record at all, but a TXT record that lists which servers are allowed to send as this domain. It is checked here because a domain with MX and no SPF is a domain whose own outbound mail is more likely to be treated as suspicious.

What you will not find in an MX record is anything about an individual mailbox. MX is a property of the domain, and it says nothing about whether jane@ exists.

The records are a small, reliable piece of technographic data, sitting in public, free to query.

Which mail platform they run. Google Workspace and Microsoft 365 account for most of the B2B market, and knowing which one a prospect uses is a genuine qualifying signal if you sell anything that integrates with either.

Whether a security gateway sits in front. Proofpoint, Mimecast, Barracuda, and Cisco in the MX chain mean an organization that bought serious inbound filtering, which usually correlates with size and with a harder time getting cold mail delivered.

Whether mail is self-hosted. Rare now, and generally a marker of either a very technical organization or a very old setup.

Whether the domain is live at all. No MX records, no mail, no lead.

Run the same lookup on your own domain regularly. MX and SPF misconfiguration is a common and quiet cause of legitimate mail being rejected, and it tends to be noticed only after a campaign underperforms.

An MX check is the cheapest filter in the deliverability stack, and it belongs at the front of it.

It costs nothing. A DNS query, answered in milliseconds, with no credits spent and no permission needed.

It removes the guaranteed bounces. Every address at a domain with no MX records will bounce. Filtering those out before a send protects the only number mailbox providers really watch.

It explains failures you already have. When mail to one specific company keeps disappearing, the MX chain often names the gateway that is eating it.

It confirms your own setup. Your domain needs correct MX to receive replies and a correct SPF record to be trusted when it sends.

What it cannot do is tell you whether a mailbox exists. That check happens at the SMTP layer against the mail server this lookup just identified, and it is the step that catches an address at a perfectly healthy domain belonging to someone who left. Cleanlist runs both on a whole list across 25+ providers at 98% accuracy.

To check whether your sending domain has already been flagged somewhere, pair this with the email blacklist checker.