MX Records Explained: How Email Routing Works

What is an MX record?

MX stands for Mail Exchanger. An MX record is a DNS record that tells the world: "If you want to send email to anyone @example.com, here's the server (or servers) to deliver it to." Without MX records, no one can email your domain.

An MX record has two essential parts:

1. The hostname of a mail server. Always a hostname, never an IP — that's a strict requirement of the DNS spec (RFC 5321 §5.1).
2. A priority number that orders multiple MX records when more than one is defined.

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

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

This says: "To deliver mail to example.com, try mail.example.com first (priority 10). If it's unreachable, fall back to mail-backup.example.com (priority 20)."

The hostnames themselves resolve via separate A or AAAA records:

mail.example.com.        3600   IN   A      203.0.113.10
mail-backup.example.com. 3600   IN   A      198.51.100.20

How email routing actually works

When alice@othercompany.com sends mail to bob@example.com, the sending server (Alice's MTA) does this:

1. Extract the recipient domain. "example.com".
2. Query DNS for MX records at example.com.
3. Sort the returned MX records by priority, ascending (lower number = higher priority).
4. Resolve each MX hostname to one or more A/AAAA records.
5. Open an SMTP connection to the highest-priority host on port 25.
6. If that fails (connection refused, timeout, 4xx temporary failure), try the next host in the list.
7. If every MX fails, the sender queues the message and retries periodically — typically for 3–5 days — then bounces it with a 5xx delivery failure to the original sender.

An important fallback rule (RFC 5321 §5.1): if a domain has no MX records, the sender falls back to the domain's A record and attempts delivery there. This is called the "implicit MX" rule. It exists for historical reasons and is widely supported, but you should never rely on it — always publish explicit MX records.

A related but stricter modern recommendation (RFC 7505): if a domain explicitly doesn't accept email, publish a null MX — a single MX record with priority 0 and hostname ".":

noreply.example.com.   3600   IN   MX   0   .

This signals "this domain does not receive email" and causes well-behaved senders to bounce immediately instead of queuing for days.

The priority field

The priority (also called "preference" in the DNS spec) is a 16-bit unsigned integer — any value from 0 to 65535. Lower values are preferred. The number itself has no meaning beyond the ordering: a record with priority 10 and one with priority 20 behave identically to records with priorities 1 and 2, or 100 and 200.

The convention is to use round numbers with gaps, so you can insert new records without renumbering. A typical scheme:

• 10 — primary MX
• 20 — secondary
• 30 — tertiary / backup
• 40–100 — reserved for future additions

If two MX records have the same priority, senders distribute traffic between them — usually round-robin, sometimes randomised. This is how cloud providers like Google Workspace spread inbound mail across four equally-weighted servers (more on that below).

Multi-MX failover

Failover is the original reason MX records have priorities. Picture a small business with two mail servers: a primary in their office and a secondary at a colocation facility. Their MX records:

example.com.   3600   IN   MX   10   primary.mail.example.com.
example.com.   3600   IN   MX   50   colo.mail.example.com.

Day-to-day, all inbound mail goes to primary. If the office loses its internet connection, sending MTAs try primary, get a timeout, and fall through to colo. colo queues the messages and forwards them to primary when it comes back online.

What does "failure" mean for the fallback to trigger? An SMTP sender treats these as reasons to try the next MX:

• TCP connection refused or timeout.
• SMTP greeting timeout or malformed.
• 4xx response codes (temporary failure) on MAIL FROM or RCPT TO.

It does not fall through on 5xx responses — those are permanent failures and the message bounces.

An important subtlety: the sender's queue is its own. The fallback decision happens per-attempt. A message rejected by the primary with a 5xx never reaches the backup; a message that gets a 4xx is requeued, and the next retry might land at the primary again (which by then may be working) or at the backup.

Primary vs backup MX: when does it actually matter?

Twenty years ago, backup MX records were standard practice — ISPs ran "secondary MX" services that would receive mail when your server was down and forward it later. Today, with cloud-hosted email (Google Workspace, Microsoft 365, Fastmail, etc.) and MTAs that retry for days, backup MX is mostly unnecessary and sometimes counterproductive.

Reasons modern setups often skip a backup MX:

• Cloud providers are highly available. Google Workspace publishes four equally-priority MX records, all of which point at Google's redundant infrastructure. A backup MX outside Google adds no real reliability.
• Backup MX is a spam vector. Spammers often deliver to the lowest-priority backup MX because backups historically have looser anti-spam policies than the primary. If your backup doesn't have identical filtering to your primary, you've opened a hole.
• Modern senders queue for days anyway. A temporary primary outage means a few hours' delay, not lost mail.

When does a backup MX still make sense? Self-hosted setups with limited redundancy, or organisations with regulatory requirements around uptime. If you use one, configure it to run the same anti-spam and relay rules as the primary.

Common provider MX configurations

Most domains use a hosted email provider rather than running their own mail server. Here are the canonical MX records for the major providers:

Google Workspace

example.com.   3600   IN   MX   1   smtp.google.com.

As of 2023, Google replaced the older aspmx.l.google.com / alt1–alt4.aspmx.l.google.com setup with a single smtp.google.com record. Behind the scenes, smtp.google.com still resolves to multiple IPs across Google's network for redundancy. The older setup still works, but new domains should use the simplified form.

Older (still functional) configuration:

example.com.  3600  IN  MX   1   aspmx.l.google.com.
example.com.  3600  IN  MX   5   alt1.aspmx.l.google.com.
example.com.  3600  IN  MX   5   alt2.aspmx.l.google.com.
example.com.  3600  IN  MX  10   alt3.aspmx.l.google.com.
example.com.  3600  IN  MX  10   alt4.aspmx.l.google.com.

Microsoft 365 / Exchange Online

example.com.   3600   IN   MX   0   example-com.mail.protection.outlook.com.

The hostname is your domain with dots replaced by hyphens, suffixed with .mail.protection.outlook.com. Microsoft routes mail to the appropriate datacenter automatically based on this hostname.

Fastmail

example.com.   3600   IN   MX   10   in1-smtp.messagingengine.com.
example.com.   3600   IN   MX   20   in2-smtp.messagingengine.com.

Apple iCloud Custom Email Domain

example.com.   3600   IN   MX   10   mx01.mail.icloud.com.
example.com.   3600   IN   MX   10   mx02.mail.icloud.com.

Zoho Mail

example.com.   3600   IN   MX  10   mx.zoho.com.
example.com.   3600   IN   MX  20   mx2.zoho.com.
example.com.   3600   IN   MX  50   mx3.zoho.com.

Always check your provider's current official documentation — these records do occasionally change, and providers usually publish a single canonical source for the correct values.

MX, SPF, and the sending IP

One of the most common confusions in email is the relationship between MX records (receiving) and SPF / sending IPs.

MX is for inbound only. It says "send mail addressed to my domain to these servers." It says nothing about where your outbound mail comes from.

The IPs that send mail from your domain are governed by SPF. They do not need to be your MX hosts. It's normal — in fact, almost universal — for outbound mail to go through a completely different infrastructure than inbound:

• Inbound to example.com → Google Workspace MX.
• Outbound transactional mail from example.com → Postmark IPs (different network).
• Outbound marketing from example.com → Mailchimp IPs (yet another network).

All three of those outbound sources must appear in your SPF record. Your MX record can stay pointed only at Google. The mistake to avoid is publishing v=spf1 mx ~all (the mx mechanism) and assuming that covers your outbound. The mx mechanism only authorises mail from your MX hosts; if your outbound goes through Postmark, that mechanism doesn't help.

See our SPF guide for how to build a record that covers all your outbound senders.

Reverse DNS / PTR records

Reverse DNS (PTR records) is the other half of the IP ↔ hostname mapping. While A records map mail.example.com → 203.0.113.10, PTR maps 203.0.113.10 → mail.example.com.

For email, PTR matters in two places:

1. Outbound deliverability. When your mail server connects to a remote MX, the remote server looks up the PTR of your IP. If the PTR is missing, generic ("static-203-0-113-10.isp.net"), or doesn't resolve back to the same IP (a "matching PTR"), spam filters become much more suspicious. Major providers like Gmail outright require valid forward-confirmed reverse DNS (FCrDNS) for bulk senders — see our Gmail/Yahoo requirements guide.
2. Receiving mail server identification. Your MX hostnames should also have proper PTRs. This helps the sender's logs and diagnostic tools.

To check the PTR for an IP:

$ dig -x 203.0.113.10 +short
mail.example.com.

PTRs are configured by the IP block's owner — that's your hosting provider (AWS, Hetzner, Linode, etc.), not your DNS host. For each outbound sending IP you control, log into the hoster's panel and set the PTR. The PTR's value should be a hostname whose A record points back to the same IP — that's the FCrDNS requirement.

Common breakage modes

No MX record → "address rejected" bounces

Without MX records (and without an A record fallback), sending mail to your domain returns a permanent failure like 550 5.1.2 Address rejected: domain doesn't accept mail. Always publish an MX, even if you're using a "do-not-reply" address.

MX pointing to a CNAME → technically invalid

RFC 2181 §10.3 explicitly forbids MX records from pointing to CNAMEs. Many resolvers tolerate it; others (especially older mail servers) silently fail. If you must alias a mail host, do it at the A record level instead.

Wrong:

example.com.        IN   MX     10   mail.example.com.
mail.example.com.   IN   CNAME       mail.provider.com.   ; ← invalid

Right:

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

MX pointing to an IP → not allowed

Same RFC, different clause: the right-hand side of an MX must be a hostname. example.com IN MX 10 203.0.113.10 is invalid, even though some sloppy resolvers accept it.

Trailing dot mistakes in zone files

In zone-file syntax, a hostname without a trailing dot is interpreted as relative to the current zone. So in example.com's zone:

example.com.   IN   MX   10   mail   ; resolved as mail.example.com.

That might be what you want — or it might silently break if you intended mail.provider.com. Always use fully qualified names with the trailing dot, especially when pointing at an external provider.

Wrong priority causes provider switching during failover

If your primary and backup MX have different filtering rules, an upstream issue at the primary that returns 4xx codes will spill traffic over to the backup. If the backup is on a different domain, your DKIM, SPF, and DMARC behaviour can change unexpectedly. Test that failover by temporarily firewalling traffic to the primary.

"mx" mechanism in SPF doesn't cover outbound

Covered above — using v=spf1 mx ~all authorises your receiving servers to send mail, but it does nothing for your transactional and marketing providers.

TXT records mistaken for MX

SPF and DMARC records are TXT records, not MX. They live alongside the MX record but serve completely different purposes. Confusing the two is surprisingly common in early setups.

Next steps

1. Check your MX records — verify priority, resolution, and provider.
2. Audit your SPF record to make sure outbound senders are covered (remember: mx mechanism only covers your inbound hosts).
3. Read the SPF guide for the full inbound vs outbound separation.
4. Read the Gmail/Yahoo requirements guide — PTR records, TLS, and other infrastructure that interacts with your MX setup.
5. Run a Domain Health report to see everything — MX, SPF, DKIM, DMARC, PTR — on a single screen.