MX Records Explained: How DNS Routes Email to the Right Server

Every email you send goes through an MX record lookup before it reaches its destination. When you hit send on a message to jane@example.com, your sending server queries DNS for the MX records of example.com, picks the host with the lowest priority value, opens an SMTP connection, and hands the message off. The whole exchange takes milliseconds and happens billions of times per day.

MX records are a small, well-defined piece of internet infrastructure that does an outsized amount of work. They turn an email address into a delivery destination, they handle failover and load balancing through priority numbers, and they tell email verifiers which domains can receive mail at all. This guide covers exactly what MX records contain, how the lookup process works, the misconfigurations that break delivery, and the relationship between MX records and the other DNS records that make email work.

What an MX Record Actually Is

MX stands for Mail Exchange. An MX record is a DNS resource record that specifies which mail server is responsible for accepting incoming email for a domain. Every domain that wants to receive mail needs at least one MX record published in its DNS zone.

The mechanics: when a sending server has a message for jane@example.com, it doesn't know where to deliver it yet. The address itself is just a label; the routing comes from DNS. The sender's Mail Transfer Agent (MTA) queries DNS for the MX records of example.com, gets back a list of mail servers with priority values, and connects to the one with the lowest priority value first.

One critical clarification: MX records control incoming mail only. Outbound mail uses a completely separate mechanism (your sending server's configuration). Your domain's MX records have nothing to do with where your outbound mail comes from.

Anatomy of an MX Record

A typical MX record looks like this in DNS zone file format:

; Domain    TTL    Class  Type  Priority  Host
example.com.  3600   IN     MX    10        mx1.example.com.
example.com.  3600   IN     MX    20        mx2.example.com.
example.com.  3600   IN     MX    30        backup-mx.example.com.

Each field has a specific job:

• Domain: The domain the MX record applies to.
• TTL (Time To Live): How long DNS resolvers cache this record before re-querying. Common values: 3600 seconds (1 hour) or 86400 seconds (24 hours). Shorter TTLs let changes propagate faster but increase query load.
• Class: Almost always IN (Internet). Inherited from the original DNS spec.
• Type: MX, identifying this as a mail exchange record.
• Priority: An integer from 0 to 65535 indicating preference. Lower is higher priority (counterintuitive). 10 beats 20.
• Host: The fully qualified domain name (FQDN) of the mail server. Must end with a period in zone files. Must resolve to an A or AAAA record (never a CNAME, per RFC 2181).

How Priority Works (And Why It Trips People Up)

The priority field is where most MX confusion lives. The rules:

• Lower numbers are tried first. Priority 10 is preferred over priority 20. The numbering works backward from how priority usually works in casual language.
• Equal priorities are load-balanced. If two MX records share the same priority value, sending servers pick one at random (or distribute load between them).
• Failover is automatic. If the lowest-priority host doesn't respond, the sender tries the next-lowest, and so on down the list.
• The actual numbers don't matter, only the order. Priorities of 1, 2, 3 work identically to 10, 20, 30 or 100, 200, 300. Most administrators use multiples of 10 to leave room for inserting new records between existing ones.

How the Lookup Process Works

When mail arrives at a sending server destined for example.com, the routing sequence is:

1. DNS query. The sender's MTA queries DNS for the MX records of example.com.
2. DNS response. The authoritative DNS server returns the MX list with priority values.
3. Priority sort. The MTA sorts records by priority (ascending).
4. A/AAAA resolution. The MTA resolves the lowest-priority host to an IP address.
5. SMTP connection. The MTA opens an SMTP connection to that IP on port 25.
6. Delivery attempt. The MTA delivers the message via SMTP.
7. Failover if needed. If the connection fails, the MTA tries the next-lowest priority host.

You can run this lookup yourself with dig on Linux/macOS or nslookup on Windows:

# Quick MX lookup
$ dig +short MX gmail.com

# Output (priority host):
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

# Verbose lookup with TTL and authoritative answer
$ dig MX gmail.com +noall +answer

# Output:
gmail.com.    300  IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.    300  IN  MX  10 alt1.gmail-smtp-in.l.google.com.

Real-World MX Configurations

The exact MX records you publish depend entirely on who hosts your email. Three common patterns:

Google Workspace:

Microsoft 365:

Self-hosted with backup:

Notice that Microsoft 365 uses a single MX record at priority 0. That works fine because Microsoft handles failover at their infrastructure level (their host resolves to multiple IPs across data centers). You don't always need multiple MX records; one is sufficient if the host behind it is highly available.

MX vs Other Email DNS Records

MX is one of several DNS record types involved in email. Each handles a different concern:

Critical distinction: MX records affect inbound mail only. SPF, DKIM, and DMARC affect outbound mail authentication. They serve different functions and live in different DNS record types. A domain can have perfect SPF/DKIM/DMARC and still fail to receive mail if MX records are missing or misconfigured, and vice versa.

Common MX Misconfigurations

The MX problems that break email delivery, in rough order of frequency:

MX pointing to a CNAME. RFC 2181 prohibits MX records from pointing to a CNAME alias. The host field must resolve directly to an A or AAAA record. Cloudflare, Route 53, and other modern DNS providers usually catch this, but older or self-hosted DNS configurations don't. Mail to a CNAME-based MX may still work at some receivers but will be rejected by stricter implementations.

Inverted priorities. Setting your primary at priority 50 and backup at priority 10 routes all mail to the backup. Always test priorities after publishing.

Missing MX records entirely. If you delete MX records during a migration without publishing the new ones first, mail bounces immediately. Always publish new records, verify they're live, then remove the old ones.

Conflicting providers. Adding MX records for a new email provider without removing the old ones causes unpredictable routing. Mail randomly arrives at one provider or the other depending on which MX the sending server tried first.

Propagation delays. DNS changes take time to propagate (TTL determines how long). During the propagation window, some senders see new records and others see old ones. Plan migrations during low-traffic windows and use lower TTLs (300-600 seconds) before changes to speed propagation.

MX pointing to an unreachable host. The MX target server must accept SMTP connections on port 25. Firewalls blocking port 25, retired servers still in DNS, or hosts that no longer have valid A records all cause mail to fail.

How Email Verifiers Use MX Records

Email verification services use MX records as the second-stage filter in the verification pipeline. The sequence:

1. Syntax check. Is the address structurally valid (RFC 5322)?
2. MX lookup. Does the domain have MX records? If not, the domain can't receive mail and the address fails immediately.
3. SMTP probe. Connect to the lowest-priority MX host and probe whether the specific mailbox exists.

The MX check filters out massive numbers of obviously-undeliverable addresses cheaply. Domains that have expired, been retired, or never had mail infrastructure don't need an SMTP probe; the MX lookup alone reveals them. This is why the free email checker can rapidly classify addresses without opening thousands of SMTP connections per check.

For high-volume verification through the real-time API, MX caching dramatically improves throughput. Verifying 1,000 addresses at the same domain only requires one MX lookup, not 1,000.

Frequently Asked Questions

Do MX records affect outbound email?

No. MX records control where inbound mail is delivered for a domain. Outbound mail is routed by your sending server using its own configuration, which is unrelated to MX records. Outbound authentication is handled by SPF, DKIM, and DMARC (which are TXT records, not MX records).

What does it mean when priority 10 is "preferred" over priority 20?

Lower priority values are tried first by sending servers. A priority of 10 means "try this host before any host with a higher priority number." It's counterintuitive because in everyday language "high priority" usually means most important, but in DNS MX, lower number equals higher priority.

How many MX records should I have?

One is sufficient if the host behind it is highly available (Microsoft 365 uses one). Two or more provides explicit failover at the DNS level. Most providers publish 2-5 MX records for redundancy, but more isn't inherently better. Quality of the underlying mail infrastructure matters more than the number of MX entries.

Can I have MX records pointing to a CNAME?

No. RFC 2181 explicitly prohibits this. The host field of an MX record must resolve to an A or AAAA record directly. Modern DNS providers usually validate this; some older or self-hosted setups don't, which causes intermittent delivery problems at strict receivers.

How long do MX changes take to propagate?

Up to the TTL value of the old records. If your previous MX records had a TTL of 86400 (24 hours), some senders may use the old records for 24 hours after you change them. To speed migrations, lower the TTL to 300-600 seconds at least 48 hours before the change. After the change, you can return to a longer TTL.

The Bottom Line

MX records do a small, specific job: tell the world where to deliver mail for your domain. Get them right and email just works. Get them wrong (inverted priorities, CNAME targets, missing records, propagation issues) and inbound mail breaks in ways that take hours to diagnose. The mechanics are simple once you internalize that lower numbers are tried first and that MX records control inbound only.

For senders, the relevant overlap is that mail you send to verified-undeliverable addresses (domains with no MX records) damages your reputation. That's exactly the class of address email verifiers catch cheaply via MX lookup. Running addresses through bulk email verification before sending uses the same DNS-level filtering to eliminate undeliverable mail before it leaves your queue.