MX Records

Email addresses are a beautiful abstraction. When you write user@example.com, you're addressing a domain—but domains don't receive email. Servers do. MX records bridge that gap, telling the Internet which mail servers speak for a domain.

Without MX records, that email you sent would have nowhere to go. The sending server would stare at "example.com" and have no idea which machine actually accepts mail for it.

What an MX Record Contains

Every MX record carries two pieces of information:

Priority (sometimes called preference): A number that determines which server to try first. Here's the quirk that trips people up: lower numbers mean higher priority. Priority 10 beats priority 20.

Mail server hostname: The fully-qualified domain name of a server that accepts mail.

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

This tells the world: "example.com has two mail servers. Try mail1 first. If that fails, try mail2."

The Delivery Process

When a mail server needs to deliver a message to recipient@example.com:

1. Extract the domain from the email address (example.com)

2. Query DNS for MX records:

$ dig example.com MX

;; ANSWER SECTION:
example.com.    3600    IN    MX    10 mail1.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.

3. Sort by priority (lowest number first)

4. Look up the IP address of the winning server:

$ dig mail1.example.com A

;; ANSWER SECTION:
mail1.example.com.    300    IN    A    203.0.113.10

5. Connect and deliver via SMTP on port 25

6. On failure, try the next server in the priority list

Priority: The Backwards Ranking System

The priority system feels backwards because it is. Lower numbers win:

• Priority 10 is tried before priority 20
• Priority 20 is tried before priority 30
• The actual numbers don't matter—only their relative order

Convention uses increments of 10 (10, 20, 30) to leave room for inserting servers later. You could use 1, 2, 3 or 100, 200, 300—the behavior is identical.

Equal priorities create load balancing. When multiple servers share a priority, sending servers pick randomly among them:

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

Incoming mail distributes across all three servers.

Common Configurations

Single server (simple, no redundancy):

example.com.    IN  MX  10  mail.example.com.

Primary with backup (failover):

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

Load balanced (equal priority):

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

Cloud email service (Google Workspace example):

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.

Spam filtering service:

example.com.    IN  MX  10  filter.spamservice.com.

Mail routes through the filter first, then the service forwards clean mail to your actual server.

The Rules

MX records have strict requirements:

Must point to hostnames, not IP addresses:

# Correct:
example.com.    IN  MX  10  mail.example.com.

# Wrong:
example.com.    IN  MX  10  203.0.113.10

Those hostnames must have A or AAAA records that resolve to actual IP addresses.

Cannot point to CNAMEs. The target hostname needs a direct A/AAAA record:

# Wrong:
mail.example.com.   IN  CNAME   server.hosting.com.

# Correct:
mail.example.com.   IN  A       203.0.113.10

Every MX record needs a priority value, even if you only have one mail server.

What Happens Without MX Records?

If a domain has no MX records, RFC 5321 says sending servers should fall back to the domain's A record—treating the domain itself as the mail server.

Don't rely on this. Many mail servers reject domains without explicit MX records. It provides no redundancy, no load balancing, and signals misconfiguration. Always set MX records for domains that receive email.

Subdomains Get Their Own Records

Subdomains don't inherit MX records from parent domains:

example.com.        IN  MX  10  mail.example.com.
sales.example.com.  IN  MX  10  sales-mail.example.com.

Email to user@example.com and user@sales.example.com route to different servers. If sales.example.com has no MX record, it can't receive email—it doesn't automatically use the parent's configuration.

TTL: Controlling Cache Duration

The TTL (Time To Live) tells DNS resolvers how long to cache the record:

example.com.    3600    IN  MX  10  mail.example.com.

This record caches for 3600 seconds (one hour).

Before making changes: Lower TTL to 300-600 seconds so the change propagates quickly.

After changes stabilize: Raise TTL back to 3600+ seconds to reduce DNS query load.

Checking Your MX Records

# dig (most detailed)
$ dig example.com MX +short
10 mail1.example.com.
20 mail2.example.com.

# nslookup
$ nslookup -type=MX example.com

# host
$ host -t MX example.com

Online tools like MXToolbox provide additional diagnostics.

The Trailing Dot

In DNS zone files, fully-qualified domain names end with a dot:

# Unambiguous:
example.com.    IN  MX  10  mail.example.com.

# Ambiguous (might become mail.example.com.example.com):
example.com.    IN  MX  10  mail.example.com

The trailing dot means "this is the complete name." Without it, some DNS servers append the zone name again.

MX Records and Email Security

MX records interact with SPF in a useful way. The SPF "mx" mechanism authorizes your MX servers to send mail:

example.com.    IN  TXT  "v=spf1 mx -all"

This says: "Only the servers in our MX records are allowed to send email for example.com."

Migrating to New Mail Servers

1. Lower TTL days before the migration (300-600 seconds)
2. Configure new servers completely before touching DNS
3. Update MX records to point to new servers
4. Wait for propagation (minutes to hours, occasionally longer)
5. Keep old servers running briefly to catch cached DNS stragglers
6. Migrate mailboxes from old to new
7. Raise TTL back to normal values