MX Records Explained: How Email Routing Works (2026)

An MX record is the DNS entry that tells the rest of the internet which servers accept email for your domain. Every message sent to an address at your domain is routed by its MX record, which makes it the foundation of inbound mail — get it wrong and you simply stop receiving email. This guide explains what an MX record is, how MX record priority works, the correct MX record syntax with a real MX record example, how the major providers configure it, and the misconfigurations that quietly break delivery. It pairs with the authentication standards in our email authentication hub, which secure the mail your MX records route.

What is an MX record?

MX stands for Mail Exchanger. An MX record is a DNS record that names the mail server responsible for receiving email on behalf of your domain, along with a preference number that sets its priority. When someone sends a message to you@yourdomain.com, their server looks up your domain’s MX record to find out where to deliver it. MX records were introduced in RFC 974 and their handling is defined by RFC 5321, the core SMTP standard. Crucially, an MX record always points to a hostname — never to a raw IP address.

How an MX record routes mail

1. A sending server takes the domain part of the recipient address.
2. It queries that domain’s MX records and sorts them by preference — lowest number first.
3. It resolves the chosen target hostname to an IP via its A/AAAA record.
4. It connects on port 25 and delivers the message.
5. If that server is unreachable, it falls back to the next MX record by priority.

If a domain has no MX record at all, RFC 5321 says senders should fall back to the domain’s A/AAAA record as an implicit mail server — but this is a “should,” not a guarantee, and stricter servers will simply bounce the mail. That is why you should always publish an explicit MX record rather than relying on the fallback.

MX record syntax and priority

An MX record has two parts after the name: a preference number and a target hostname. The MX record priority number is a value from 0 to 65535, and the lowest number is the most preferred. Equal numbers are load-balanced — senders pick among them at random.

MX record example

Here is an MX record example with a primary server and a backup for failover:

example.com.   IN MX 10 mx1.example.com.
example.com.   IN MX 20 mx2.example.com.

Mail is delivered to mx1 first; if it is down, senders try mx2. To load-balance instead, give two servers the same preference. A domain that sends and receives no mail at all should publish a “Null MX” (defined in RFC 7505) — a single record example.com. IN MX 0 . — which cleanly tells the world the domain accepts no email and helps cut spoofing on parked domains.

How the major providers set the MX record

When you use a hosted email provider, you point your MX record at their servers. The exact value is provider-specific and occasionally changes, so always copy the current value from your provider’s admin console rather than from an old tutorial:

• Google Workspace now uses a single record, smtp.google.com at priority 1 (the older five-record ASPMX set still works — use one or the other, never both).
• Microsoft 365 uses a single tenant-specific record ending in mail.protection.outlook.com at priority 0; Microsoft is migrating newer domains to a different format, so copy the exact value from the admin center.

MX records, A records, and CNAMEs

To understand what is an MX record’s relationship to the rest of your DNS, it helps to see how the record types interact. An MX record does not contain an IP address — it contains a hostname, and that hostname must have its own A record (for IPv4) or AAAA record (for IPv6) so the sending server can find the actual machine. In other words, mail delivery is a two-step lookup: first the MX record to find the mail server’s name, then that name’s A/AAAA record to find its address. This is why a target hostname with no A/AAAA record silently breaks delivery even when the MX record itself looks perfect.

It is also why an MX record must never point to a CNAME (an alias). The mail standards explicitly forbid it, because resolving an MX to a CNAME to yet another record introduces ambiguity that different servers handle differently — the result is mail that delivers for some senders and bounces for others. Always point the MX record at a real, canonical hostname that resolves directly to an address. The same rule rules out pointing an MX record at a bare IP address, which is simply malformed and ignored.

Multiple MX records: failover and load balancing

Most production domains publish more than one MX record, and the priority numbers decide how they are used. Give two servers different priorities and you get failover: senders always try the lowest number first and only fall back to the higher one if the primary is unreachable. Give two servers the same priority and you get load balancing: senders pick between them at random, spreading inbound mail across both. Large mail platforms combine the two, publishing several equal-priority front-end servers plus higher-priority backups.

