Free MX record checker.
Type a domain and get its MX records back with priorities, plus who actually filters that domain's mail. Useful in two directions: checking a prospect's domain before you send to it, and checking your own sending domains before you send from them.
Privacy: this tool runs entirely in your browser. When you click Check, one DNS query for the domain you typed goes to Cloudflare's public DNS resolver (Google's as fallback). Nothing is stored, logged or sent to GrowthPal.
MX records at a glance
| Item | Value |
|---|---|
| What it does | Names the servers that accept mail for a domain, and in what order to try them |
| Priority | Lower number is tried first. Equal numbers share the load |
| No MX record | The spec allows a fallback to the domain's A record, which almost never accepts mail, so in practice the message bounces |
| Null MX | A single record of . at priority 0 means the domain accepts no mail at all, deliberately |
| Specification | RFC 5321 for delivery, RFC 7505 for null MX |
What is an MX record?
An MX record is a DNS record that names a mail server willing to accept messages for a domain, along with a priority number that says which to try first. A domain usually publishes several for redundancy.
When a sending server has a message for someone@example.com, it looks up the MX records for example.com, sorts them by priority, and connects to the lowest number first. If that host does not answer, it works down the list. Equal priorities are treated as interchangeable, which is how providers spread load.
For outbound work MX records are useful twice over. Before a campaign, a domain with no MX is a guaranteed bounce and belongs out of the list. During diagnosis, the MX host tells you which company filters that prospect's mail, which explains a great deal about why an otherwise good campaign went quiet against one segment.
How to read your MX check result
The checker returns each MX host with its priority, lowest first, and flags what it recognizes.
A list of hosts is the normal result. Read the hostnames rather than counting them: the names tell you who runs the mail, and the table below maps the common ones.
No MX records is the result that matters before a send. Take the address out of the list. A bounce costs reputation, and reputation is the expensive thing.
A strict gateway warning appears when the MX points at a filtering appliance rather than a mailbox provider. It is not a problem with the domain, it is information about the kind of filtering your message will meet.
One thing worth knowing: MX tells you where mail is accepted, not whether a specific mailbox exists behind it. A domain with perfect MX records still bounces mail to an address that was never real.
What the MX host tells you
| Host pattern | Who runs it | What it means for outbound |
|---|---|---|
aspmx.l.google.com and alt*.aspmx.l.google.com | Google Workspace | Engagement-led filtering. Replies and opens by real people matter more than any header. |
*.mail.protection.outlook.com | Microsoft 365 | Standard filtering plus whatever rules the tenant's admin has added on top. |
*.pphosted.com, *.ppe-hosted.com | Proofpoint | Strict gateway. Expect aggressive filtering and keep links out of a first touch. |
*.mimecast.com | Mimecast | Strict gateway, often with attachment and link rewriting. |
*.barracudanetworks.com | Barracuda | Strict gateway, reputation-heavy. |
mx.zoho.com, mx2.zoho.com | Zoho Mail | Standard filtering. Common at smaller companies. |
| A hostname on the company's own domain | Self-hosted or a smaller provider | Behavior varies. Worth watching as its own segment. |
Failure states and what they mean
| State | What it means | What to do |
|---|---|---|
| No MX records | Nothing is advertised as accepting mail for the domain. | Remove the address before sending. It will bounce. |
Null MX (a single .) | The domain declares that it accepts no mail, deliberately, under RFC 7505. | Remove. This is a parked or send-only domain. |
| Domain does not resolve | The domain itself does not exist in DNS. | Remove, and check where that data came from. |
| MX points at a host that does not resolve | A leftover record aimed at a decommissioned server. | If it is your domain, remove the stale record. If it is a prospect's, expect delivery problems. |
| Several records at equal priority | Normal. The provider is spreading load. | Nothing. |
| One record at a very low priority pointing somewhere unexpected | Often a forgotten migration artefact that silently wins over the real records. | On your own domains, remove it. |
How to set up MX on a cold email sending domain
A sending domain that cannot receive mail looks exactly like what it is. It also throws away the bounces and out-of-office replies that tell you how a campaign is really doing.
- Decide where replies should land. Usually the mailbox provider hosting the sending inboxes, since replies are the thing you are optimising for.
- Publish the provider's MX records exactly as given. Hostnames and priorities both. A transposed priority still works most of the time, which is how it survives unnoticed for months.
- Remove anything left over. A single stale record at a lower priority takes precedence over the correct ones and quietly swallows replies.
- Publish SPF, DKIM and DMARC on the same domain before the first warmup send, not after.
- Send a real message to the domain and confirm it arrives. This is the only step that proves the chain works end to end.
- Re-check after any provider migration. Migrations are where MX records go stale, and nothing alerts you.
Common questions about MX records
What happens if a domain has no MX record?
In practice your mail fails. The standard allows a fallback to the domain's A record, but that host almost never accepts mail, so the message bounces. Catching it before a campaign is the whole point, because a bounce costs reputation, not just a send.
Why does the MX host matter for cold email?
It tells you who filters the mail. A Google or Microsoft MX means one set of behaviors. A Proofpoint, Mimecast or Barracuda gateway in front means a strict corporate filter, and it often explains total silence from a company that otherwise looked like a good fit.
Do my own sending domains need MX records?
Yes. A domain that sends but cannot receive looks like exactly what it is. It also means bounces and out-of-office replies have nowhere to land, so you lose the reply signal your campaign is measured on.
What does MX priority mean?
The lower number is tried first and higher numbers are fallbacks for when the primary is unreachable. Equal numbers share the load. A leftover MX with a low priority pointing at a server that no longer exists is a quiet way to lose mail for months.
What is a null MX record?
A single MX record consisting of a dot at priority 0, defined in RFC 7505. It is a domain stating that it accepts no mail at all, which is the correct configuration for a parked or send-only domain. Sending to one guarantees an immediate bounce, so remove those addresses.
Should I check MX before every campaign?
Check it as part of verification rather than as a separate step, because a missing MX is one of the failures a verification pass catches anyway. Where a manual check earns its keep is diagnosis: segmenting reply rates by MX host regularly explains a quiet campaign better than rewriting the copy does.