Check a domain
How it works
Query the MX records
Every domain that receives mail publishes MX records pointing at its mail servers.
Read the hostnames
The hostname gives away the provider — aspmx.l.google.com is Workspace, .protection.outlook.com is Microsoft.
Check the preference
Lower numbers are tried first. Backups only matter when the primary is down.
Match it to your setup
On a sending fleet, the detected provider should match what you provisioned. It often does not.
What MX tells you about a prospect
MX lookup is the cheapest form of prospect qualification there is. Before you write a line of copy you can know whether a company runs Google Workspace or Microsoft 365, whether they route mail through a security gateway, and whether they are on a small provider that filters lightly.
That matters because the two big providers behave differently. Microsoft tenants are generally stricter on cold traffic than Google, and mail from Google Workspace to Google Workspace tends to land more reliably than Google to Microsoft. If your list is 80% Microsoft, sending it entirely from Google infrastructure is a decision you should make deliberately rather than by accident.
What MX tells you about your own fleet
On sending domains, MX is a verification step. If you provisioned a domain on Microsoft 365 and its MX still points at the registrar's default parking service, that domain cannot receive replies — and replies are the entire point of cold email. Bounces vanish too, which means your list never gets cleaned and your bounce rate stays invisible until a provider throttles you for it.
A domain with no MX records at all is worth flagging. Some senders do this deliberately on pure-outbound domains, but it means every reply and every bounce is lost, and some receivers treat a missing MX as a weak spam signal on its own.
If a gateway shows up in front of the provider, the gateway checker goes into more detail on what that means for delivery.
Reading MX records
An MX record has two parts: a priority number and a hostname. Lower numbers are tried first, and equal numbers are load-balanced between. A domain with 1 aspmx.l.google.com and 5 alt1.aspmx.l.google.com is sending everything to the first host and falling back to the second only if it is unreachable.
The priority number says nothing about quality — it is ordering, not ranking. What matters more is the hostname, because that identifies the provider.
Identifying the provider from the hostname
| MX hostname pattern | Provider | What it means for you |
|---|---|---|
| aspmx.l.google.com | Google Workspace | Generally more forgiving of cold traffic than Microsoft. |
| *.mail.protection.outlook.com | Microsoft 365 | Stricter filtering. Expect tighter inbox placement. |
| mx.zoho.com / .eu | Zoho Mail | Common with smaller businesses and startups. |
| *.pphosted.com | Proofpoint | Security gateway in front of the real provider. |
| *.mimecast.com | Mimecast | Gateway. Aggressive filtering, often with link rewriting. |
| *.barracudanetworks.com | Barracuda | Gateway. Common in mid-market and education. |
| *.protonmail.ch | Proton Mail | Privacy-focused. Small but growing in B2B. |
| inbound-smtp.*.amazonaws.com | Amazon SES | Usually an application receiving mail, not people. |
| registrar parking hosts | None | Domain was bought but never provisioned for mail. |
Where a gateway appears, the real mailbox provider sits behind it and is not visible in MX at all. The gateway checker goes further on what each one does to inbound mail.
Using provider mix to plan a campaign
Run a sample of any list through this before you commit to infrastructure. If the list skews heavily Microsoft, sending entirely from Google Workspace is a choice you want to make deliberately — Microsoft tenants filter cold traffic harder, and same-platform delivery tends to be smoother.
A high proportion of gateways in a list tells you something too: those are larger, more security-conscious organisations, and reply rates will read lower for reasons that have nothing to do with your copy.
Frequently asked questions
What does the MX preference number mean?
It is a priority order — lower is tried first. A domain with 1, 5, 5 and 10 sends to the 1 first, falls back to either of the 5s if that is unreachable, and only reaches the 10 if everything else fails. The numbers themselves are arbitrary; only their relative order matters.
Can a domain send email without MX records?
Yes. MX governs receiving, not sending. A domain with no MX can still send mail perfectly well. It just cannot receive replies or bounces, which for cold email means losing the responses you are paying to generate.
Why do my MX records point somewhere I do not recognise?
Usually a security gateway sitting in front of the real provider, or a leftover from a previous host. Gateways are normal in enterprise setups. A leftover from a migration is not, and it can mean mail is being delivered to a mailbox nobody reads.
Does the MX provider affect my cold email deliverability?
The recipient's provider affects whether your mail lands, and your own sending provider affects how your mail is treated. They are separate questions. Knowing your prospect list's provider mix helps you decide how to split your sending infrastructure — see the comparison in Google Workspace vs Microsoft 365 for cold email.
How do I check the MX records for a domain?
Paste the domain above, or query directly with dig +short MX example.com on macOS and Linux or nslookup -type=MX example.com on Windows. This tool goes a step further and identifies the provider from the hostnames, including any security gateway sitting in front of the real mailbox host.
What does the MX priority number mean?
It sets the order in which receiving servers are tried — lower numbers first, with equal values load-balanced between them. It is purely ordering, not a quality ranking, and a higher number does not indicate a backup of lesser standing. Most providers publish several hosts so mail still flows if one is unreachable.
Can a domain send email without MX records?
Yes. Sending is governed by SPF, DKIM and DMARC, not MX, so a domain with no MX can still deliver outbound mail. What it cannot do is receive — every reply and every bounce is discarded. For cold email that is close to self-defeating, and some receivers treat a missing MX as a weak negative signal.
How can I tell if a company uses Google Workspace or Microsoft 365?
Read the MX hostnames. Google Workspace resolves to aspmx.l.google.com and its alternates; Microsoft 365 to a host ending mail.protection.outlook.com. If a security gateway like Proofpoint or Mimecast is in front, the underlying provider is hidden and you will need other signals such as their published SPF record.
Does the recipient's email provider affect deliverability?
Yes, noticeably. Microsoft tenants filter cold traffic more aggressively than Google in most operators' experience, and a security gateway in front of either filters harder still. Knowing the mix in a list before you send explains reply-rate differences that would otherwise get blamed on copy or targeting.
Why do my own domain's MX records point somewhere I do not recognise?
Usually the registrar's default parking or forwarding service, left in place because the domain was bought but never provisioned. Occasionally it is a forwarding service someone configured years ago. Either way, if you expect mailboxes on that domain, replies are currently going somewhere you are not reading.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.