MX Records Explained: Priority, Structure, and Best Practices

MX records are the backbone of email delivery. Every email sent to your domain relies on these DNS entries to find the right mail server. Understanding how MX records work helps you configure email correctly and troubleshoot problems when they arise.

This guide covers MX record structure in depth, including priority values, TTL settings, and how MX records interact with other DNS records.

MX Record Structure

Every MX record consists of three components: the domain it applies to, a priority value, and a mail server hostname.

Domain: The domain name that receives email. For example, the MX record for example.com handles email sent to anyone@example.com.

Priority: A numeric value that determines the order in which mail servers are tried. Lower numbers indicate higher priority.

Mail Server Hostname: The fully qualified domain name (FQDN) of the server that accepts email. This must be a hostname, not an IP address.

Here's an example of how MX records appear in DNS:

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

The first record says: for email to example.com, try mail.example.com with priority 10. The second provides a backup option with lower priority (higher number).

How Priority Values Work

Priority determines which mail server receives email first. The sending server always tries the lowest priority number first.

If that server is unavailable—down for maintenance, unreachable, or returning errors—the sending server moves to the next lowest priority. This continues until either delivery succeeds or all servers have been tried.

Equal priorities create load balancing. When two or more MX records share the same priority, sending servers randomly select between them. Large email providers use this to distribute incoming mail across multiple servers.

Priority spacing affects flexibility. Using 10, 20, 30 instead of 1, 2, 3 leaves room to insert new servers without renumbering everything. Need to add a server between your primary and first backup? Just give it priority 15.

TTL and MX Records

TTL (Time to Live) controls how long DNS servers cache your MX records before checking for updates.

High TTL (like 86400 seconds, or 24 hours) reduces DNS queries but means changes take longer to propagate. If you update your MX records, some servers might use the old values for up to a day.

Low TTL (like 300 seconds, or 5 minutes) means changes take effect quickly but increases DNS query volume. This is useful during migrations when you need flexibility.

Recommended approach: Use a moderate TTL (3600 seconds, or 1 hour) during normal operation. Lower it before making changes, make your updates, verify everything works, then raise it again.

MX Records vs A Records

A common point of confusion is the relationship between MX records and A records.

MX records point to a hostname, not an IP address. When you set up an MX record for mail.example.com, you're specifying a name.

A records map that hostname to an actual IP address. The mail server hostname in your MX record needs its own A record so it can be resolved to an IP.

This two-step process exists for flexibility. You can change the IP address of your mail server by updating the A record without touching the MX record. Any domain using your mail server immediately uses the new IP.

MX Records vs CNAME Records

CNAME records create aliases, pointing one domain name to another. There's an important rule about combining them with MX records.

You cannot have both a CNAME and an MX record for the same domain name. This is a DNS specification limitation.

If you have a CNAME for example.com pointing to something.else.com, you cannot also have MX records for example.com. The CNAME takes over all record types for that name.

This is why root domains (example.com) typically use A records rather than CNAMEs. You need the ability to add MX records for email.

Subdomains can use CNAMEs more freely since email is usually handled at the root domain level.

Multiple MX Records for Redundancy

Most production email setups use multiple MX records. Here's why:

Server failures happen. Hardware breaks, networks go down, and software crashes. Multiple MX records mean email delivery continues even when one server fails.

Maintenance windows become easier. You can take a server offline for updates knowing email will route to alternates.

Geographic distribution improves delivery. Some organizations place MX servers in different regions. Email routes to the nearest available server.

A typical redundant configuration looks like this:

The two priority-10 servers share the load during normal operation. If both fail, the priority-20 backup takes over.

MX Records and Email Security

MX records work alongside other DNS records to secure email:

SPF records specify which servers are allowed to send email from your domain. Check yours at spfrecordcheck.com.

DKIM records contain public keys for verifying email signatures. Test your DKIM setup at dkimtest.com.

DMARC records tell receiving servers how to handle email that fails authentication. Verify your policy at dmarcrecordchecker.com.

These records don't replace MX records—they complement them. MX handles where email goes; SPF, DKIM, and DMARC handle whether it should be trusted.

Common MX Record Problems

Several issues frequently cause email delivery failures:

Missing MX records mean email bounces immediately. This often happens with new domains where email wasn't configured.

Typos in hostnames point to servers that don't exist. Double-check spelling, especially for complex hostnames from email providers.

Stale records after provider changes leave old MX records in place. Email might still route to your previous provider.

Missing A records for MX hostnames prevent resolution. The MX record looks correct, but the hostname doesn't resolve to an IP.

Firewall blocks on port 25 prevent mail delivery even when records are correct. The MX record points to the right place, but the server can't accept connections.

Best Practices for MX Configuration

Follow these guidelines for reliable email delivery:

Always have at least two MX records for redundancy. One server failure shouldn't stop all email delivery.

Use consistent priority spacing like 10, 20, 30. This leaves room for future changes.

Verify hostnames resolve before adding MX records. Check that the mail server hostname has a valid A record.

Test after changes using an MX lookup tool. Confirm the records appear correctly in DNS.

Monitor continuously for unexpected changes or server issues. Problems can develop between manual checks.

Monitor Your MX Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.