MX records: how inbound mail finds your server

MX records: how inbound mail finds your server

By James Bayliss · Updated · Reviewed

In this guide
  1. How a sender uses MX records
  2. No MX, and null MX
  3. CNAME rules
  4. Inbound vs outbound
  5. Changing MX records safely
  6. Common mistakes
  7. Sources

How a sender uses MX records

To deliver to alex@example.com, a sending server:

  1. Queries the MX records for example.com.
  2. Sorts them by preference, lowest first. Hosts with equal preference are tried in random order, which spreads load.
  3. Resolves each host's A/AAAA records and connects on port 25.
  4. If a host is unreachable or answers with a temporary error (4xx), it tries the next one. If all fail, it queues the message and retries, typically for several days, before bouncing.
example.com.  3600  IN  MX  10  mx1.example.com.
example.com.  3600  IN  MX  10  mx2.example.com.
example.com.  3600  IN  MX  20  backup-mx.example.net.

Here mx1 and mx2 share the load, and backup-mx is only used when both are down.

Hosted mail platforms

With Microsoft 365 or Google Workspace you publish exactly the MX records the provider tells you, often a single host such as example-com.mail.protection.outlook.com (Microsoft 365). Extra legacy MX records pointing at an old server are a classic cause of mail going missing after a migration: some senders deliver to the old server, which may still accept the mail.

No MX, and null MX

  • No MX records at all: RFC 5321 §5.1 says senders then treat the domain's own A/AAAA address as an implicit MX. If your website's server doesn't accept mail, senders keep retrying it until the message expires. That's slow and confusing.
  • Null MX (RFC 7505): a single record 0 . explicitly says "this domain accepts no mail". Senders bounce immediately with a clear error. Use it on parked domains and on domains that only send.
parked-example.com.  IN  MX  0  .

CNAME rules

Most "it should work" MX problems break one of these rules:

  • An MX target must not be a CNAME. RFC 2181 §10.3 requires MX targets to have address records directly. Many senders tolerate a CNAME, but not all, and the failures are intermittent and hard to trace.
  • A name with a CNAME can't have any other records (RFC 1034 §3.6.2). So you can't put a CNAME at a name that also has MX, TXT (SPF) or other records, and never at the zone apex (example.com), which always has SOA and NS records. Providers' "ALIAS", "ANAME" or "CNAME flattening" features exist to work around this for websites.
  • An MX target must be a hostname, not an IP address. MX 10 203.0.113.25 is invalid; create mx1.example.com A 203.0.113.25 and point the MX at that.

Inbound vs outbound

MX records control inbound mail only. They have no effect on which servers may send as your domain (that's SPF), and receivers don't use your MX to judge your outbound mail. The mx mechanism in SPF is a convenience that authorises your MX hosts to send. It's only correct when those hosts actually send your outbound mail.

Changing MX records safely

  1. Lower the TTL on the existing MX records (to 300 seconds, for example) at least one old-TTL period before the change. See DNS propagation and TTLs.
  2. Make sure the new platform is ready to accept mail for every address, including aliases and shared mailboxes.
  3. Change the MX records and remove any that point at the old system.
  4. Keep the old system accepting mail, and forwarding or syncing it, for at least the old TTL plus a day. Some senders cached the old records, and some queued messages retry against them.
  5. Raise the TTL again once everything is stable.

Common mistakes

  • Leftover MX records pointing at a decommissioned server.
  • A typo in the MX hostname, which the Email Record Lookup flags as an MX host with no address.
  • Equal preferences on a primary server and a spam-filtering backup that doesn't know your valid users, which leads to backscatter.
  • Forgetting MX records on subdomains used for mail, e.g. a ticketing system's reply address.

From the field: If you are having trouble receiving mail, it is a very simple thing to validate your MX records are still present and valid, particularly if you recently had some DNS or website work done. The most common cause of disappearing records that I have experienced were due to web developers making DNS changes without knowing what the ramifications are or just not caring.

Sources

Check it now

Email Record Lookup Is this domain's email set up correctly: MX, DMARC, DKIM and SPF?

Related guides