MX records done right

Syntax: priority and hostname

An MX record has two parts: a priority (preference) as a number and the hostname of the mail server that accepts mail for the domain. The priority is an integer between 0 and 65535; lower values are preferred. The hostname must be a name that resolves to an A or AAAA record.

Two things are forbidden by RFC and still sometimes work, until they do not: an MX must not point directly to an IP address, and it must not point to a CNAME. Many mail servers resolve the CNAME anyway, others reject it or behave unpredictably. The MX checker flags both as errors.

example.com.    3600  IN  MX  10 mail.example.com.
example.com.    3600  IN  MX  20 mail2.example.com.
mail.example.com.   3600  IN  A   203.0.113.25
mail2.example.com.  3600  IN  A   203.0.113.26

How priority and failover work

A sending mail server fetches all MX records, sorts them by priority and tries the host with the lowest value first. If it does not respond, the next one is tried. Only when all hosts are unreachable is the message queued and retried later, usually over several days, before the sender receives a bounce.

Several MX records with the same priority are chosen at random, which gives simple load distribution. Important: a backup MX with a higher number is only used when the primary is unreachable, not when it rejects. If the primary server rejects a message with an error, nobody falls back to the backup. And a backup MX that accepts mail without knowing which mailboxes exist is a popular entry point for spam.

Typical setups: Google Workspace and Microsoft 365

Since 2023 Google Workspace uses a single MX record for new domains: smtp.google.com with priority 1. The older configuration with five entries (aspmx.l.google.com and alt1 through alt4) continues to work; you do not have to migrate existing clients. Mixing both is unnecessary but harmless, because all hosts belong to Google.

Microsoft 365 uses one hostname per domain following the pattern domain-tld.mail.protection.outlook.com, so for example.com it is example-com.mail.protection.outlook.com. The admin center shows the exact name, because it can differ in special cases. A single MX, priority 0 or 10, both are common.

# Google Workspace (new)
example.com.  IN  MX  1  smtp.google.com.

# Microsoft 365
example.com.  IN  MX  0  example-com.mail.protection.outlook.com.

Null MX: domains that never receive mail

Not every domain should receive mail. A pure marketing domain, a typo domain or a subdomain like cdn.example.com does not need a mail server. Without an MX record, senders still try to deliver to the domain's A record and then wait for days for a server that never answers.

RFC 7505 defines the Null MX for this: a single MX record with priority 0 and a dot as the hostname. Senders recognise immediately that the domain accepts no mail and generate a clean bounce instead of waiting. Combine it with "v=spf1 -all" and a DMARC policy with p=reject, and the domain cannot be abused for spam either.

marketing-example.com.  IN  MX   0 .
marketing-example.com.  IN  TXT  "v=spf1 -all"

The most common errors

MX errors are insidious because mail does not disappear immediately. Senders keep trying for days, and the client only notices after a week that enquiries are missing.

• MX points to a host without an A or AAAA record, for example after a server migration where mail.example.com was deleted.
• Two providers mixed: one MX points to Microsoft 365, a second one still to the old host. Depending on priority and availability, mail lands sometimes here, sometimes there.
• The trailing dot: in zone files the final dot makes the name absolute. Without it, some DNS servers append the zone and mail.example.com becomes mail.example.com.example.com. In web panels it is usually the other way round; the dot is added automatically.
• Old host's MX forgotten: the old server keeps accepting mail and files it into a mailbox nobody reads anymore. This is the classic silent loss.
• MX pointing to a CNAME or directly to an IP address.
• MX pointing to a host whose certificate or hostname does not match MTA-STS, so strict senders refuse delivery.

What an MX change means

An MX record changes rarely, and when it does, for one of three reasons. First, a planned switch of mail provider that the agency knows about. Second, a mistake, such as a client who "cleaned up" an entry in the hosting panel, or a provider that re-imported a zone. Third, a takeover: whoever controls the DNS zone or the registrar account can redirect all of a company's mail with a changed MX, including password resets for every other service.

For an agency with many client domains this means: every MX change you did not plan yourself is an incident. The client often only notices when mail from suppliers or applicants is missing. Monitoring that compares MX records regularly with the last known state shortens that time from weeks to minutes.

Frequently asked questions

Do I need a backup MX?

Not with Google Workspace or Microsoft 365; the redundancy sits behind the single hostname. With your own mail server, a backup MX only helps if it knows the valid recipients and forwards mail reliably. Otherwise it creates more problems than it solves, because senders wait several days anyway before giving up.

What do different priority values like 0, 1 and 10 mean?

Only the order matters, not the absolute value. A single MX with 0, 1 or 10 behaves identically. Gaps like 10, 20, 30 leave room to insert a server later.

How long until a changed MX takes effect?

As long as the TTL of the old record. Mail servers do not cache MX longer than other DNS answers. Lower the TTL before a planned switch, and the change takes effect within minutes.