MX Record Lookup: How to Check Mail Servers and What It Proves

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.

How to Check MX Records Using Command-Line Tools

• Windows (Command Prompt): Run the following command:

  nslookup -type=mx example.com
  

  The output lists each mail exchanger along with its preference value.

• macOS or Linux: Run:

  dig mx example.com +short
  

  You get compact output lines such as:

  10 mx1.example.com
  

• PowerShell: Run the following command for a tabular view with TTL values:

  Resolve-DnsName example.com -Type MX
  

• Query a Specific DNS Resolver: To rule out local caching issues, query a public DNS resolver:

  dig @8.8.8.8 mx example.com
  

  Alternatively, use:

  nslookup -type=mx example.com 1.1.1.1
  

• Resolve the Mail Host Itself: Run the following command to confirm that the MX hostname points to a live IP address:

  dig a mx1.example.com
  

  An MX record pointing 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

How to Interpret Different MX Record Results

• Several MX Records with Different Priorities: This is normal. Mail is sent to the server with the lowest preference number first. If that server is unavailable, the sending server can try the next available server.
• A Single Record Reading 0 (Null MX): This indicates that the domain does not accept email. Under RFC 7505 (June 2015), a Null MX record explicitly declares that the domain has no mail service. Mail sent to the domain should be rejected rather than routed to another server.
• NXDOMAIN: This means the domain itself does not exist in DNS. Email addresses using that domain cannot receive email.
• No MX Record, but an A Record Exists: Email may still be deliverable through the RFC 5321 fallback mechanism, which allows the sending server to use the domain's A or AAAA record as the mail host. However, this setup is uncommon for business email.
• MX Pointing to an Unresolvable Host: This indicates a DNS misconfiguration. If the mail server hostname cannot be resolved, email delivery may fail, and messages may bounce.

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:

What an MX Record Check Cannot Tell You

• Does the Mailbox Exist? An address such as an******@gmail.com can pass an MX check because Gmail has valid mail exchange records for its domain. MX checks validate domain-level mail routing, not individual mailbox existence.
• Is the Domain a Catch-All? Some mail servers accept messages for any local part, even if the mailbox does not actually exist or is not monitored. As a result, even an SMTP-level probe may return an accepted response for addresses nobody reads.
• Is the Domain Disposable? Temporary or throwaway email services often publish perfectly valid MX records. This is intentional, as these services are designed to receive temporary messages.
• Does the Address Belong to the Applicant? No DNS query can establish ownership of an email address. Additional verification, such as sending a one-time password (OTP) or confirmation link, is required to verify access.

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

Email Verification Methods: Comparison

• Syntax (RFC Format): What It Detects: Malformed addresses and illegal characters. What It Misses: Every well-formed fake address. Typical Use: First filter on any form.
• MX Record Lookup: What It Detects: Non-existent domains, Null MX records, and broken mail routing. What It Misses: Fake mailboxes on real domains. Typical Use: Typo and dead-domain removal.
• SMTP Mailbox Probe: What It Detects: Rejected or non-existent mailboxes. What It Misses: Catch-all domains and providers that accept messages before bouncing them. Typical Use: Pre-send list cleaning.
• Catch-All Detection: What It Detects: Domains accepting any local part. What It Misses: Whether a human actually reads the inbox. Typical Use: Risk-weighting B2B emails.
• Disposable Domain Check: What It Detects: Throwaway and temporary inbox services. What It Misses: New disposable domains that are not yet listed. Typical Use: Sign-up and lead-form fraud prevention.
• OTP or Link Confirmation: What It Detects: Real-time control of the inbox. What It Misses: Ownership by the named person. Typical Use: Account creation and 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

Building an Effective Email Verification Setup

A single MX record lookup in a terminal is useful for troubleshooting. However, validating thousands of email addresses daily through app sign-ups, DSA lead uploads, and partner APIs requires a more structured infrastructure.

A reliable email verification setup should:

• Validate at the Point of Capture: Check email addresses when users enter them into a form, allowing them to correct typos before submitting their information.
• Combine Multiple Verification Checks: Bring syntax, MX, SMTP, catch-all, and disposable email checks into a single response with a clear verification status.
• Cache Domain-Level Results: Store domain-level results, such as MX records, catch-all status, and disposable domain information. Recheck mailbox-level details more frequently because they can change over time.
• Integrate Results into Risk Logic: Use verification results as part of your risk assessment process. A disposable email address on a credit application represents a different risk signal from a simple typo on a newsletter subscription form.

Email is also an identity attribute in its own right and can provide useful signals when assessing applicants with limited credit histories or thin-file profiles.

Use cases in Indian fintech and lending

Illustrative Email Verification Scenarios

The following scenarios are based on common industry patterns rather than a specific client:

• Digital Lending App: An applicant enters n***@gmal.com. The MX lookup returns NXDOMAIN, and the form prompts the applicant to correct the email address before the loan agreement and Key Fact Statement are emailed to an address no one controls. Learn more about RBI Digital Lending Guidelines.
• NBFC Lead Ingestion: A Direct Selling Agent (DSA) uploads 2,000 leads. Validation flags 14% of the addresses on disposable domains and identifies a cluster on one catch-all domain. The operations team reviews the DSA's sourcing quality before paying commissions.
• Payment Aggregator Merchant Onboarding: A merchant's business email is hosted on a domain with a Null MX record. This conflicts with the claimed business website and prompts a Know Your Business (KYB) follow-up.
• Wallet or BNPL Sign-ups: Dozens of accounts are created within an hour using newly registered disposable domains. This can be a common indicator of promotional abuse. Learn more about BNPL fraud.

In each case, the MX record lookup is the cheapest step. Decision quality comes from the verification checks and risk logic built on top of it.

Where BeFiSc Fits In

BounceProof validates email addresses through a single API call, returning syntax, domain, mailbox, and disposable-address signals that onboarding and lead management workflows can act on in real time. Start with 100 free email checks using your own data.

Key Takeaways

• MX Record Lookup: An MX record lookup identifies which mail servers accept emails for a domain. You can run it using nslookup -type=mx or dig mx.
• Null MX Record: A Null MX record (0 .), defined in RFC 7505, indicates that the domain does not accept email. Treat it as a hard rejection.
• MX Validity Does Not Guarantee Mailbox Existence: A valid MX record proves that the domain has mail routing configured, but it does not confirm that a specific mailbox exists or belongs to the applicant.
• Additional Email Verification Checks: SMTP probing, catch-all detection, and disposable-domain checks help identify risks that a basic MX lookup cannot detect.
• Email Validation for Lenders and Fintechs: Email validation is most useful when its results feed into fraud detection, applicant risk assessment, and lead-quality decisions.

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.