MX (Mail Exchange) records are the DNS records that tell the internet where to deliver email for a domain. If your MX records are missing, misconfigured, or pointing to the wrong servers, email sent to your domain will bounce or disappear. Checking them takes less than a minute — and knowing what you're looking at makes troubleshooting email problems much faster.
What MX Records Control
When someone sends an email to hello@example.com, their sending server performs an MX lookup for example.com. The DNS response returns one or more MX records, each containing:
- Priority (preference value) — a number that indicates which mail server to try first. Lower numbers are higher priority.
- Mail server hostname — the domain name of the server that should receive the email (e.g.
mail.example.comoraspmx.l.google.com).
The sending server tries the lowest-priority (lowest number) MX host first. If that server is unavailable, it tries the next one. This allows you to configure primary and backup mail servers.
MX records must point to a hostname (a domain), not an IP address directly. The hostname must have its own A or AAAA record. Pointing an MX record to a CNAME or an IP address is invalid per RFC 5321 and will cause delivery failures with many mail servers.
Method 1: Use the ShowDNS MX Lookup Tool
The fastest way to check MX records for any domain is the ShowDNS MX Lookup tool. It queries DNS from multiple global vantage points, so you can see whether your records have propagated worldwide — not just from your local resolver.
- Go to showdns.net/mx-lookup.
- Enter the domain name you want to check (e.g.
example.com) and press Enter or click the lookup button. - The tool returns all MX records for the domain, sorted by priority. It also shows the A record behind each MX hostname so you can verify the IP address.
This is especially useful when you have recently changed your MX records and want to confirm the change has propagated globally.
Method 2: Using dig on Linux and macOS
dig is the standard command-line DNS query tool on Linux and macOS. To look up MX records:
# Basic MX lookup
dig MX example.com
# Short output (just the records)
dig MX example.com +short
# Query a specific DNS server (e.g. Google's resolver)
dig MX example.com @8.8.8.8 +shortThe +short flag suppresses the header and additional sections and returns just the record values. A typical output looks like:
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
20 alt2.aspmx.l.google.com.
30 alt3.aspmx.l.google.com.
30 alt4.aspmx.l.google.com.The first number on each line is the priority. The domain that follows is the mail server hostname. In this example, aspmx.l.google.com will always be tried first (priority 10), with the alt servers acting as backups.
Method 3: Using nslookup on Windows, macOS, or Linux
nslookup is available on all major operating systems including Windows, where dig is not installed by default.
# Windows / macOS / Linux — interactive mode
nslookup -type=MX example.com
# Specify a DNS resolver
nslookup -type=MX example.com 8.8.8.8The output from nslookup is more verbose but contains the same information. Look for lines beginning with MX preference or mail exchanger:
example.com MX preference = 10, mail exchanger = aspmx.l.google.com
example.com MX preference = 20, mail exchanger = alt1.aspmx.l.google.com
example.com MX preference = 20, mail exchanger = alt2.aspmx.l.google.comUnderstanding MX Priority Values
MX priority values are integers from 0 to 65535. The lower the number, the higher the priority. Sending servers always attempt delivery to the lowest-numbered MX host first. You can use any values you like; common conventions include:
| Priority Value | Role | Example |
|---|---|---|
| 1 or 10 | Primary mail server | Google Workspace primary |
| 20 or 30 | Secondary / backup servers | Google Workspace alt servers |
| 0 | Highest priority (used sparingly) | Some providers use 0 for the primary |
If two MX records have the same priority, the sending server picks between them randomly — this provides load balancing across equally preferred mail servers.
Verifying Mail Routing Is Correct
After looking up the MX records, verify the hostname in each record resolves to the correct IP address. Use dig or the ShowDNS DNS Lookup tool to check the A record for each MX hostname:
# Verify the MX hostname resolves
dig A aspmx.l.google.com +short
# Expected output example:
# 142.250.153.26Cross-reference this IP with your mail provider's published IP ranges to confirm routing is correct.
When migrating email providers, always look up the MX records your new provider tells you to set (in their documentation) and compare them directly against what is currently published in DNS. Even a single typo in an MX hostname will silently drop incoming email.
Troubleshooting Missing or Incorrect MX Records
If the MX lookup returns no records or unexpected values, work through these checks:
- Confirm the record was saved. Log into your DNS provider's control panel and verify the MX record exists with the correct hostname and priority.
- Wait for propagation. DNS changes can take up to 48 hours to propagate, though most providers apply changes within minutes. Check the TTL of the previous record to estimate the maximum wait time.
- Check for CNAME conflicts. If your root domain has a CNAME record, MX records cannot coexist with it — this is a DNS specification violation. Use an ALIAS or ANAME record instead, or contact your DNS provider.
- Verify the MX hostname resolves. If the hostname in your MX record does not have a valid A or AAAA record, delivery will fail even though the MX record itself looks correct.
- Check for typos. Common mistakes include missing trailing dots in zone files, extra spaces, and transposing letters in hostnames.
Common MX Record Examples by Provider
| Provider | Primary MX Record | Priority |
|---|---|---|
| Google Workspace | aspmx.l.google.com | 1 |
| Microsoft 365 | domain-com.mail.protection.outlook.com | 0 |
| Zoho Mail | mx.zoho.com | 10 |
| ProtonMail | mail.protonmail.ch | 10 |
Frequently Asked Questions
Can a domain have multiple MX records?
Yes, and it is strongly recommended. Having multiple MX records with different priorities provides redundancy — if the primary mail server is unavailable, sending servers will automatically fall back to the secondary servers. Most mail providers supply 2–5 MX records for this reason.
What happens if a domain has no MX record?
Per RFC 5321, if no MX record exists, some sending servers will attempt delivery to the domain's A record as a fallback. However, this behaviour is not reliable. In practice, most sending servers will simply return a bounce error if no MX record is found.
Does MX record priority affect spam filtering?
Spam filters sometimes check whether the connection came in through the lowest-priority (highest-numbered) MX server — a technique spammers occasionally use to bypass filters. Legitimate senders always target the highest-priority (lowest-numbered) server first.
Why does my MX lookup show records from my old provider?
Your old MX records are still cached by resolvers based on the TTL of the record at the time of the change. If you had a TTL of 3600 (1 hour), it can take up to an hour for all resolvers to pick up the new records. Lowering the TTL to 300 seconds before making changes reduces propagation time.
How do I check MX records on Windows without installing dig?
Use nslookup -type=MX example.com in Command Prompt or PowerShell — no installation required. Alternatively, use the ShowDNS MX Lookup tool directly in your browser.