An MX record lookup is a DNS query that returns the mail servers responsible for accepting email for a domain, ranked by priority. You can run one with nslookup -type=mx domain.com or dig mx domain.com. A valid MX record proves the domain can receive mail. It does not prove that a specific mailbox exists or belongs to the person who typed it.
People run an MX record lookup for two reasons: mail is bouncing, or they want to know whether an address on a form is real. The first is a configuration question. The second is a verification question, and that is where teams over-trust the result.
This guide gives the exact commands, how to read the output, what RFC 7505’s “null MX” means, and where an MX check sits in an email verification stack for lenders, fintechs and marketplaces.
What is an MX record?
An MX (mail exchanger) record is a DNS entry that tells sending servers which host accepts email for a domain.
Each MX record has two parts: a preference number and a hostname. Lower numbers are tried first.
Mail delivery under RFC 5321, the core SMTP standard published in October 2008, starts with this lookup. If a domain has no MX record, the standard lets the sender fall back to the domain’s A or AAAA record, treating the domain itself as an implicit mail host. That fallback is why “no MX record” does not automatically mean “cannot receive mail”.
How to do an MX record lookup (nslookup, dig, PowerShell)
You need no special tools. Every operating system ships with a DNS client.
- Windows (Command Prompt): run nslookup -type=mx example.com. The output lists each “mail exchanger” with its preference value.
- macOS or Linux: run dig mx example.com +short. You get compact lines such as 10 mx1.example.com.
- PowerShell: run Resolve-DnsName example.com -Type MX for a tabular view with TTL values.
- Query a specific resolver to rule out local caching: dig @8.8.8.8 mx example.com or nslookup -type=mx example.com 1.1.1.1.
- Resolve the mail host itself: run dig a mx1.example.com to confirm the MX hostname points to a live IP address. An MX record that points to a hostname with no A or AAAA record is broken.
Web-based MX record lookup tools run the same queries through a browser.
How to read MX lookup results
- Several MX records with different priorities: normal. Mail goes to the lowest number first and fails over to the next.
- A single record reading 0: a null MX. Under RFC 7505 (June 2015), this is an explicit declaration that the domain accepts no email at all. Mail to it should fail immediately, with the sending server returning reply code 556 and enhanced status 5.1.10.
- NXDOMAIN: the domain itself does not exist in DNS. Any address on it is invalid.
- No MX, but an A record exists: deliverable under the RFC 5321 fallback, but rare for real business mail.
- MX pointing to an unresolvable host: a misconfiguration; mail bounces.
RFC 7505 exists because the old fallback made senders retry undeliverable mail, sometimes for about a week. Parked and website-only domains now often publish a null MX, which gives sign-up validation a clean reject signal.
What an MX lookup proves, and what it does not
An MX record lookup answers one question: can this domain receive email? That is useful, and it removes typo domains (gmial.com), expired company domains, and invented ones in milliseconds.
It does not answer the questions that matter for fraud:
- Does the mailbox exist? anything@gmail.com passes an MX check for every possible string before the @.
- Is the domain a catch-all? Some servers accept mail for any local part, so even an SMTP-level probe returns “accepted” for addresses nobody reads.
- Is the domain disposable? Throwaway inbox services publish perfectly valid MX records. That is the whole point of them.
- Does the address belong to the applicant? No DNS query can tell you that.
Mailbox existence is tested at the SMTP layer. A verifier connects to the MX host, issues MAIL FROM and RCPT TO, reads the reply code, and disconnects without sending. A 250 suggests the mailbox is accepted; a 550 suggests rejection. RFC 5321 also defines VRFY, but most providers disable it to stop address harvesting.
Even SMTP probing has limits. Large providers may accept at RCPT TO and bounce later, greylist unknown senders, or throttle probes. Treat each result as a probability, not a verdict.
MX checks compared with other email verification signals
| Check | What it detects | What it misses | Typical use |
|---|---|---|---|
| Syntax (RFC format) | Malformed addresses, illegal characters | Every well-formed fake | First filter on any form |
| MX record lookup | Non-existent domains, null MX, broken mail routing | Fake mailboxes on real domains | Typo and dead-domain removal |
| SMTP mailbox probe | Rejected or non-existent mailboxes | Catch-all domains, providers that accept then bounce | Pre-send list cleaning |
| Catch-all detection | Domains accepting any local part | Whether a human reads the inbox | Risk-weighting B2B emails |
| Disposable domain check | Throwaway and temporary inbox services | New disposable domains not yet listed | Sign-up and lead-form fraud |
| OTP or link confirmation | Real-time control of the inbox | Ownership by the named person | Account creation, consent capture |
The pattern is clear. Each layer removes a different kind of bad address, and no single layer is sufficient.
Why this matters more since Gmail’s sender rules
Bad addresses are now a sender-reputation risk, not just a marketing nuisance.
Google’s sender guidelines, which took effect in February 2024 for senders of around 5,000 or more messages a day to personal Gmail accounts, require authentication, easy unsubscribes, and low complaint rates. Google recommends keeping user-reported spam below 0.1% and says senders should never reach 0.3%. Its FAQ states that starting in November 2025, Gmail is “ramping up its enforcement on non-compliant traffic”, with gradual and progressive enforcement.
Bounce rates are not a published Gmail threshold, but heavy bounces signal poor list hygiene to every mailbox provider. A lender sending EMI reminders and KYC links from its campaign domain cannot afford that reputation hit.
Verifying this at scale for your business
A single MX record lookup in a terminal is troubleshooting. Validating thousands of addresses a day from app sign-ups, DSA lead uploads, and partner APIs is infrastructure. A working setup:
- Validates at the point of capture, so the user can fix a typo while still on the form.
- Combines syntax, MX, SMTP, catch-all, and disposable checks into one response with a clear status.
- Caches domain-level results (MX, catch-all, disposable) while re-checking mailboxes, which change more often.
- Feeds the result into risk logic. A disposable address on a credit application is a different signal from a typo on a newsletter form.
The email is also an identity attribute in its own right, and feeds for thin-file applicants.
Use cases in Indian fintech and lending.
Illustrative scenarios, based on common patterns rather than a specific client:
- Digital lending app: an applicant enters name@gmal.com. The MX lookup returns NXDOMAIN, and the form prompts a correction before the loan agreement and Key Fact Statement are emailed to an address no one controls.
- NBFC lead ingestion: a DSA uploads 2,000 leads. Validation flags 14% on disposable domains and a cluster on one catch-all domain. Operations reviews the DSA’s sourcing quality before paying commission.
- Payment aggregator merchant onboarding: a merchant’s business email sits on a domain with a null MX. That conflicts with the claimed business website and prompts a KYB follow-up.
- Wallet or BNPL sign-ups: dozens of accounts created within an hour on fresh disposable domains, a common marker of promo abuse.
In each case, the MX record lookup is the cheapest step. Decision quality comes from what sits on top of it.
Where BeFiSc fits: BounceProof validates email addresses through a single API call, returning syntax, domain, mailbox, and disposable-address signals that your onboarding and lead flows can act on in real time. Start with 100 free email checks on your own data.
Key Takeaways
- An MX record lookup shows which servers accept mail for a domain; run it with nslookup -type=mx or dig mx.
- A null MX (0 ., defined in RFC 7505) means the domain accepts no email. Treat it as a hard reject.
- MX validity proves the domain can receive mail, not that the mailbox exists or belongs to the applicant.
- SMTP probing, catch-all detection, and disposable-domain checks fill the gaps an MX check leaves.
- For lenders and fintechs, email validation is most useful when its output feeds fraud and lead-quality decisions.
Frequently Asked Questions
Does a valid MX record mean the email address is real?
No. It confirms only that the domain has working mail routing. The mailbox may not exist, the domain may be a catch-all, or the address may be disposable. You need mailbox-level and disposable checks for that.
What does an MX record of “0 .” mean?
It is a null MX under RFC 7505. The domain owner is stating that the domain does not accept email. Messages to it should be rejected immediately rather than retried.
Can a domain receive email without an MX record?
Yes, in principle. RFC 5321 lets senders fall back to the domain’s A or AAAA record when no MX exists. In practice, most legitimate business domains publish MX records, so a missing one deserves a closer look.
How do I check the MX record of a domain?
Run nslookup -type=mx example.com on Windows or dig mx example.com on macOS and Linux. Both return the mail server hostnames and their priority values. Use a public resolver such as 8.8.8.8 if you suspect cached or stale results.
Conclusion
An MX record lookup is the right first question to ask of any email address: can this domain receive mail at all? It is fast, free, and definitive for dead domains, typo domains, and null MX records.
Fraudsters have already answered it too. Disposable services, catch-all domains, and fake Gmail mailboxes all pass. For credit applications, merchant onboarding, and DSA lead files, the MX check should be one layer in a stack that also tests the mailbox, the domain type, and the sign-up pattern.
Test 100 addresses for free with BounceProof’s email validation API
