MX Records Explained: How Email Routing Works (2026)

What Are MX Records?

An MX record is a type of DNS resource record that specifies the mail server responsible for accepting email messages on behalf of a domain. When someone sends an email to user@example.com, the sending mail server queries DNS for the MX records of example.com to determine where to deliver the message.

Each MX record contains two pieces of information: a priority value (also called preference) and a mail server hostname. The priority value is a number that determines the order in which mail servers should be tried. Lower numbers indicate higher priority.

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

In this example, sending servers will first attempt delivery to mail1.example.com (priority 10). If that server is unavailable, they will try mail2.example.com (priority 20), and finally mail3.example.com (priority 30). This provides built-in redundancy for email delivery.

How Email Routing Works Step by Step

Understanding the full email delivery process helps you appreciate why MX records are so critical. Here is what happens when an email is sent:

1. Sender composes the email. The sending mail client (like Gmail or Outlook) passes the message to its outgoing mail server (SMTP server).
2. DNS MX lookup. The sending server extracts the recipient's domain (everything after the @) and queries DNS for MX records.
3. Priority sorting. The returned MX records are sorted by priority value. The server with the lowest number is tried first.
4. A/AAAA resolution. The sending server resolves the MX hostname to an IP address using A (IPv4) or AAAA (IPv6) records.
5. SMTP connection. The sending server connects to the mail server on port 25 and initiates the SMTP handshake. If the server supports STARTTLS, the connection is upgraded to TLS.
6. Message delivery. The email is transferred to the receiving server, which places it in the recipient's mailbox.
7. Fallback on failure. If the primary server is unreachable, the sending server tries the next MX record in priority order. If all servers fail, the message is queued and retried later (typically for up to 5 days).

Understanding MX Priority Values

MX priority values (also known as preference values) determine the order in which mail servers are contacted. The key rules are:

• Lower number = higher priority. A server with priority 10 is tried before a server with priority 20.
• Equal priorities = load balancing. When two MX records share the same priority value, sending servers randomly distribute connections between them, providing basic load balancing.
• Common spacing. Best practice is to use increments of 10 (10, 20, 30) to leave room for inserting additional servers later.
• Backup servers. Higher-numbered MX records serve as backup servers. They only receive mail when all lower-priority servers are unavailable.

A common misconception is that a priority of 0 is "special." It is not — 0 simply means the highest possible priority. Many cloud email providers use 0, 1, 5, or 10 as their primary MX priority.

Common MX Configurations

Google Workspace

Google Workspace (formerly G Suite) uses five MX records with different priorities for redundancy:

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

Notice how the ALT1 and ALT2 servers share priority 5, providing load balancing at the secondary level. ALT3 and ALT4 at priority 10 serve as tertiary backup.

Microsoft 365

Microsoft 365 (Exchange Online) typically uses a single MX record pointing to their mail protection service:

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

Microsoft handles redundancy internally within their infrastructure, so only one MX record is needed. The priority 0 ensures it takes precedence over any other MX records that might exist.

Custom Mail Servers

Organizations running their own mail servers (Postfix, Exim, Exchange on-premises) typically configure a primary and backup server:

example.com.  IN  MX  10  mail.example.com.
example.com.  IN  MX  20  backup-mail.example.com.

The backup server should be configured to accept mail for your domain and either store it locally until the primary recovers (store-and-forward) or relay it to the primary when it comes back online.

MX Records and Email Security

MX records interact with several email security mechanisms. When you look up a domain's MX records, you can also check whether those mail servers have proper security configurations:

• SPF alignment. Your SPF record should include the IP addresses of all servers listed in your MX records, since these servers may also send outbound mail (bounces, autoreplies).
• TLS encryption. Modern mail servers should support STARTTLS. Use our SMTP Banner checker to verify your MX servers advertise TLS.
• MTA-STS. MTA-STS policies reference your MX hostnames to enforce TLS for incoming email. The MX entries in your MTA-STS policy must match your DNS MX records.
• DANE. If your domain uses DNSSEC, you can publish DANE TLSA records for your MX servers to cryptographically bind their TLS certificates.

Troubleshooting MX Record Issues

MX record misconfigurations are one of the most common causes of email delivery failures. Here are the most frequent issues and how to fix them:

• Missing MX records. If no MX records exist, some servers will fall back to the domain's A record. This is unreliable — always configure explicit MX records.
• MX pointing to CNAME. RFC 2181 prohibits MX records from pointing to a CNAME. The MX target must resolve directly to an A or AAAA record. Some servers tolerate this, but many will reject the configuration.
• MX pointing to an IP address. MX records must point to a hostname, not an IP address. The record MX 10 192.168.1.1 is invalid.
• Trailing dot issues. In DNS zone files, hostnames should end with a trailing dot (e.g., mail.example.com.). Missing the dot can cause the hostname to be interpreted as relative to the zone.
• TTL too high. If you are migrating mail providers, lower the TTL on your MX records to 300 seconds (5 minutes) at least 48 hours before the switch to minimize propagation time.
• Stale backup MX. Backup MX servers that are no longer maintained become spam magnets. Attackers specifically target backup MX servers because they often lack the spam filtering of the primary server. Remove backup MX records for servers you no longer operate.

The Null MX Record

If your domain does not receive email, you should publish a null MX record (RFC 7505) to explicitly declare this:

example.com.  IN  MX  0  .

A null MX tells sending servers that the domain does not accept email, causing them to immediately generate a bounce rather than attempting delivery. This saves bandwidth and prevents mail from being queued unnecessarily.

How to Check Your MX Records

You can verify your MX configuration using our free tools:

• MX Lookup — Query and display all MX records for any domain with priority values and IP resolution.
• DNS Lookup — Check any DNS record type including MX, A, AAAA, TXT, and more.
• Email Verifier — Verify that a specific email address is deliverable by checking MX records and SMTP connectivity.