MX Records: How Email Finds Your Server

Every email delivery begins with a question: who accepts mail for this domain?

When you send an email to someone@example.com, your mail server doesn't magically know where example.com receives its mail. It asks. Specifically, it queries DNS for MX (Mail Exchanger) records—the DNS records that answer "who speaks for this domain when it comes to email?"

The answer comes back as a hostname: "Send mail for example.com to mail.example.com." Your server then looks up that hostname's IP address and delivers the message.

Why Hostnames, Not IP Addresses

Notice the two-step process: MX record points to hostname, hostname points to IP address. This seems like unnecessary indirection until you need to change mail servers.

If MX records pointed directly to IP addresses, migrating to a new mail server would mean updating MX records for every domain you host—then waiting for DNS caches worldwide to expire. Instead, you update a single A record for your mail server hostname, and every domain using that hostname instantly points to the new IP.

This indirection is required by RFC 5321, the SMTP specification. MX records must point to hostnames, never directly to IP addresses. Many mail servers will reject mail from domains that violate this rule.

Priority: Automatic Failover

MX records include a priority value—a number that determines which server to try first:

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

Lower numbers mean higher priority. When email arrives for example.com, the sending server tries mail.example.com (priority 10) first. Only if that server is unreachable does it fall back to backup.example.com (priority 20).

This is failover built into the protocol. Your backup server doesn't need to coordinate with the primary. It doesn't need to know the primary is down. The sending server figures it out—try the preferred server, fail over if necessary.

Load Distribution

What happens when two MX records share the same priority?

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

Sending servers choose randomly between them. This distributes incoming email across multiple servers without any load balancer—the randomness is baked into the protocol.

Combine these patterns for sophisticated configurations:

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

Load-balance across mail1 and mail2 during normal operation, fail over to backup if both go down.

Cloud Email Configurations

Google Workspace and Microsoft 365 reveal two philosophies of redundancy.

Google Workspace:

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.

One primary (priority 1), two alternates for load distribution (priority 5), two more for deeper failover (priority 10). Five layers of redundancy, explicit in the DNS.

Microsoft 365:

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

Just one record. Microsoft handles all redundancy internally—their single hostname routes to a globally distributed infrastructure. The simplicity is the point.

Diagnosing MX Problems

When email isn't arriving, MX records are the first thing to check:

dig example.com MX

Common problems:

• No MX records at all. Email has nowhere to go.
• Priorities backwards. Backup server has a lower number than primary, so it receives all the traffic.
• MX pointing to a CNAME. RFC 5321 prohibits this. Some servers tolerate it; others reject your mail.
• MX pointing directly to an IP. Violates the SMTP specification. Many servers will reject your mail.

The Coordination Problem

MX records solve something that seems impossible: millions of mail servers worldwide need to know where to deliver email for millions of domains, without any central authority telling them.

Rather than maintaining massive lookup tables or requiring manual configuration, MX records let each domain declare "send my mail here." The priority system provides failover and load distribution. The sending server handles the logic. No coordination required.

Your domain's MX records are a public declaration of how to reach you. Every mail server in the world can find them, trust them, and act on them.

Sources