MX Records Explained: How Email Routing Works

Updated February 6, 2026

MX records are the foundation of email delivery. Every email that reaches your inbox got there because the sender's mail server looked up your domain's MX records and found the right server to deliver to. Without MX records, email for your domain has nowhere to go.

How MX Records Work

When someone sends an email to [email protected], here is what happens:

1. The sender's mail server queries DNS for the MX records of example.com.
2. DNS returns one or more MX records, each with a priority value and a mail server hostname.
3. The sender's server connects to the highest-priority server (lowest priority number) and delivers the email via SMTP.
4. If that server is unavailable, it tries the next priority level, and so on.
5. If all servers are unavailable, the message is queued and retried later (typically for up to 5 days).

MX Record Format

An MX record has two components: a priority (also called preference) and a mail server hostname:

example.com.    IN    MX    10    mail1.example.com.
example.com.    IN    MX    20    mail2.example.com.
example.com.    IN    MX    30    mail3.example.com.

Priority and Failover

The priority value determines the order in which servers are contacted. Lower numbers have higher priority.

example.com.    MX    10    primary-mail.example.com.
example.com.    MX    20    secondary-mail.example.com.
example.com.    MX    30    backup-mail.example.com.

In this configuration:

• primary-mail (priority 10) is tried first
• If it's unavailable, secondary-mail (priority 20) is tried
• If both are down, backup-mail (priority 30) is tried

Equal Priority (Load Balancing)

If multiple MX records have the same priority value, the sending server randomly selects between them. This provides basic load distribution:

example.com.    MX    10    mail1.example.com.
example.com.    MX    10    mail2.example.com.

Both servers share the load roughly equally. If one fails, the other handles all traffic.

Common Provider MX Records

Here are the MX records for popular email hosting providers:

Google Workspace

example.com.    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

example.com.    MX    0     example-com.mail.protection.outlook.com.

Microsoft 365 typically uses a single MX record with priority 0. The hostname is unique to your tenant.

Zoho Mail

example.com.    MX    10    mx.zoho.com.
example.com.    MX    20    mx2.zoho.com.
example.com.    MX    50    mx3.zoho.com.

TTL Considerations

The TTL (Time to Live) on your MX records controls how long DNS resolvers cache the records before checking for updates.

For more about how TTL affects DNS changes, see our guide on DNS propagation.

MX Records and Email Authentication

MX records handle incoming email. Email authentication protocols (SPF, DKIM, DMARC) handle the outgoing side — verifying that email claiming to be from your domain is legitimate.

However, they are connected. Your MX records should be consistent with your authentication setup:

• The servers in your MX records should be included in your SPF record if they also send outbound email.
• Your mail servers should be configured with DKIM signing.
• DMARC policies should be in place to protect against spoofing.

Common Mistakes

Pointing MX to an IP Address

MX records must reference a hostname, not a raw IP address:

# WRONG
example.com.    MX    10    192.168.1.1

# CORRECT
example.com.    MX    10    mail.example.com.

Make sure mail.example.com has an A record resolving to 192.168.1.1.

Pointing MX to a CNAME

The MX target should not be a CNAME alias. While some resolvers handle this, it violates RFC 2181 and can cause unpredictable delivery failures:

# WRONG — mail.example.com is a CNAME
mail.example.com.    CNAME    loadbalancer.provider.com.
example.com.         MX       10    mail.example.com.

# CORRECT — use the canonical hostname directly
example.com.         MX       10    loadbalancer.provider.com.

Missing Reverse DNS (PTR)

While not strictly an MX record issue, mail servers listed in your MX records should have proper reverse DNS (PTR records). Many receiving servers check that the sending server's IP resolves back to a valid hostname. Missing PTR records can cause delivery issues.

No Backup MX

Running a single MX record with no backup means any downtime on that server causes email to bounce. While most senders queue and retry, prolonged outages can result in lost messages once retry limits are exceeded.

Looking Up MX Records

You can query MX records from the command line:

# Using dig
dig MX example.com +short

# Using nslookup
nslookup -type=mx example.com

Or use DNS Kit's DNS Lookup tool for instant results with additional context about your records.

MX Records vs. Other DNS Record Types

MX records are one of many DNS record types. Here's how they relate to the broader DNS ecosystem:

For a comprehensive overview of all DNS record types, see our DNS records guide. To learn how to look up any record type, check out How to Check DNS Records.