MX Records Explained: How Email Routing Works

MX (Mail Exchange) records are DNS records that specify which mail servers are responsible for receiving email for a domain. When someone sends an email to user@example.com, the sending mail server queries the DNS for example.com's MX records to find out where to deliver the message.

Without properly configured MX records, email sent to your domain will bounce or fail to deliver. MX records are one of the most critical DNS configurations for any domain that receives email.

Here's what happens when an email is sent:

1. The sender's mail server extracts the domain from the recipient's email address (everything after the @).
2. It queries DNS for the MX records of that domain.
3. DNS returns one or more MX records, each containing a mail server hostname and a priority value.
4. The sending server connects to the mail server with the lowest priority number (highest priority) first.
5. If that server is unavailable, it tries the next one in order of priority.
6. The email is delivered to the first available mail server.

Priority values determine the order in which mail servers are tried. A lower number means higher priority. For example:

In this setup, mail1 is the primary server. If it's down, mail2 is tried, then mail3. This provides redundancy and ensures emails are delivered even during server outages.

Google Workspace (Gmail): Google Workspace uses five MX records with different priorities, all pointing to Google's mail servers (ASPMX.L.GOOGLE.COM, ALT1.ASPMX.L.GOOGLE.COM, etc.). This provides high availability across multiple data centers.

Microsoft 365 (Outlook): Microsoft 365 typically uses a single MX record pointing to your-domain.mail.protection.outlook.com. Microsoft handles redundancy internally.

Custom mail servers: Organizations running their own mail servers typically configure a primary MX record pointing to their main mail server and one or more backup MX records pointing to secondary servers.

Third-party email services (Zoho, ProtonMail, Fastmail): Each provider has their own specific MX records that you configure in your DNS settings. Always follow the exact instructions provided by your email service.

Use LookMyIP's free MX checker tool at lookmyip.com/mx. Enter any domain name to instantly see all configured MX records, their priorities, and the IP addresses they resolve to.

Command line methods:

On macOS/Linux: nslookup -type=mx example.com or dig mx example.com

On Windows: nslookup -type=mx example.com

These commands return the MX records along with their priority values and TTL (Time to Live).

Emails not being received: Check that MX records exist and point to the correct mail servers. A missing or misconfigured MX record is the most common cause of email delivery failure.

Emails going to the wrong server: Verify the priority values. The server with the lowest priority number receives mail first. If you recently switched email providers, old MX records pointing to the previous provider may still be cached.

Delayed email delivery: If the primary mail server is slow to respond, the sending server may queue the message and retry. Check whether your primary MX server is operational and responding on port 25.

SPF and DKIM failures: While not directly related to MX records, email authentication issues often accompany MX changes. Make sure your SPF, DKIM, and DMARC records are updated to match your current mail server configuration.

DNS propagation delays: After changing MX records, allow up to 48 hours for the changes to propagate globally. During this window, some emails may still be sent to the old servers.

MX priority is the most misunderstood part of mail routing, largely because the number works backwards from intuition: lower is preferred.

Given this set:

10  mail1.example.com
20  mail2.example.com
20  mail3.example.com
50  backup.example.com

A sending server tries mail1 first. If it cannot connect, it moves to priority 20 — and because two hosts share that value, it picks between them at random, which distributes load evenly. Only if both fail does it reach backup.

Three consequences follow from this that trip people up regularly.

Equal priorities load-balance, they do not fail over in order. If you list two hosts at priority 10 and one of them is broken, roughly half of inbound mail hits the broken host on the first attempt. Senders will retry, so mail is usually not lost, but delivery is delayed by minutes to hours. If you want strict failover, the priorities must differ.

A backup MX that does not know your users is a spam liability. The classic design — a low-priority backup MX that accepts everything and spools it — is now actively harmful. Spammers deliberately target the *highest* priority number precisely because backup servers historically performed less filtering, and a backup that accepts mail for non-existent addresses then has to generate backscatter bounces. If you run a backup MX, it must validate recipients exactly as the primary does. For most organisations the better answer is no backup MX at all: sending servers already queue and retry for several days under RFC 5321.

