What Are MX Records?
MX stands for Mail Exchange. An MX record is a type of DNS record that specifies which mail servers are responsible for receiving email on behalf of a domain. When someone sends an email to user@example.com, their mail server looks up the MX records for example.com to find out where to deliver the message.
Without MX records, a domain cannot receive email. It's that simple. If example.com has no MX records configured, emails sent to any address @example.com will bounce immediately with a "no MX record found" error.
MX records are one of the foundational building blocks of email infrastructure, and understanding them is essential for anyone working with email deliverability, verification, or domain administration.
How DNS Routes Email
To understand MX records, you need to understand how email delivery works at the DNS level. The process involves several steps that happen in milliseconds:
Step 1: Sender's Server Extracts the Domain
When you send an email to user@example.com, your mail server (or your ESP's server) extracts the domain portion: example.com.
Step 2: DNS Query for MX Records
Your server queries the DNS system for MX records associated with example.com. This is similar to how a web browser queries DNS for A records when you visit a website — but instead of asking "what's the IP address of this website?", it's asking "what mail servers handle email for this domain?"
Step 3: DNS Returns MX Records with Priorities
The DNS response includes one or more MX records, each with a hostname and a priority value (lower number = higher priority):
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
example.com. MX 30 mail3.example.com.
Step 4: Sender Connects to the Highest Priority Server
Your mail server connects to mail1.example.com (priority 10) first. If that server is unavailable, it falls back to mail2.example.com (priority 20), then mail3.example.com (priority 30).
Step 5: SMTP Handshake and Delivery
Once connected, the two servers perform an SMTP handshake to negotiate the delivery. If the recipient's server accepts the message, the email is delivered. If it rejects it (invalid address, policy block, etc.), the email bounces.
The Fallback Mechanism
The priority system provides redundancy. If a domain's primary mail server goes down, email still gets delivered via backup servers. Large organizations typically configure multiple MX records at different priorities for this reason.
Some domains also configure a null MX record (priority 0 with . as the host) to explicitly declare that they do not accept email. This is defined in RFC 7505 and is used by domains that have no email infrastructure.
How to Perform an MX Record Lookup
Using dig (Linux/macOS)
The dig command is the standard DNS lookup tool on Unix-based systems:
dig MX example.com +short
Output:
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 alt2.aspmx.l.google.com.
40 aspmx2.googlemail.com.
50 aspmx3.googlemail.com.
For more detailed output including TTL and response metadata:
dig MX example.com
Output:
;; ANSWER SECTION:
example.com. 3600 IN MX 10 aspmx.l.google.com.
example.com. 3600 IN MX 20 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 30 alt2.aspmx.l.google.com.
The 3600 is the TTL (Time To Live) in seconds — how long DNS resolvers should cache this record before re-querying.
Using nslookup (Windows/macOS/Linux)
nslookup -type=MX example.com
Output:
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
example.com mail exchanger = 10 aspmx.l.google.com.
example.com mail exchanger = 20 alt1.aspmx.l.google.com.
Using PowerShell (Windows)
Resolve-DnsName -Name example.com -Type MX
Programmatically in Node.js
const dns = require('dns').promises;
async function lookupMx(domain) {
try {
const records = await dns.resolveMx(domain);
// Sort by priority (lowest number = highest priority)
return records.sort((a, b) => a.priority - b.priority);
} catch (err) {
if (err.code === 'ENOTFOUND') {
console.log(`Domain ${domain} does not exist`);
} else if (err.code === 'ENODATA') {
console.log(`Domain ${domain} has no MX records`);
}
return [];
}
}
// Usage
const records = await lookupMx('google.com');
// [
// { exchange: 'smtp.google.com', priority: 5 },
// { exchange: 'smtp2.google.com', priority: 10 },
// ...
// ]
Programmatically in Python
import dns.resolver
def lookup_mx(domain: str) -> list:
try:
answers = dns.resolver.resolve(domain, 'MX')
records = []
for rdata in answers:
records.append({
'priority': rdata.preference,
'exchange': str(rdata.exchange).rstrip('.')
})
return sorted(records, key=lambda r: r['priority'])
except dns.resolver.NXDOMAIN:
print(f"Domain {domain} does not exist")
return []
except dns.resolver.NoAnswer:
print(f"Domain {domain} has no MX records")
return []
Online MX Lookup Tools
If you prefer a web-based approach, several free tools are available:
- MXToolbox (mxtoolbox.com) — The industry standard for DNS diagnostics
- Google Admin Toolbox (toolbox.googleapps.com/apps/dig) — Clean interface, reliable results
- DNS Checker (dnschecker.org) — Checks MX records from multiple global locations
These tools are handy for quick one-off lookups but aren't suitable for programmatic use.
What MX Records Tell You About Email Deliverability
MX records reveal more about a domain's email infrastructure than most people realize. Here's what you can learn:
Email Provider Identification
The MX hostnames immediately reveal which email platform a domain uses:
| MX Record Pattern | Provider |
|---|---|
| *.google.com or *.googlemail.com | Google Workspace |
| *.outlook.com or *.protection.outlook.com | Microsoft 365 |
| *.pphosted.com | Proofpoint |
| *.mimecast.com | Mimecast |
| *.messagelabs.com | Symantec/Broadcom |
| *.securemx.net | Trend Micro |
| *.emailsrvr.com | Rackspace |
| *.zoho.com | Zoho Mail |
Knowing the provider matters for email verification because different providers have different behaviors. Google Workspace and Microsoft 365 respond to SMTP verification queries differently, and some providers are more aggressive with rate limiting or greylisting than others.
Infrastructure Maturity
Domains with multiple MX records at different priorities have invested in email redundancy. This typically indicates a professional IT setup. A single MX record with no backup suggests a smaller operation or less mature infrastructure.
Security Posture
Domains that route mail through security gateways (Proofpoint, Mimecast, Barracuda) before their primary mail server are more likely to be enterprise organizations with strict email policies. These domains may be more aggressive about rejecting unrecognized senders.
Catch-All Likelihood
The email provider significantly influences whether a domain is likely configured as catch-all. Self-hosted mail servers and smaller providers are more commonly configured as catch-all than Google Workspace or Microsoft 365.
Common MX Configurations
Google Workspace
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 alt2.aspmx.l.google.com.
40 aspmx2.googlemail.com.
50 aspmx3.googlemail.com.
Google Workspace is the most common email provider for businesses. Their MX configuration includes five servers at different priorities for redundancy. When verifying addresses at Google Workspace domains, the SMTP response is generally reliable — Google returns definitive 550 errors for non-existent mailboxes (unless catch-all is enabled).
Microsoft 365
0 company-com.mail.protection.outlook.com.
Microsoft 365 typically uses a single MX record pointing to their Exchange Online Protection (EOP) gateway. The hostname follows a pattern: your domain name with dots replaced by dashes, followed by .mail.protection.outlook.com.
Microsoft's SMTP behavior during verification is less predictable than Google's. They sometimes delay responses, return ambiguous codes, or apply rate limiting more aggressively.
Self-Hosted (cPanel/Plesk)
0 mail.example.com.
Self-hosted mail servers (common with shared hosting providers) typically have a single MX record pointing to the same server that hosts the website. These are the most likely to be configured as catch-all and the most likely to have non-standard SMTP behaviors.
Domains That Don't Accept Email
0 .
A null MX record (RFC 7505) explicitly declares that a domain does not accept email. Any address at this domain is guaranteed invalid.
Additionally, domains with no MX records at all (NXDOMAIN or NODATA DNS responses) cannot receive email. Some email systems will fall back to A record delivery as specified in RFC 5321, but this is rare in practice and most modern mail servers treat the absence of MX records as undeliverable.
How Email Verification Uses MX Records
MX record analysis is a critical stage in the email verification pipeline. In SendSure's 27-stage verification engine, MX lookup happens early — typically as stage 2, right after syntax validation — because it informs every subsequent stage.
Stage 2: MX Resolution
The verification engine queries the domain's MX records and classifies the result:
- MX records found — Domain can receive email. Proceed to SMTP verification.
- No MX records — Domain cannot receive email. Mark as invalid immediately (no need to waste time on SMTP checks).
- Domain doesn't exist (NXDOMAIN) — The entire domain is dead. Invalid.
- DNS timeout — Retry with different resolvers. If persistent, flag as unknown.
Provider Detection
Based on the MX records, the verification engine identifies the email provider and selects the appropriate verification strategy. Different providers require different approaches:
- Google Workspace — Standard SMTP verification works well. Reliable 250/550 responses.
- Microsoft 365 — Requires careful handling of delayed responses and rate limiting. May need retry logic.
- Self-hosted — Higher likelihood of catch-all configuration. May need AI-assisted resolution.
- Security gateways — May block SMTP verification entirely. Alternative signals needed.
Infrastructure Quality Scoring
MX record data contributes to the overall quality score for an address. A domain with proper MX configuration, multiple priority levels, and a recognized enterprise provider scores higher than a domain with a single MX record on shared hosting.
Disposable Domain Detection
MX fingerprinting is one of the methods used to detect disposable email addresses. Many disposable email services share MX infrastructure, so checking whether a domain's MX records point to known disposable email servers catches domains that haven't yet been added to blocklists.
Troubleshooting MX Record Issues
If you manage a domain and are having email deliverability problems, MX record misconfiguration is a common culprit.
No MX Records Configured
Symptom: All email to your domain bounces with "no MX record found."
Fix: Add MX records through your domain registrar or DNS provider. The exact records depend on your email provider. Google Workspace, Microsoft 365, and others provide specific MX records to add during setup.
Wrong Priority Values
Symptom: Email goes to a backup server instead of the primary, causing delays.
Fix: Ensure your primary mail server has the lowest priority number (e.g., 10) and backup servers have higher numbers (20, 30, etc.).
Stale MX Records After Migration
Symptom: After switching email providers, some emails still go to the old provider.
Fix: Update MX records to point to the new provider and remove old records. Note that DNS propagation can take up to 48 hours, so both systems should be running during the transition.
TTL Too High
Symptom: DNS changes take a long time to propagate.
Fix: Before making MX record changes, lower the TTL to 300 seconds (5 minutes). After the change has propagated, you can increase it back to 3600 (1 hour) or higher.
MX Records and Other DNS Records for Email
MX records don't work alone. A complete email DNS setup includes several complementary record types:
- SPF (TXT record) — Specifies which servers are authorized to send email for the domain
- DKIM (TXT record) — Provides a cryptographic signature for email authentication
- DMARC (TXT record) — Defines policy for handling emails that fail SPF or DKIM checks
- A/AAAA records — IP addresses of mail servers referenced in MX records
- PTR records — Reverse DNS for mail server IPs (critical for sender reputation)
A domain with properly configured MX, SPF, DKIM, and DMARC records signals a mature email infrastructure. During verification, the presence or absence of these records contributes to the overall assessment of an address's quality and deliverability.
Try It Yourself
Understanding MX records is useful for diagnosing email issues, but you don't have to become a DNS expert to verify your email list. SendSure handles MX lookups, provider detection, and all 25 subsequent verification stages automatically.
Create your free account and get 100 verification credits. Upload your list and see detailed results that include provider detection, MX status, and quality scores — all powered by the same DNS infrastructure described in this guide.
