Key takeaways
- MX records list the mail servers that receive email for a domain, with a priority number.
- Lower priority numbers are tried first; others are backups.
- You can check MX records with online tools, nslookup (Windows) or dig (Mac/Linux).
- No MX record (and no fallback) means the domain cannot receive email.
- MX records reveal the mail provider behind a domain, which helps diagnose B2B delivery.
In this guide
- What an MX record is
- Three ways to look up MX records
- How to read the results
- What MX records reveal
- MX lookups for list cleaning
- MX records and your own domain
- MX vs other email DNS records
- Common MX misunderstandings
- Example: diagnosing a B2B delivery problem with MX
- Checking MX records in bulk
- TTL and recent changes
- Glossary
- MX and verification results
- In one minute
- Checklist
- Frequently asked questions
What an MX record is
An MX (Mail Exchange) record is a DNS record that tells the internet which servers receive email for a domain. When someone sends an email to anna@example.com, the sending server asks DNS: "Where should mail for example.com go?" The MX records answer with one or more server names, each with a priority number.
example.com. MX 10 mx1.mailprovider.example.
example.com. MX 20 mx2.mailprovider.example.The lower the number, the higher the priority. Senders try mx1 first (priority 10), and use mx2 (priority 20) only if the first one does not respond. Records with the same priority share the load.
Three ways to look up MX records
1. Online lookup tools
Search for "MX lookup" and you will find many free tools. Type the domain (not the full email address), and the tool lists the MX records with their priorities. This is the easiest method and works from any device.
2. nslookup (Windows, Mac, Linux)
Open a command prompt or terminal and type:
nslookup -type=mx example.comThe output lists lines such as mail exchanger = 10 mx1.mailprovider.example.
3. dig (Mac, Linux)
dig example.com MX +shortThe short output shows one record per line, for example 10 mx1.mailprovider.example.
How to read the results
| Result | Meaning | For verification |
|---|---|---|
| One or more MX records | The domain receives email | Domain OK; mailbox still to check |
| No MX record, but an A record | Mail may fall back to the domain's main server | Often treated as risky or invalid |
| No MX and no A record | The domain cannot receive email | Invalid |
| Domain does not exist (NXDOMAIN) | Typo or expired domain | Invalid |
| MX pointing to "." (null MX) | The domain explicitly accepts no email | Invalid |
A valid MX record proves only that the domain can receive mail. Whether anna@ exists on that domain requires a mailbox-level check, which verification tools perform. See how email verification works.
What MX records reveal
MX host names often show which provider handles email for a domain. That is useful for B2B senders:
| MX host pattern (typical) | Likely provider |
|---|---|
| Hosts under google.com or googlemail.com | Google Workspace |
| Hosts under outlook.com (mail.protection.outlook.com) | Microsoft 365 |
| Hosts of a security gateway vendor | Company uses an email security filter in front of its mailboxes |
| Hosts of a web hosting company | Email hosted with the website hosting |
If many of your B2B contacts sit behind the same security gateway and your emails do not reach them, that gateway is a likely cause. Knowing the provider also helps you understand Microsoft-specific filtering for companies on Microsoft 365.
MX lookups for list cleaning
You can use MX checks to catch a whole class of bad addresses before full verification:
- Extract the unique domains from your list (a few hundred or thousand at most, even for large lists).
- Look up MX records for each domain with a script or tool.
- Flag addresses on domains without MX: they cannot receive email.
- Review the flagged domains: many are typos (see common email typos) or expired company domains.
- Run full verification on the remaining addresses for mailbox-level results.
Developers can add MX checks to forms in a few lines; examples are in how to validate emails in PHP, Python and JavaScript.
MX records and your own domain
MX records also matter for your sending domain:
- Replies: if your From or Reply-To domain has no working MX, replies from subscribers are lost, and some filters see a domain that cannot receive mail as suspicious.
- Bounces: bounce messages need somewhere to go; your platform usually handles this with its own return-path domain.
- Migrations: when changing email providers, MX records are switched last, after the new mailboxes are ready.
MX vs other email DNS records
| Record | Role |
|---|---|
| MX | Where incoming mail for the domain goes |
| SPF (TXT) | Which servers may send mail for the domain |
| DKIM (TXT/CNAME) | Public keys to verify signatures |
| DMARC (TXT) | Policy and reporting for authentication failures |
MX is about receiving; SPF, DKIM and DMARC are about sending. Both sides are explained in SPF, DKIM and DMARC explained.
Common MX misunderstandings
- "The domain has MX, so the address is valid." Not necessarily; the mailbox may not exist.
- "Lower priority means less important." In MX, a lower number means it is tried first.
- "MX records affect deliverability of my campaigns." Only indirectly, through replies and domain credibility. Authentication records matter much more for sending.
Example: diagnosing a B2B delivery problem with MX
A company notices that emails to one important client never arrive, while other clients receive them normally. An MX lookup on the client's domain shows that their mail goes through a security gateway before reaching Microsoft 365. That gateway is likely quarantining the messages. The fix is not on the sender side alone: the client's IT team can check the quarantine and allow the sender's domain.
Without the MX lookup, the company might have spent hours changing content or authentication that were already fine. Knowing where mail goes is often the fastest step in B2B troubleshooting.
Checking MX records in bulk
For a list with many company domains, checking MX one by one is slow. Options:
- A short script that reads unique domains from a file and queries MX records (examples in validating emails in code).
- A bulk DNS lookup tool that accepts a list of domains.
- A verification service, which checks MX for every address as part of its standard process.
Work on unique domains, not on every address: a list of 50,000 contacts may contain only a few thousand different domains.
TTL and recent changes
Each DNS record has a TTL (time to live), which tells resolvers how long they may cache it. When a company changes email provider, the new MX records can take some time to be seen everywhere. If a lookup shows old records just after a migration, wait for the TTL to expire and check again.
Glossary
| Term | Meaning |
|---|---|
| MX record | DNS record naming a mail server that receives email for a domain |
| Priority (preference) | Order in which MX servers are tried; lowest first |
| Null MX | A special record stating that a domain accepts no email |
| A record fallback | Delivery to the domain's main address when no MX exists |
| TTL | How long DNS answers can be cached |
MX and verification results
Verification tools use MX lookups as one of their first checks. When you see an invalid result explained as "no MX" or "domain not found", the problem is the domain, not the person: often a typo or an expired company domain. Check the list of such domains once; you will often find a pattern, such as one misspelled provider or one company that rebranded.
In one minute
An MX lookup tells you where a domain receives email and in which order servers are tried. No MX usually means no email. A valid MX does not prove a mailbox exists, but it filters fake domains and typos cheaply and reveals which provider a company uses, which helps diagnose B2B delivery problems.
Checklist
- Look up MX by domain, not by full address
- Read priorities: lowest number is tried first
- Treat domains without MX as invalid for email
- Use MX host names to identify B2B providers
- Combine MX checks with mailbox verification for real results
- Make sure your own sending domains can receive replies
Frequently asked questions
What does an MX record look like?
It contains a priority and a host name, for example 10 mx1.example.com. The host name points to a server that accepts mail for the domain.
What if a domain has no MX record?
Mail servers may fall back to the domain's A record, but in practice a domain without MX usually cannot receive email. Verification tools treat it as invalid.
Does a valid MX record mean the address exists?
No. It means the domain can receive email. Whether a specific mailbox exists requires a mailbox-level check.
Can I find which provider hosts a company's email?
Often, yes. MX host names usually reveal the provider, such as Google Workspace or Microsoft 365.
Why do MX records have priorities?
To define backup servers. Senders try the lowest number first, then the next ones if the first server does not respond.
