Blog

MX Lookup: How to Check MX Records Correctly

DeBounce
Articles
26 min read

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:

  1. 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.
  2. DNS resolver responds: The DNS system returns all MX records configured for that domain, including priority values and mail server hostnames.
  3. 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.
  4. 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.
  5. 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.

performing-an-mx-lookup

Using online MX lookup tools

Online tools provide the easiest way to check MX records without installing anything. Popular options include:

MXToolbox (mxtoolbox.com):

  1. Go to mxtoolbox.com
  2. Enter your domain in the search box
  3. Select “MX Lookup” from the dropdown
  4. Review the results showing priority values and mail server hostnames

Google Admin Toolbox:

  1. Visit toolbox.googleapps.com/apps/dig
  2. Enter your domain name
  3. Select “MX” as the query type
  4. Click “Run” to see MX records

What MX Toolbox (whatsmydns.net):

  1. Visit whatsmydns.net
  2. Enter your domain
  3. Select “MX” from record types
  4. 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):

nslookup -type=mx example.com

This returns MX records directly from DNS servers. The output shows priority values and hostnames.

Using dig (Mac, Linux):

dig example.com MX +short

The +short flag returns just the essential information: priority values and mail server hostnames, without extra DNS query details.

Using host (Mac, Linux):

host -t MX example.com

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:

  1. Log in to your hosting control panel (cPanel, Plesk, etc.) or domain registrar dashboard
  2. Navigate to DNS settings or DNS zone editor
  3. Look for MX records in the list of DNS entries
  4. 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.

MX    10    mail.google.com

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:

example.com    3600    IN    MX    10    mail.example.com

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.

mx-lookup-issues-and-errors

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:

  1. Log in to your DNS provider or hosting control panel
  2. Add MX records provided by your email service (Google Workspace, Microsoft 365, etc.)
  3. Save changes and wait for DNS propagation (1-48 hours, typically 1-4 hours)
  4. 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:

  1. Identify which mail server should receive email primarily
  2. Assign that server the lowest priority number (typically 10)
  3. Assign backup servers progressively higher numbers (20, 30, etc.)
  4. 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:

  1. Verify each MX hostname resolves to an IP address using nslookup hostname
  2. Test whether mail servers are accepting connections: telnet hostname 25
  3. Replace incorrect hostnames with correct ones from your email provider’s setup documentation
  4. 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:

  1. Decide which email provider should receive all email
  2. Delete MX records for all other providers
  3. Keep only the MX records for your chosen provider
  4. 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.

Frequently Asked Questions

01

How long does it take for MX record changes to take effect?

MX record changes typically propagate within 1-4 hours but can take up to 48 hours to reach all DNS servers globally; the TTL value on your existing records determines the minimum propagation time.

02

Can a domain have MX records without an email service?

Yes, you can configure MX records even if you don’t actively use email, but they must point to servers that either accept or properly reject mail rather than timing out or causing errors.

03

What happens if multiple MX records have the same priority?

Sending mail servers randomly select among equal-priority MX records for each delivery attempt, effectively distributing load across those servers instead of using them as failover backups.