The relative gap between numbers is meaningless. Priorities 10 and 20 behave identically to 1 and 2, or 100 and 900. Only the ordering matters. The convention of using multiples of ten simply leaves room to insert a host later without renumbering.

A few requirements in the MX specification cause real-world failures when they are broken.

An MX record must point to a hostname, never to an IP address. 10 192.0.2.25 is invalid. Some servers reject it outright, others behave unpredictably. Create an A record for a hostname and point the MX at that.

An MX target must not be a CNAME. RFC 2181 prohibits it. A CNAME target can appear to work with some senders and fail silently with others, producing the worst kind of intermittent delivery bug. The target must resolve directly to A or AAAA records.

A domain with no MX record falls back to its A record. If example.com has an A record but no MX, senders will attempt delivery to that A record on port 25. This is the source of a common surprise: a company points its apex domain at a web server, never configures MX, and then discovers that mail for the domain is being attempted against the web host. If a domain should not receive mail at all, publish a null MX — a single record with priority 0 and a target of . — which tells senders to reject immediately rather than retry for days:

example.com. IN MX 0 .

MX records live at the domain apex for the address domain. Mail to user@example.com uses the MX for example.com. Mail to user@mail.example.com uses the MX for mail.example.com, which is a different lookup entirely. Subdomain mail needs its own MX records.

Getting these exactly right, including the trailing dots your DNS provider may or may not require, saves a lot of debugging.

Google Workspace (current single-host configuration):

1  smtp.google.com

Google's older five-record set (aspmx.l.google.com plus four alternates) still works, but new tenants should use the single record above.

Microsoft 365:

0  <tenant>-com.mail.protection.outlook.com

Replace <tenant> with your domain with dots converted to hyphens — example.com becomes example-com.

Zoho Mail:

10  mx.zoho.com
20  mx2.zoho.com
50  mx3.zoho.com

Fastmail:

10  in1-smtp.messagingengine.com
20  in2-smtp.messagingengine.com

Proton Mail:

10  mail.protonmail.ch
20  mailsec.protonmail.ch

Whichever provider you use, changing MX records is one of the few DNS changes where a mistake is immediately and painfully visible. Lower the TTL to 300 seconds a day before the change, verify the new records with the MX checker before decommissioning anything, and leave the old mail server accepting mail for at least 72 hours afterwards to catch senders with stale caches.

How long do MX changes take to take effect?

Bounded by the TTL on the old record. If the TTL was 3600, senders that already looked up your domain may keep using the old server for up to an hour. Senders that have never contacted you get the new record immediately. Lowering the TTL in advance is what makes a cutover fast.

Can I have MX records at two different providers at once?

Technically yes, and it is almost always a mistake. Mail will be split unpredictably between them based on priority and retry behaviour, and users will find some messages in one mailbox and some in the other. Migrations should use a single MX set pointed at the new provider, with forwarding configured on the old one.

Why does my mail work but the MX checker shows an error?

The usual cause is a CNAME or an IP address used as the MX target. Some senders tolerate both; others do not. It works until it does not, typically when one important correspondent's mail server turns out to be strict.

Do I need MX records to send email?

No. Sending depends on SPF, DKIM and DMARC, not MX. But receiving servers frequently check whether the sending domain can also receive mail, and a domain with no MX at all looks more like a throwaway spam domain. If you send from a domain that does not receive, publish a null MX rather than nothing.

What does "MX record not found" mean when the record clearly exists?

Check whether you created it on the right zone — adding an MX for mail.example.com when you meant example.com is the most common version of this. Also check for a trailing-dot error: smtp.google.com without the trailing dot may be interpreted as smtp.google.com.example.com by some DNS panels.