MX records name the servers that accept mail for a domain, each with a preference number — lower is tried first. Without them a sender falls back to the domain's A record or gives up. MX governs receiving only: it says nothing about who may send as the domain, which is what SPF, DKIM and DMARC decide.

How to read your result

Preference. The number beside each host. Lower is tried first; equal values are load-balanced between.
Host. The mail exchanger's hostname. This must be a hostname that resolves to an address, never an IP address and never a CNAME.
Addresses. What each host resolves to. A host listed with no address is a broken MX — senders will try it, fail, and fall through to the next.

What the preference number actually does

It is a priority order, not a weighting. A sender tries the lowest number first and only moves on when that host is unreachable. The absolute values are meaningless — 10 and 20 behave exactly like 1 and 2 — so use gaps of ten purely so you can insert a host later without renumbering.

Equal preferences are the only case where distribution happens: senders pick among them at random, which is how you spread inbound load across two equivalent servers.

The five most common failures

No MX records at all

A sender then falls back to the domain's A or AAAA record and tries to deliver there. Sometimes that works by accident; usually it does not, and the mail bounces. If a domain is meant to receive mail, it needs explicit MX records.

An MX pointing at a CNAME

Not allowed. An MX target must be a hostname with an address record, and pointing it at a CNAME is a spec violation that some senders tolerate and others reject. It usually appears when a hosting panel autocompletes the field.

A host that resolves to nothing

Typically a typo, or a hostname that belonged to a provider you have left. Senders will still attempt it in preference order, so a dead high-priority host delays every inbound message while the sender times out and retries the next one.

Leftover records from a previous provider

Migrations tend to add the new records and leave the old ones. If an old host still accepts mail, some of your inbound will silently land in a mailbox nobody reads. This is the failure most worth checking for after a move.

A null MX that was not intended

A single MX of . at preference 0 is the standard way to declare that a domain accepts no mail at all. It is genuinely useful on a domain you only send from, and alarming if you did not mean it.

A worked example

A domain on Google Workspace, with a secondary at a higher preference:

10  aspmx.l.google.com
20  alt1.aspmx.l.google.com
20  alt2.aspmx.l.google.com

Preference 10 is tried first for every message.
The two hosts at 20 are equivalent, and senders choose between them at random when 10 is unreachable.
Every host is a hostname that resolves — the thing to verify after any change.

MX does not authorise sending

This is the most common misunderstanding about MX records. They tell the world where to deliver mail for your domain. They say nothing about which servers may send as it, and a receiver checking your outbound mail does not consult them.

One caveat worth knowing: SPF has an mx mechanism that authorizes whatever your MX hosts resolve to. That is the only place the two ideas touch, and it costs one of your ten DNS lookups.

Related checks

SPF checker — which servers may send as the domain.
DMARC checker — the policy for mail that fails authentication.
DKIM checker — signing keys by selector.
Full domain check — MX, SPF, DKIM and DMARC together.

Check MX records