The relevance of email deliverability to an organization's email marketing strategy may have been discussed frequently. Still, you may not fully comprehend how it applies...
Key Takeaways
- MX records tell sending servers which mail servers accept email for your domain and the order in which they should be tried.
- There are several ways to check MX records, from online tools to command-line utilities, depending on your technical comfort level and needs.
- MX record updates can take 1–48 hours to fully propagate across DNS servers globally, so careful planning is essential during migrations.
Your team just migrated to a new email provider, and you updated all the settings in your ESP. Everything looks configured correctly. And yet emails to your domain keep bouncing, with senders seeing “mail server not found” errors.
The issue is simpler and more frustrating than it looks. Your MX records, the DNS entries that tell the internet where your email should be delivered, are still pointing to the old provider.
MX records operate behind the scenes, routing billions of emails daily without most people knowing they exist. But when MX records are missing, misconfigured, or pointing to the wrong servers, email delivery breaks completely. Unlike deliverability problems that reduce inbox placement, MX issues prevent emails from reaching your mail server at all.
An MX lookup reveals exactly where emails to your domain are being routed, what priority each mail server has, and whether your DNS configuration matches your actual email infrastructure.
This guide explains what MX records are, how MX lookups work, how to perform and interpret them using common tools, and how to fix the most frequent MX configuration problems.
What Is an MX Lookup?
An MX lookup is a DNS query that retrieves the Mail Exchange (MX) records for a specific domain. Those MX records are the DNS entries that tell the internet which mail servers are supposed to receive email for that domain.
For example, when someone sends you a physical letter, the postal system uses your street address to figure out which facility should handle delivery. Similarly, when someone sends you an email, mail servers use your domain’s MX records to determine which email servers should receive the message.
An MX lookup answers one question: “Where should email for this domain be delivered?”
Every domain that receives email must have at least one MX record published in its DNS. Without MX records, sending mail servers don’t know where to route messages, and delivery fails with errors like “mail server not found” or “no MX records available.”
MX records contain:
- Priority value: A number (typically 0-100) that indicates which mail server to try first. Lower numbers have higher priority.
- Hostname: The fully qualified domain name (FQDN) of the mail server that accepts email for your domain, such as mail.example.com or mx1.googlemail.com.
Most domains configure multiple MX records with different priorities to provide redundancy. If the primary mail server is down, sending servers automatically try the secondary or tertiary servers based on priority order.
What Are MX Records Used For?
MX records serve one primary purpose: routing inbound email to the correct mail servers for your domain. But that simple function has several important implications for how email works.
Directing all incoming email
When someone sends an email to [email protected], their mail server performs an MX lookup for yourdomain.com to find out which mail server handles your email. The MX records tell the sending server exactly where to deliver the message.
This routing happens for every email sent to your domain, including customer inquiries, newsletter signups, system notifications, internal team communications, and everything else. If your MX records are wrong, none of those emails reach you.
Providing failover and delivery resilience
Domains typically publish multiple MX records with different priorities:
- Priority 10: Primary mail server (mx1.emailprovider.com)
- Priority 20: Secondary backup server (mx2.emailprovider.com)
- Priority 30: Tertiary backup server (mx3.emailprovider.com)
Sending servers try the lowest priority number first. If that server is unavailable, unreachable, or returns an error, they automatically move to the next-highest priority server. This redundancy ensures email delivery continues even if your primary mail server goes down for maintenance or experiences an outage.
Some organizations also use equal-priority MX records to distribute incoming email load across multiple servers, though this is less common than simple failover configurations.
Matching your active email infrastructure
Your MX records need to point to mail servers you actually control or that your email provider operates. If you’re using Google Workspace, your MX records should point to Google’s mail servers. If you’re using Microsoft 365, they should point to Microsoft’s servers. If you run your own mail server, they should point to your server’s hostname.
Mismatches between MX records and actual infrastructure cause delivery failures. For example, if your MX records still point to an old email provider after you’ve migrated, new emails will try to deliver to servers that no longer accept mail for your domain.
Preventing delivery failures and misrouting
If MX records are incorrect or missing:
- Sending servers can’t find where to deliver email, causing immediate bounces
- Emails may be routed to old providers or wrong servers that reject them
- Backup servers might receive all mail if primary servers are unreachable due to misconfiguration
- Delivery delays occur as sending servers repeatedly retry different MX hosts
How an MX Lookup Works
When a mail server needs to deliver an email, it performs an MX lookup by querying DNS servers. This process happens automatically and takes milliseconds, but understanding the mechanics helps you troubleshoot delivery issues.
The DNS query process:
- Mail server initiates lookup: The sending mail server extracts the domain from the recipient’s email address (the part after @) and queries DNS for MX records associated with that domain.
- DNS resolver responds: The DNS system returns all MX records configured for that domain, including priority values and mail server hostnames.
- Mail server sorts by priority: The sending server sorts the returned MX records by priority value (lowest number first) to determine which mail server to try first.
- Connection attempts begin: The sending server attempts to connect to the highest-priority (lowest number) mail server on port 25 (SMTP) to deliver the message.
- Failover if needed: If the primary server is unavailable, the sending server moves to the next priority level and tries again until it successfully delivers the message or exhausts all options.
An MX lookup returns a list of records formatted like this:
example.com MX 10 mail1.provider.com
example.com MX 20 mail2.provider.com
example.com MX 30 mail3.provider.com
Each line shows the domain, record type (MX), priority value, and the hostname of the mail server. Sending servers use this information to determine delivery routing and failover sequences.
How to Perform an MX Lookup
Checking MX records doesn’t require specialized software. Several methods exist, from online tools to command-line utilities, depending on your technical comfort level and needs.
Using online MX lookup tools
Online tools provide the easiest way to check MX records without installing anything. Popular options include:
MXToolbox (mxtoolbox.com):
- Go to mxtoolbox.com
- Enter your domain in the search box
- Select “MX Lookup” from the dropdown
- Review the results showing priority values and mail server hostnames
Google Admin Toolbox:
- Visit toolbox.googleapps.com/apps/dig
- Enter your domain name
- Select “MX” as the query type
- Click “Run” to see MX records
What MX Toolbox (whatsmydns.net):
- Visit whatsmydns.net
- Enter your domain
- Select “MX” from record types
- See MX records from multiple DNS servers globally
These tools show not just your MX records but often additional information like whether the mail servers are responding, what their IP addresses are, and whether any DNS propagation issues exist.
Using command-line tools
For technical users or automated checks, command-line utilities provide direct DNS queries without relying on web interfaces.
Using nslookup (Windows, Mac, Linux):
This returns MX records directly from DNS servers. The output shows priority values and hostnames.
Using dig (Mac, Linux):
The +short flag returns just the essential information: priority values and mail server hostnames, without extra DNS query details.
Using host (Mac, Linux):
Returns MX records in a human-readable format with priority and hostname information.
Checking through your hosting dashboard
Most hosting providers and domain registrars offer DNS management interfaces where you can view and edit MX records directly:
- Log in to your hosting control panel (cPanel, Plesk, etc.) or domain registrar dashboard
- Navigate to DNS settings or DNS zone editor
- Look for MX records in the list of DNS entries
- Verify priorities and hostnames match your email provider’s requirements
This method shows your configured records as they’re stored, which may differ from what’s currently propagated globally if you recently made changes.
How to Read MX Lookup Results
MX lookup results contain specific information you need to interpret correctly to understand your email routing configuration.
Priority numbers (preference values)
The priority number controls the order in which mail servers are tried, starting with the lowest number first (indicating higher priority).
example.com MX 10 primary.mailserver.com
example.com MX 20 backup.mailserver.com
In this example, primary.mailserver.com (priority 10) receives all email under normal conditions. If it’s unavailable, sending servers automatically try backup.mailserver.com (priority 20).
Common priority patterns include:
- Increments of 10 (10, 20, 30), providing clean failover ordering
- Large gaps (10, 50, 100), leaving room to add servers between existing priorities later
- Equal priorities (10, 10, 10), distributing load randomly across servers
Mail server hostnames
The hostname is the fully qualified domain name of the server that accepts email. It must resolve to an IP address where a mail server is actually running and listening on port 25.
This tells sending servers to deliver email to the server at mail.google.com. That hostname must resolve via DNS to a valid IP address, and a mail server must be running at that address.
TTL (Time to Live) values
Some lookup results include TTL values, shown in seconds:
The TTL (3600 seconds = 1 hour) indicates how long DNS servers should cache this record before checking for updates. Lower TTL values mean changes propagate faster, but increase DNS query load.
What to look for in results
Good signs include:
- Multiple MX records with different priorities (redundancy)
- Hostnames that match your email provider’s documentation
- All hostnames resolve to valid IP addresses
- Consistent configuration across all DNS servers globally
Warning signs include:
- No MX records found (email delivery will fail)
- MX records pointing to localhost, private IPs, or non-existent hostnames
- Priorities that don’t match your intended failover order
- Mixed records pointing to different email providers (migration not completed)
Common MX Lookup Issues and Errors
When you perform an MX lookup, you might encounter several common problems that prevent proper email delivery.
No MX record found
What it means: DNS returns no MX records for your domain, indicating email routing isn’t configured.
Why it happens:
- You just registered a domain and haven’t configured email yet
- DNS records were accidentally deleted during a migration or configuration change
- Your domain registrar or DNS provider is experiencing issues
- DNS hasn’t propagated after recent changes (though this usually takes under 24 hours)
How to fix it:
- Log in to your DNS provider or hosting control panel
- Add MX records provided by your email service (Google Workspace, Microsoft 365, etc.)
- Save changes and wait for DNS propagation (1-48 hours, typically 1-4 hours)
- Verify using an MX lookup tool after waiting
If no MX records exist, some sending servers will attempt to deliver email directly to an A record for the domain, but this is not reliable and many servers will simply bounce the message immediately.
Incorrect priority setup
What it means: Priority values are configured in ways that don’t match your intended routing, causing email to be delivered to backup servers first or creating unpredictable delivery patterns.
Why it happens:
- Manual configuration errors when setting up DNS
- Misunderstanding priority logic (thinking higher numbers mean higher priority)
- Incomplete migration where old and new provider records both exist with wrong priorities
Examples of problems:
example.com MX 50 primary.mailserver.com
example.com MX 10 old-backup.mailserver.com
Email goes to the old backup server (priority 10) instead of the intended primary server (priority 50) because lower numbers are tried first.
How to fix it:
- Identify which mail server should receive email primarily
- Assign that server the lowest priority number (typically 10)
- Assign backup servers progressively higher numbers (20, 30, etc.)
- Remove any MX records for decommissioned or old servers
Pointing to inactive or wrong mail servers
What it means: MX records reference hostnames that don’t exist, don’t resolve to IP addresses, or point to servers that aren’t running mail services.
Why it happens:
- Migration to a new email provider was incomplete (DNS updated, but new servers aren’t ready)
- Typos in hostnames when configuring DNS
- Old MX records remain after switching providers
- Server hostnames changed but DNS wasn’t updated
Symptoms:
- Sending servers timeout trying to connect to mail servers
- “Connection refused” or “Host unreachable” errors in bounce messages
- Intermittent delivery, as some records work, but others don’t
How to fix it:
- Verify each MX hostname resolves to an IP address using nslookup hostname
- Test whether mail servers are accepting connections: telnet hostname 25
- Replace incorrect hostnames with correct ones from your email provider’s setup documentation
- Remove MX records that point to decommissioned servers
Conflicts with email providers
What it means: MX records reference multiple different email providers simultaneously, causing delivery to be split unpredictably between systems or routed to providers that no longer host your email.
Why it happens:
- Incomplete migration where old provider’s MX records weren’t removed
- Attempting to use multiple email providers simultaneously without proper routing rules
- Testing new email service while production system is still active
Example of conflicting records:
example.com MX 10 aspmx.l.google.com (Google Workspace)
example.com MX 20 mail.oldprovider.com (Previous provider)
example.com MX 10 example-com.mail.protection.outlook.com (Microsoft 365)
This configuration splits email unpredictably between Google and Microsoft, with some going to an old provider. Users won’t receive all their email in one place.
How to fix it:
- Decide which email provider should receive all email
- Delete MX records for all other providers
- Keep only the MX records for your chosen provider
- Wait for DNS propagation before decommissioning old accounts
The Bottom Line
MX records are the fundamental routing system that directs all inbound email to your domain. When they’re configured correctly with proper priorities and pointing to active mail servers, email delivery works seamlessly. When they’re missing, misconfigured, or pointing to incorrect servers, email delivery fails completely, and you’ll never know what messages you’re missing.
Running an MX lookup takes 30 seconds using free online tools or command-line utilities and immediately reveals whether your email routing configuration matches your actual infrastructure. Check your MX records during migrations, after DNS changes, and whenever delivery problems appear.
Beyond correct MX configuration, email deliverability depends on clean lists that don’t generate bounces, spam complaints, or trap hits. Use DeBounce to verify email addresses before sending, removing invalid addresses and checking domain configurations that could cause delivery failures.
Verify your list now to ensure your messages reach real, active mailboxes after MX records route them correctly.