A word of caution that surprises people: a backup MX at a higher priority number is only useful if that backup server is itself configured to accept and queue your mail. An MX record that points at a server which does not know about your domain does not provide redundancy — it provides a black hole. Microsoft, for instance, notes that publishing multiple MX records can cause problems, and many modern hosted providers deliberately use a single, well-chosen MX record rather than a sprawl of backups.

Migrating email providers without losing mail

Changing email providers is the moment MX records most often go wrong, and the failure is always the same shape: the new provider’s MX record is added, but the old one is left in place or still wins on priority, so mail splits unpredictably between two systems. Before you cut over, lower your MX record’s TTL a day in advance so the change propagates quickly. At cutover, remove every old MX record in the same edit that adds the new one, then verify with a lookup that only the new provider’s record is returned. Finally, confirm a test message actually lands in the new mailbox before you consider the migration done.

Common MX record mistakes

• Pointing an MX record at a CNAME. This is prohibited (RFC 2181) and causes intermittent or total delivery failure. The target must be a hostname with its own A/AAAA record.
• Pointing an MX record at an IP address. Also invalid — the value must be a hostname.
• Leaving an old provider’s MX in place after migrating. The single most common cause of “we stopped receiving email”: two providers’ MX records coexisting, or the old one still winning on priority.
• Wrong priority ordering so backup servers receive primary traffic.
• A target hostname with no A/AAAA record, which resolves to nothing.

MX record best practices

• Always publish an explicit MX record — never rely on the implicit A-record fallback.
• Point to real hostnames with valid A/AAAA records, never a CNAME or IP.
• Use priority deliberately: lowest number is primary; use equal numbers only when you genuinely want load balancing.
• Remove stale MX records immediately after any migration.
• Use a Null MX on no-mail domains and pair it with a strict SPF record.
• Remember MX is only inbound. It does nothing for the trustworthiness of mail you send — that is the job of SPF, DKIM and DMARC, and of reverse DNS on your sending IPs. See the wider picture in our deliverability hub.

How to check your MX record

Whenever you change mail providers or set up a new domain, verify the MX record before trusting it. From a terminal you can run dig MX yourdomain.com +short (or nslookup -type=mx yourdomain.com on Windows) and confirm that the records returned are exactly the ones your provider specifies — same hostnames, same priorities, and nothing left over from a previous host. Then check that each target hostname resolves to an address with dig A mail.yourdomain.com, because an MX pointing at a hostname with no A/AAAA record is a silent failure. Our free MX lookup tool does the same checks in the browser and is the quickest way to confirm a domain’s mail routing at a glance. The final and most important test is always a real one: send a message to an address at the domain and confirm it arrives in the right mailbox.

Related reading

• SPF records guide
• DKIM records guide
• DMARC records guide
• BIMI records guide
• Reverse DNS (PTR) guide

MX record FAQ

What does the MX record priority number mean?

It is a preference value from 0 to 65535, and the lowest number is tried first. The numbers are only relative ordering hints — 10, 20, 30 behaves identically to 1, 2, 3. Servers with equal numbers share the load.

Can an MX record point to a CNAME?

No. An MX record must point to a canonical hostname that has its own A or AAAA record. Pointing it at a CNAME violates the DNS standards and causes unreliable delivery, so always use a real mail-server hostname.

What happens if a domain has no MX record?

Senders are supposed to fall back to the domain’s A/AAAA record as an implicit mail server, but this is a recommendation, not a rule, and strict servers will bounce the message instead. Always publish an explicit MX record so delivery is predictable.

What is a Null MX record?

A Null MX is the record 0 . (priority zero, a single dot as the target) defined in RFC 7505. It explicitly declares that a domain accepts no email, which prevents pointless delivery attempts and reduces spoofing on parked or send-only domains. It must be the only MX record on the domain.

Can I have more than one MX record?

Yes. Multiple MX records provide failover (different priorities) or load balancing (equal priorities). Just make sure they all belong to the same mail provider — leftover records from a previous host are the most common reason inbound mail breaks after a migration.

Does the MX record affect email I send?

No. The MX record only controls inbound mail — where messages to your domain are delivered. The reputation and authentication of mail you send are governed by SPF, DKIM, DMARC and reverse DNS, which are separate from your MX configuration.