KoltrixMX records explained: priorities, fallbacks and null MX
How sending servers pick among MX records, what preference values really do, what happens without an MX, and when to publish a null MX instead.
On this page(10 sections)
- What an MX record says
- How senders choose among MX hosts
- Equal preferences for load balancing
- Different preferences for fallback
- A word on backup MX hosts
- What happens with no MX record
- Null MX: saying "no mail here"
- MX records and subdomains
- Changing MX records safely
- Verifying your MX setup
- Checklist
- Key takeaways
MX records are the oldest piece of email DNS, and the one people touch least often. That is exactly why a migration or a typo in them causes so much confusion.
Here is how sending servers actually use MX records, what the numbers mean, and what happens when there are none.
What an MX record says
An MX (mail exchanger) record tells the world which hosts accept email for a domain. Each record has two parts, a preference number and a hostname:
example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.The target must be a hostname with A or AAAA records, not an IP address and, per the DNS and SMTP specifications, not an alias defined by a CNAME. Some software tolerates a CNAME target, but you should not rely on that.
How senders choose among MX hosts
SMTP's rules for this are in RFC 5321. A sending server:
- Looks up the MX records for the recipient's domain.
- Sorts them by preference, lowest number first.
- Tries the most preferred host. If several share the lowest preference, it picks among them randomly, which spreads load.
- If that host cannot be reached or returns a temporary failure, it moves on to the next host in order.
- If all hosts fail temporarily, it queues the message and retries later.
The preference values themselves are only relative. 10 and 20 behave exactly like 1 and 2, or 5 and 500. Gaps are left by convention so you can insert a host later without renumbering.
Equal preferences for load balancing
example.com. MX 10 mx-a.example.com.
example.com. MX 10 mx-b.example.com.Senders distribute connections between the two. Mailbox providers often publish several equal-preference MX hosts for this reason.
Different preferences for fallback
example.com. MX 10 mx1.example.com.
example.com. MX 50 backup-mx.example.net.The backup receives mail only when the primary is unreachable.
A word on backup MX hosts
Traditional backup MX servers accepted mail when the primary was down and forwarded it later. Today they often cause more trouble than they solve:
- Spam targets them because backup hosts frequently have weaker filtering and accept mail for addresses that do not exist, generating backscatter later.
- Sending servers already queue mail for days when your primary is unreachable. A backup MX is not needed to avoid losing mail during a short outage.
- Hosted mailbox providers handle redundancy with multiple equal-preference MX hosts of their own.
If you use a hosted mailbox provider, publish exactly the MX records it specifies and nothing else. Adding your own backup MX usually bypasses the provider's filtering.
What happens with no MX record
If a domain has no MX records at all, RFC 5321 tells senders to fall back to the domain's A or AAAA record, treating the domain itself as an implicit MX with preference 0. This is a historical behavior with a surprising consequence: if your domain's A record points at a web server, senders will try to deliver mail to that web server.
If the web server does not run SMTP, connections fail, and senders keep retrying for days before bouncing. Recipients of the bounce wait a long time to learn their mail failed.
Null MX: saying "no mail here"
RFC 7505 defines a clean way to declare that a domain accepts no email:
example.org. MX 0 .A preference of 0 and a target of a single dot, the DNS root, means "this domain does not accept mail." Senders that honor null MX fail immediately with a clear permanent error instead of retrying. It is the right record for:
- Domains that host only a website.
- Parked or defensively registered domains.
- Subdomains used for APIs or services that should never receive mail.
A null MX must be the only MX record for the name. Combine it with v=spf1 -all and a DMARC p=reject policy if the domain also never sends mail.
MX records and subdomains
MX records apply to the exact name where they are published. example.com having MX records says nothing about support.example.com. If you want mail delivered to addresses at a subdomain, publish MX records on that subdomain. If you are using a subdomain as a custom bounce domain for a sending provider, the provider usually asks you to publish an MX record there so bounces return to them.
Changing MX records safely
MX changes are how mail migrations happen, and timing matters because records are cached for their TTL.
- Lower the TTL on the existing MX records well in advance, to something like 300 seconds, and wait for the old TTL to expire.
- Prepare the new provider to accept mail for your domain before switching, including all mailboxes and aliases.
- Switch the records in one change.
- Keep the old provider accepting mail for a while, since some senders cache aggressively or retry queued mail to old hosts.
- Raise the TTL again once traffic has moved.
- Update MTA-STS if you publish a policy: list the new MX hosts before the switch, or drop to testing mode during the cutover.
Verifying your MX setup
dig +short MX example.com
# 10 mx1.example.com.
# 20 mx2.example.com.
dig +short A mx1.example.com
dig +short AAAA mx1.example.comEach MX target should resolve to at least one address. Then check that each host answers on port 25 and offers STARTTLS:
openssl s_client -starttls smtp -connect mx1.example.com:25 -crlf -quiet </dev/null 2>&1 | head -5Many networks block outbound port 25, so run that from a server rather than a laptop.
Checklist
- MX targets are hostnames with A or AAAA records, never IP addresses or CNAMEs.
- Lowest preference is tried first; equal preferences share load.
- Use only the MX records your mailbox provider specifies.
- Publish a null MX on domains and subdomains that receive no mail.
- Lower TTLs before migrations and update MTA-STS policies alongside MX changes.
Key takeaways
- Senders try MX hosts in order of preference, lowest number first, and pick randomly among equals.
- With no MX record, senders fall back to the domain's address records, which can send mail at a web server.
- A null MX (
MX 0 .) cleanly declares that a domain accepts no email. - MX records are per name; subdomains need their own.
- Treat MX changes as migrations: lower TTLs, overlap providers and update related policies.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
