“MX record lookup” is searched roughly 400 times a month in India, and the broader topic attracts far more traffic through tools like MXToolbox. The searchers are a mix: IT admins migrating to Google Workspace or Microsoft 365, developers debugging why mail is not arriving, and marketers trying to understand why a domain bounces.
An MX lookup is one of the fastest diagnostics in email. It also plays a quiet but essential role in email verification. This guide explains what MX records are, how to look them up on any system, how to read the output, and what an MX check can and cannot tell you about an address.
What an MX Record Is
An MX (Mail Exchanger) record is a DNS entry that tells the internet which servers accept email for a domain. Each MX record contains:
- A priority value (lower number means higher preference).
- A hostname of the receiving mail server.
Without valid MX records, a domain cannot reliably receive email.
How Mail Delivery Uses MX Records
When you send to anita@example.in:
- Your mail server queries DNS for the MX records of example. in.
- It sorts them by priority and tries the lowest number first.
- It resolves that hostname to an IP address and opens an SMTP connection.
- If the primary server is unavailable, it tries the next priority.
If no MX exists, the standard permits a fallback to the domain’s A record, but modern practice and most verifiers treat a missing MX as a strong sign the domain does not receive mail.
How to Do an MX Record Lookup
Windows (Command Prompt)
nslookup -type=mx example.in
macOS and Linux (Terminal)
dig mx example.in +short
or
host -t mx example.in
Online tools
Web-based DNS lookup tools, including MXToolbox and Google’s Admin Toolbox Dig, show MX records along with related diagnostics. These are useful when you cannot use a terminal or want to check propagation across resolvers.
Programmatically (Node.js)
const dns = require(‘dns’).promises;
async function getMx(domain) {
try {
const records = await dns.resolveMx(domain);
return records.sort((a, b) => a.priority – b.priority);
} catch (err) {
return []; // NXDOMAIN, no MX, or lookup failure
}
}
Reading the Results
A typical Google Workspace domain returns:
1 smtp.google.com.
Older Workspace setups show five records:
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
A Microsoft 365 domain typically returns one record ending in mail.protection.outlook.com. Zoho Mail domains commonly show mx.zoho.in, mx2.zoho.in and mx3.zoho.in for India data-centre accounts.
What you can infer:
- Provider: hostnames reveal whether the domain uses Google, Microsoft, Zoho, a hosting provider,r or a security gateway.
- Gateway filtering: MX hosts belonging to email security vendors indicate inbound filtering, which often affects verification responses.
- Redundancy: multiple priorities indicate failover.
Common MX Problems and Their Symptoms
| Problem | Symptom |
|---|---|
| No MX record | Senders receive bounces; verifiers mark addresses invalid |
| MX points to an IP address instead of a hostname | Violates the standard; some senders reject delivery |
| MX points to a CNAME | Unreliable delivery with some servers |
| Old MX left after migration | Mail split between old and new providers |
| Typo in hostname | Intermittent or total delivery failure |
| Very high TTL during migration | Slow propagation, mail going to the old server for hours |
| Null MX (0 .) | Domain explicitly declares it accepts no mail. |
The null MX case is increasingly common for domains used only for websites or sending. Mail to them should be treated as undeliverable.
MX Records in Email Verification
Every serious verifier runs an MX check early, because it is cheap and decisive:
- Syntax check confirms the address format.
- Domain and MX check confirms the domain can receive mail. No valid MX usually means the address is invalid, however plausible it looks.
- SMTP check connects to the MX host to ask whether the mailbox exists. See SMTP verification explained.
- Risk assessment for catch-all, disposable and role-based addresses.
What an MX check cannot tell you
- Whether a specific mailbox exists. nobody@realcompany.in has the same MX as ceo@realcompany.in.
- Whether the domain is catch-all. See catch-all addresses.
- Whether the address is a spam trap.
- Whether your email will land in the inbox.
MX lookup is a gatekeeper step, not a verdict. For a list, run full verification; BounceProof runs domain and MX checks alongside mailbox and risk checks in one pass, including inside Google Sheets.
Checklist for Domain Migrations in India
Indian SMEs frequently move from hosting-provider email to Google Workspace, Microsoft 365, or Zoho Mail. Before and after switching MX:
- Lower the MX record TTL a day in advance.
- Create mailboxes in the new provider before switching.
- Replace all old MX records; do not leave legacy entries.
- Update SPF to include the new provider and remove the old one.
- Set up DKIM in the new provider and publish the key.
- Keep or create a DMARC record, starting with monitoring.
- Test inbound mail from Gmail, Outlook, and a corporate domain.
- Run an MX lookup from multiple resolvers to confirm propagation.
Our email domain health guide covers ongoing checks.
Key Takeaways
- MX records tell the internet which servers accept mail for a domain, ordered by priority.
- Use nslookup, dig, host, or online tools to check them.
- Hostnames reveal the mail provider and any security gateway.
- Missing, broken, or null MX records mean the domain cannot receive mail.
- MX checks confirm a domain can receive mail, not that a specific mailbox exists.
Frequently Asked Questions
A DNS query that returns the mail servers responsible for receiving email for a domain, along with their priority.
Run nslookup -type=mx domain.com on Windows, dig mx domain.com on macOS or Linux, or use an online DNS lookup tool.
Lower numbers are tried first. Equal numbers share the load; higher numbers act as backups.
Rarely. Without MX records, delivery depends on fallback behaviour that most modern systems do not rely on. Verifiers generally treat such addresses as undeliverable.
Usually minutes to a few hours, depending on the previous TTL. Some resolvers cache longer, so allow up to 48 hours before concluding a change failed.
Conclusion
An MX lookup takes seconds and answers a question every email workflow depends on: can this domain receive mail at all? For administrators, it is the first diagnostic in any delivery problem. For marketers and developers, it is the gate that keeps obviously undeliverable domains out of lists and databases.
Use it as the first layer, not the last. Pair MX checks with mailbox-level verification and risk classification, and you move from knowing a domain exists to knowing which addresses on it are safe to send to.
