What is an MX Record?

What an MX record looks like

An MX record has two parts: a priority value and a target hostname. Example:

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

This says "to deliver mail for example.com, try mail1.example.com first (priority 10). If that is unreachable, fall back to mail2.example.com (priority 20)."

For a typical Google Workspace domain, the actual records look like:

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.

Five records spread across Google's mailserver pool. Senders try priority 1 first; if it fails, they fall back to either of the priority-5 servers (chosen at random); if both fail, they try one of the priority-10 servers. This is what high-availability mail routing looks like as DNS.

How priority actually works

Lower number = higher preference. This is the most counterintuitive part of MX records for newcomers. Priority 1 is tried before priority 10. Think of priority as "the order of attempts" rather than "importance."

When multiple records share the same priority — like the two alt1/alt2 records both at priority 5 above — the sender picks one at random. This is how load balancing is expressed: tie the priorities to spread traffic; differ the priorities to set a strict preference order.

The valid range is 0-65535. Common conventions:

• 0 reserved for null MX (see below).
• 10, 20, 30 — classic step-of-10 ordering. Easy to insert new records between existing ones.
• 1, 5, 10 — Google Workspace's convention.
• 100, 200 — large gaps when you anticipate many future records.

Multiple MX records: redundancy and load balancing

Publishing more than one MX record is the standard pattern. Reasons:

• Server outage tolerance. If your primary mailserver is down for any reason — hardware, network, maintenance — senders will keep retrying for up to 5 days, but if a secondary MX is available they switch immediately. Mail flows continuously.
• Geographic distribution. Two MX records pointing at servers in different data centers survive a single-region outage.
• Backup MX from a third party. Services like Cloudflare Email Routing or DynDNS BackupMX queue mail when your primary is down, then deliver when it comes back. Useful for small organizations without two of their own mailservers.
• Load distribution. Equal-priority records spread incoming connections across multiple servers, useful for high-volume domains.

One pitfall: the secondary MX must actually be configured to accept mail for your domain. If it does not know what to do with the mail, it rejects, and the sender keeps retrying the primary. A "backup MX" pointing at a server that does not know your domain is worse than no backup at all.

How MX lookups happen during mail delivery

When a sender's mailserver wants to deliver to you@example.com:

1. DNS query. Look up MX records for example.com.
2. Sort by priority. Ascending — lowest number first.
3. Pick a target. If multiple records share the lowest priority, pick one at random.
4. Resolve the target hostname. Look up A and AAAA records for the chosen MX target.
5. Open SMTP connection. Connect to port 25 on the resolved IP.
6. Deliver or retry. If the SMTP transaction succeeds, done. If the server is unreachable or returns a temporary failure (4xx code), move to the next MX in priority order. If a permanent failure (5xx) is returned, bounce immediately without trying other MX records.

The key thing to understand: fallback to a secondary MX only happens on connection or 4xx failures. A 5xx error from your primary tells the sender to give up entirely — they will not try the secondary. This is correct behavior; 5xx means "I am the right server but I am rejecting this mail."

The null MX record (RFC 7505)

If you have a domain that should never receive mail — a domain used only for serving a website, redirecting URLs, or hosting subdomains for other purposes — publish a null MX record:

example.com.    IN MX  0  .

Priority 0 with a literal dot as the target. Receivers that understand RFC 7505 will immediately bounce any mail addressed to this domain with a permanent error. This is the explicit way to say "no mail accepted here."

Without a null MX, the implicit-MX fallback applies — senders try the domain's A/AAAA records, which usually points at a web server that does not run SMTP. The mail times out and bounces hours later. A null MX returns the bounce in seconds.

TTL: how long resolvers cache

Each MX record carries a TTL (Time To Live) — how long resolvers can cache the answer before re-querying. Typical settings:

• 3600 seconds (1 hour): sensible default for stable production.
• 86400 seconds (1 day): for fully stable records where you do not expect changes for months. Reduces DNS query load.
• 300-600 seconds (5-10 minutes): temporary low TTL set 24-48 hours before a planned change. Resolvers refresh quickly during the cutover.

The standard cutover pattern: 48 hours before changing MX, drop TTL to 300 seconds. Wait 24 hours for the old high-TTL value to expire from caches everywhere. Make the change. Once you confirm new MX is working, raise TTL back to 3600+.

Debugging MX problems

1. Confirm the record exists. Run dig +short MX example.com. The output should show one or more lines like 10 mail1.example.com.. Empty result means no MX is published.
2. Confirm the target resolves. For each MX target, run dig +short A mail1.example.com. An empty result means the MX points at a hostname that does not exist — mail will fail immediately.
3. Test the SMTP port. nc -v mail1.example.com 25 or telnet mail1.example.com 25. You should get an SMTP banner like 220 mail1.example.com ESMTP ready. No banner means the server is not accepting connections, even though DNS says it should.
4. Check propagation. Use a multi-region DNS lookup tool (whatsmydns.net, dnschecker.org) to confirm the MX value is visible from major resolvers globally. Slow propagation can leave stale MX records cached for the TTL duration.
5. Read bounce messages. If senders are getting bounces, the DSN (Delivery Status Notification) tells you exactly what went wrong — DNS resolution failure, connection timeout, 5xx rejection. Each implies a different fix.

Frequently Asked Questions

What does a lower MX priority number mean?

Lower priority number = higher preference. A record with priority 10 is tried before priority 20. The naming is counterintuitive — think of it as the order of attempts, not as importance. When all MX records have the same priority, senders pick one at random for load balancing. Most setups use values like 10, 20, 30 to make the routing intention obvious.

Can I have multiple MX records?

Yes — multiple MX records are standard practice for redundancy. The sender tries the lowest-priority record first; if that mailserver is unreachable or rejects the connection, it falls back to the next-lowest priority, and so on. Cloud-hosted mail providers like Google Workspace and Microsoft 365 publish 4-5 MX records by default so a single data center outage does not lose mail.

What happens if a domain has no MX record?

RFC 5321 specifies a fallback: if no MX record exists, the sender falls back to the A or AAAA record of the domain itself (called the implicit MX). This works but is fragile — most mailservers run on the same hosts as websites, which is rarely the case for production mail. If you want a domain to NOT receive mail at all, publish a null MX record: 0 . (literal dot). RFC 7505 standardized this; receivers reject mail to the domain immediately.

What TTL should I use for MX records?

3600 seconds (1 hour) is a reasonable default for stable production. Drop to 300-600 seconds (5-10 minutes) for 24-48 hours before any planned MX change so caching DNS resolvers refresh quickly during the cutover. After the change stabilizes, raise TTL back to 3600 or higher. High TTLs reduce DNS query load and improve resolution speed for cached entries.

Can an MX record point to a CNAME or IP address?

No to both. RFC 5321 explicitly prohibits an MX target from being a CNAME — receivers that follow strict RFC behavior may reject delivery. The MX target must be a hostname that resolves directly to A or AAAA records. Pointing MX to an IP is also invalid; the value must be a hostname. If your mail provider gave you a CNAME or IP for their mailserver, ask them for the underlying hostname instead.