MX Records Explained: How Email Finds Your Mail Server

When someone sends an email to accounts@example.com, their mail server has to work out which machine on the internet accepts mail for example.com. It finds out by looking up the domain's MX record. Get the MX records right and mail flows invisibly; get them wrong and messages bounce, or worse, sit in a queue for days before anyone notices. This article explains how MX records work and how to manage them safely.

What an MX record is

MX stands for mail exchanger. An MX record is a DNS record that names a server responsible for receiving email for a domain, together with a priority number. A domain usually has two or more:

example.com.   3600   IN   MX   10 mx1.mailprovider.net.
example.com.   3600   IN   MX   20 mx2.mailprovider.net.

Each record has four useful parts: the domain it applies to (example.com), the TTL (3600 seconds), the priority (also called preference: 10, 20) and the target host name.

How a sending server uses MX records

1. The sender's server takes the domain after the @ sign and asks DNS for its MX records.
2. It sorts them by priority, lowest number first.
3. It looks up the A or AAAA record of the first target to get an IP address.
4. It connects to that address on TCP port 25 and tries to deliver.
5. If that server is unreachable or returns a temporary error, it tries the next priority. If all fail, it queues the message and retries over time, typically for several days, before bouncing it.

When two records share the same priority, senders pick between them, spreading the load. Hosted email providers often publish several equal-priority records for exactly this reason.

Priority, backups and why "lowest wins"

The numbers themselves are arbitrary; only their order matters. 10 and 20 behave exactly like 1 and 5. Leaving gaps simply makes it easy to insert another server later.

A "backup MX" with a higher number used to be common for self-hosted mail, so that mail could queue somewhere if the main server was down. With modern hosted email it is rarely needed: the providers' servers are redundant, and senders queue and retry on their own. A poorly configured backup MX can actually hurt, because spammers often target the lower-priority server hoping its filtering is weaker. Only add one if it applies the same spam filtering and recipient checks as the primary.

Rules MX records must follow

• The target must be a host name, not an IP address. MX 10 203.0.113.25 is invalid. Create an A record such as mail.example.com and point the MX at that.
• The target should not be a CNAME. The standards say an MX target must have its own address records. Some mail servers tolerate aliases; others do not.
• MX records live on the domain that receives mail. For addresses @example.com, the MX goes on example.com (host @), not on mail.example.com or www.
• Remove stale records. A leftover MX for an old provider means some mail may be delivered to a system you no longer read.

If a domain has no MX record at all, senders fall back to its A record and try to deliver there, which is usually your web server. For a domain that should never receive mail, RFC 7505 defines a "null MX" that says so explicitly:

example.net.   IN   MX   0 .

How to check MX records

Use our DNS lookup tool with the MX type selected, or from a terminal:

dig example.com MX +short
nslookup -type=MX example.com
Resolve-DnsName example.com -Type MX

Confirm that the targets belong to your current email provider, that the priorities match the provider's instructions, and that there are no leftover entries. You can also check that the mail servers are reachable on port 25 with the port checker, which is useful when you run your own mail server.

MX records for common providers

Every provider documents its own values, and they occasionally change, so always copy them from the provider's admin console or documentation. As general patterns:

Changing MX records without losing mail

1. Prepare the new provider first. Create mailboxes and verify the domain with the new provider before touching MX.
2. Lower the MX TTL to 300 seconds a day ahead, so the switch takes effect quickly.
3. Replace the MX records with the new provider's, removing the old ones completely.
4. Keep the old mailboxes active for a few days. Senders whose resolvers cached the old records will still deliver there, and you will want to collect that mail.
5. Update SPF, DKIM and DMARC to reflect the new provider. MX only controls inbound mail; outbound authentication is separate.
6. Verify from several locations with the DNS propagation checker, then send test messages from external accounts.

Troubleshooting inbound mail

• Bounces saying "no MX" or "domain not found": the record is missing, or the domain has expired.
• Some senders reach you and others do not: a recent change is still propagating, or an old MX remains alongside the new ones.
• Mail delayed by hours: the primary MX is refusing connections and senders are retrying or falling back.

Key takeaways

• MX records tell other servers where to deliver mail for your domain; the lowest priority number is tried first.
• MX targets must be host names with their own A/AAAA records, never IP addresses.
• Use a null MX on domains that should never receive mail.
• When switching providers, lower the TTL first, remove old records and keep old mailboxes running for a few days.