MX record: how email finds its destination

An MX (Mail Exchange) record is the DNS entry that answers the first question every sending server asks: where does this domain's mail go? When mail is addressed to user@example.com, the sender queries example.com's MX records, gets back one or more mail server hostnames with priority values, and connects to them in priority order. No MX records, and most senders fall back to the domain's A record; no working destination at all, and the mail bounces.

Reading and writing MX records

Two protocol rules cause most MX mistakes. The target must be a hostname that resolves to an address record: pointing MX at an IP literal or at a CNAME is invalid, even where some servers tolerate it. And the record only governs inbound routing: MX says nothing about which servers send a domain's mail, which is SPF's job, so the machines in your MX set and the machines in your SPF record are frequently and correctly different.

Operational notes

Run at least two MX hosts on independent infrastructure for resilience, and remember that senders queue and retry, so short outages lose no mail even with a single MX. Every MX host needs a valid TLS certificate matching its hostname once MTA-STS enters the picture, and every MX change must update the MTA-STS policy in the same change window. Backup MX hosts deserve suspicion: a lower-priority server with weaker filtering is a classic spam entry point, and modern practice often prefers two equal, fully filtered hosts over a weak backup.

Domains that receive no mail should still make a statement: a null MX record (priority 0 with a target of just a dot, per RFC 7505) tells senders explicitly that the domain accepts nothing, producing fast clean bounces instead of timeouts, and pairs with v=spf1 -all and p=reject as parked-domain hygiene.