What does the number in an MX record mean?

It is a preference, and lower is tried first. A sender contacts every host at the lowest value before moving to the next, so two records sharing a value share the load between them. The absolute numbers mean nothing on their own — 10 and 20 behave exactly as 1 and 2 do.

Can an MX record point at a CNAME?

No. RFC 5321 requires the target to be a hostname with address records of its own, and an alias there is a configuration error. Some senders follow the alias anyway and delivery appears to work, which makes the problem intermittent across the internet rather than obvious — resolve the alias and publish the real hostname.

What happens if a domain has no MX record at all?

The sender falls back to the domain's own address records and attempts delivery there, which RFC 5321 calls the implicit MX. If those addresses point at a web server, mail is delivered to a host that will refuse it. A domain that should receive no mail should publish a null MX instead of relying on silence.

Do I need a backup MX record?

Usually not. Sending servers already queue and retry for several days, so a backup that only holds mail adds little. A backup that does not validate recipients accepts mail for addresses that do not exist and generates the bounces itself, and backups attract spam because they have historically filtered less than the primary.

MX records: priority, backup MX and common errors

What an MX record publishes

An MX record maps a domain to a hostname that accepts mail for it, together with a preference value. A sending server that has a message for [email protected] queries the MX records of example.com, resolves the hostnames it gets back to addresses, and connects.

The target must be a hostname with address records of its own. RFC 5321 is explicit that it must not be an alias, and it must not be an IP address written in place of a name — both are common enough that they are worth checking first when a domain is not receiving mail.

Two equally preferred hosts and one fallback. Each target is a real hostname with its own address records, not an alias.

example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 10 mx2.example.com.
example.com. 3600 IN MX 20 mx-backup.example.net.

mx1.example.com. 3600 IN A    192.0.2.10
mx1.example.com. 3600 IN AAAA 2001:db8::10

Preference, and what a sender does with it

The number before the hostname is a preference, and lower is preferred. It is not a weight and not a percentage: a sender tries every host at the lowest preference value first, and moves to the next value only when all of them have failed.

Two records sharing a preference value are equivalent, and a sender chooses between them freely — usually at random, sometimes in the order the resolver returned. That is how load is spread across a pair of front-end servers, and the reason to give two servers the same value rather than 10 and 20 if you want both used.

The absolute value of an MX preference carries no meaning of its own. Ten and twenty behave identically to one and two; the convention of leaving gaps exists only so that a host can later be inserted between them.

When a domain has no MX record

A domain with no MX record is not necessarily a domain that cannot receive mail. RFC 5321 defines an implicit MX: if the lookup returns no MX records, the sender falls back to the address records of the domain itself and delivers there, at an effective preference of zero.

That fallback is a long-standing source of confusion. A domain whose A record points at a web server, with no MX published, will have its mail delivered to the web server, where it is usually refused — and the resulting bounce says connection refused rather than anything about a missing record.

Backup MX, and why it is usually a liability

A backup MX is a host at a higher preference value that accepts mail when the primary is unavailable and relays it on later. It was standard practice when outages were long and queues were short, and it is now a poor trade in most deployments.

The difficulty is that a sending server already queues and retries for days without any help from you. A backup that only holds mail adds nothing to that, while taking on two problems: it must know which recipients are valid, or it accepts mail for non-existent addresses and becomes the source of the bounce, and it is a well-known place to aim spam at, because backups historically ran weaker filtering than the primary.

A backup MX is worth running when it enforces the same recipient validation and the same filtering as the primary — which usually means it is a second primary at equal preference, not a backup at all.

Null MX for domains that receive no mail

A domain that accepts no mail should say so rather than stay silent. RFC 7505 defines the null MX: a single record with preference zero and a root target, which states that the domain has no mail service at all.

The benefit is an immediate permanent rejection instead of days of retries, and one fewer domain that can be used as a plausible-looking sender. Pair it with an SPF record of v=spf1 -all and a DMARC policy of reject, and a parked or internal-only domain becomes useless for spoofing at the cost of three DNS records.

The three records that declare a domain sends and receives no mail. The null MX target is a single dot, the DNS root.

example.net. 3600 IN MX 0 .
example.net. 3600 IN TXT "v=spf1 -all"
_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Misconfigurations that break delivery

Each of the following produces a delivery failure that presents as something else, which is why they survive for years in a zone nobody has reason to re-read.

An alias at the MX target. A CNAME where a hostname is required is prohibited by RFC 5321, and senders that follow it do so as a favour, not an obligation.
An MX target with no address record. The lookup succeeds, the resolution fails, and the sender treats it as a temporary problem and retries for days before bouncing.
An IP address in the target field, which is a syntactically valid hostname label and resolves to nothing.
A trailing-dot mistake in the zone file, producing mx1.example.com.example.com and a domain that silently accepts no mail.
An MX record still pointing at a decommissioned host after a platform migration, alongside the new one at the same preference, so half the mail goes nowhere.
Address records published for the MX target but no reverse DNS for the addresses, which does not stop delivery inbound but harms every message the host sends.
A domain that receives no mail and publishes no null MX, so every message to it is queued for days before failing.

How MX relates to sending

MX records govern inbound mail, and a domain can send perfectly well with no MX record at all. They still matter to a sender for two reasons.

The first is bounces and replies. Mail sent from a domain that cannot receive anything is mail whose failure notices go nowhere, which means a bounce processing system that never learns which addresses are dead — and a list that quietly rots into spam trap hits.

The second is that receivers read the MX records of a sending domain as one signal among many. A domain that appears in the header From with no MX and no address record is a domain that cannot be replied to, and several filters score that. Publishing MX records for a sending domain, or a null MX with a working reply address elsewhere, closes the question.

Check this on your own domain. The mx lookup reads the live records and reports what a receiver would see.

Open the mx lookup

Common questions

What does the number in an MX record mean?: It is a preference, and lower is tried first. A sender contacts every host at the lowest value before moving to the next, so two records sharing a value share the load between them. The absolute numbers mean nothing on their own — 10 and 20 behave exactly as 1 and 2 do.
Can an MX record point at a CNAME?: No. RFC 5321 requires the target to be a hostname with address records of its own, and an alias there is a configuration error. Some senders follow the alias anyway and delivery appears to work, which makes the problem intermittent across the internet rather than obvious — resolve the alias and publish the real hostname.
What happens if a domain has no MX record at all?: The sender falls back to the domain's own address records and attempts delivery there, which RFC 5321 calls the implicit MX. If those addresses point at a web server, mail is delivered to a host that will refuse it. A domain that should receive no mail should publish a null MX instead of relying on silence.
Do I need a backup MX record?: Usually not. Sending servers already queue and retry for several days, so a backup that only holds mail adds little. A backup that does not validate recipients accepts mail for addresses that do not exist and generates the bounces itself, and backups attract spam because they have historically filtered less than the primary.

Keep reading

Related checks, definitions and guides.

How MX records route mail, and how they get broken