MX record

Someone sends mail to alice@example.com. The sending server asks DNS: where does mail for example.com go? The answer is one or more MX records. The sender connects to the host named by the lowest-preference MX over SMTP and hands off the message.

Type code 15, defined in RFC 1035 §3.3.9. The routing and ordering rules are in RFC 5321 §5.

What it is

Two fields: a preference number and an exchange hostname.

example.com.  3600  IN  MX  10  alt1.smtp.google.com.
|              |    |   |   |   |
|              |    |   |   |   └─ the exchange hostname (must resolve to A/AAAA)
|              |    |   |   └─ preference: lower = tried first
|              |    |   └─ record type
|              |    └─ DNS class
|              └─ TTL
└─ owner name (the domain receiving mail)

The exchange must be a hostname with A or AAAA records. An IP literal is not allowed. A CNAME is not allowed either (more on that in the common mistakes).

Preference

A domain usually publishes multiple MX records. The sender tries the lowest preference value first, falls back to the next if that fails.

Preference and fallbacklowest number wins

sender asks DNS for MX

dig example.com MX

sender tries in preference order

10alt1.smtp.google.comfirst attempttimeout

20alt2.smtp.google.comnext attemptaccepted

30alt3.smtp.google.comnot tried

40alt4.smtp.google.comnot tried

Delivery succeeded at priority 20. The sender never touches 30 or 40. Same-priority records are load-balanced randomly; ordering only matters across different numbers.

Equal preferences are load-balanced at random. Different preferences are a strict fallback order. Think of preference as an ordered list, not a weighted one.

What the host reveals

The MX hostname alone usually tells you which mail provider the domain uses. Google Workspace, Microsoft 365, and the enterprise gateways (Proofpoint, Mimecast) all use recognisable hostname patterns.

MX provider patternswhat the hostname reveals

smtp.google.comGoogle Workspacesingle-MX recommendation since 2023

*.mail.protection.outlook.comMicrosoft 365tenant-specific, e.g. example-com.mail.protection.outlook.com

*.pphosted.comProofpointenterprise gateway

*.mimecast.comMimecastenterprise gateway

inbound-smtp.*.amazonaws.comAmazon SESregional endpoints

mx.zoho.comZoho Mailprimary MX; also mx2.zoho.com

.Null MX (RFC 7505)domain does not accept mail; preference 0 and . target

A domain running its own Postfix or Exim tends to have an MX that looks like mail.example.com. Anything with pphosted.com or mimecast.com in it is routed through a security gateway before it reaches the real inbox. For a Sudory scan, this is often the first signal that there is a vendor in the mail path.

Null MX

Some domains do not accept mail and never will. A brand-protection domain, a CDN-only subdomain, an API-only origin. The correct way to say so in DNS is a Null MX (RFC 7505):

api.example.com.  3600  IN  MX  0  .

Preference 0, target . (root, one character). Sending servers that see this return a 5xx permanent error immediately instead of queueing the message. Without it, mail to postmaster@api.example.com sits in sender queues for days before bouncing.

Implicit MX

If a domain has no MX record, RFC 5321 §5.1 says the sender falls back to the A or AAAA record of the domain. This is called an implicit MX.

It mostly exists for historical compatibility. Relying on it is fragile: your web server and your mail server usually are not the same host, and turning on the web side without thinking often exposes port 25 to the internet on a machine that is not set up to speak SMTP. Always publish an explicit MX. If no mail should arrive, publish a Null MX.

Common mistakes

MX target is a CNAME

Forbidden by RFC 2181 §10.3 and RFC 5321 §5.1. Some senders follow the CNAME, some reject. Unpredictable. Point MX at an A/AAAA host directly.

MX points at an IP literal

Not allowed. Preference is a number, exchange is a hostname. Put the IP behind a real A record.

stale legacy records after migration

Moving from Google to Microsoft or vice versa and leaving the old MX alongside the new one. Mail splits unpredictably across both providers. Remove everything old before flipping.

no MX and no Null MX on apex subdomains

An API subdomain with no MX falls back to the implicit MX (its A record). Bounces pile up in sender queues for days. Publish Null MX on anything that should never receive mail.

all MX at the same preference

Random load-balancing across five hosts is not redundancy. Use different preferences so senders have a clear primary and a clear fallback.

Check what your MX records resolve to, which provider they belong to, and whether apex subdomains publish a Null MX: scan your domain.