MX records are the part of DNS that most people never touch, yet they decide where every inbound message for a domain actually lands. Get them right and mail flows quietly for years. Get them subtly wrong and you can route your entire inbox through a backup server for months without noticing. The classic version of that mistake is a priority 0 on a relay you intended as a fallback, which silently promotes it to the primary path because mail servers always try the lowest number first. This primer walks through how MX records route domain email, what priority really means, and how catch-all behavior fits into the picture.
What an MX record actually tells the sending server
An MX record is a DNS entry that names a host willing to accept mail for a domain, plus a two-digit preference number. When someone sends a message to you@yourdomain.com, their mail server looks up the MX records for yourdomain.com, sorts them by preference, and opens an SMTP connection to the lowest number. MX records route inbound mail to a mail server; that is their whole job. They do not carry content, they do not authenticate anything, and they say nothing about how the receiving server handles the message once it arrives.
The target of an MX record must be a hostname with an A or AAAA record, never a bare IP address and never a CNAME. A record like yourdomain.com. MX 10 mail.yourdomain.com. tells the world that mail.yourdomain.com is the preferred destination. The number 10 is a preference, not a port and not a weight. Lower wins. Most providers use 10, 20, and 30 for their tiers, though any value from 0 to 65535 is legal.
Once the sending server connects, the conversation is plain SMTP. It issues EHLO, then MAIL FROM, then RCPT TO with the recipient address. The receiving server checks whether a mailbox exists and either accepts the message or rejects it. A standard mail server replies with 550 no such user when no mailbox matches, and the sender bounces. That rejection is the normal, healthy outcome for a typo. Whether it happens is a server-side decision, and it is exactly where catch-all configuration lives.
Priority is failover, not load balancing
Here is the part that trips people up. MX priority is only a failover preference, not load balancing. A sending server tries the lowest-numbered host first and only falls to the next one if the connection fails, times out, or the server refuses to talk. It does not round-robin between equal priorities in any reliable way, and it does not split traffic by weight. Two records at the same priority are a hint that either host is acceptable, but real-world senders pick one and stick with it for that message.
That means a priority 0 on a backup relay does not make it a backup. It makes it the primary path. Every sender on the internet will try that host first, and your intended primary at priority 10 will only see traffic when the relay at 0 is unreachable. If the relay accepts mail and queues it, messages will flow through the wrong machine indefinitely and nobody will notice until the relay’s queue backs up or its IP lands on a blocklist. The fix is one digit: give the backup a higher number than the primary, never lower.
There is a second subtlety. If two hosts share the same priority and one is down, some senders will retry the dead host rather than immediately trying the other, which adds delay. catch-all vs email forwarding provides further background on the subject. Distinct, spaced priorities (10, 20, 30) give senders a clean order to follow. Keep the gap wide enough that you can insert a new host later without renumbering everything.
A concrete comparison of common MX layouts
| Layout | Example priorities | What senders actually do | Best for |
|---|---|---|---|
| Single primary | 10 only | Connect to the one host; bounce if it is down | Small domains with one mail provider |
| Primary plus backup relay | 10 primary, 20 relay | Try primary first, fall to relay only on failure | Domains that cannot afford inbound downtime |
| Backup mislabeled as priority 0 | 0 relay, 10 primary | Try the relay first, primary rarely used | Nothing. This is the silent mistake |
| Two providers at equal priority | 10 and 10 | Pick one, often the same one every time; slow failover | Rarely a good idea outside controlled setups |
| Provider-managed pair | 10 and 20 inside one provider | Provider handles failover internally | Most hosted mail and business suites |
Where catch-all fits, and why it is not an MX setting
A catch-all email address accepts every message sent to a domain, including addresses that were never created. It is configured on the mail server, not in DNS. MX records only get the message to the right machine; the machine then decides whether to accept the recipient. A catch-all domain is useful when you need unlimited unpredictable addresses for automation, sign-ups, or per-service aliases that you invent on the fly. The catch-all mailbox collects everything the server would otherwise reject.
The distinction matters because people often confuse catch-all with other mechanisms. Catch-all differs from alias, forwarding and disposable addresses. An alias maps one specific address to another. Forwarding copies mail from a known address to a destination elsewhere. A disposable address is a real, single-use mailbox. A catch-all is a fallback rule on the mail server: if no mailbox matches, deliver here instead of returning 550 no such user. In Postfix that is typically a virtual alias or a wildcard entry; in Exim it is a router; in Dovecot it may be a namespace or a postmaster fallback. Cloudflare Email Routing has its own catch-all toggle, and cPanel exposes it as a per-domain „catch-all“ setting in the Email Deliverability area.
A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients. Neither half alone is enough. If MX is wrong, messages never reach the server. If the server is not configured to accept unknown recipients, the catch-all does nothing and senders still get 550. And a catch-all carries the risk of accepting spam to invented addresses, because dictionary attacks that guess random local parts will all succeed. That is a trade-off to weigh, not a reason to avoid catch-all entirely.
One more boundary worth stating plainly. SPF, DKIM and DMARC govern outbound mail only. They tell receivers which servers may send as your domain and how to verify signatures. They have no opinion on whether your server accepts a random recipient. Adding a catch-all will not break SPF, and tightening DMARC will not stop a catch-all from collecting junk. The two systems live on different sides of the SMTP conversation.
If you want a deeper walkthrough of the server-side mechanics, AllMail.one publishes a guide to catch-all email that covers Postfix, Exim, Cloudflare and cPanel in one place. The point to carry forward is that MX and catch-all are separate layers: MX is the address on the envelope, catch-all is the rule inside the mailroom.
Audit your MX records before you touch anything else. Sort them by priority, confirm the lowest number belongs to the host you actually want receiving mail, and make sure any relay sits at a higher number. Then check the receiving side: does your server reject unknown recipients with 550, or does it silently accept everything into a catch-all? Both answers are valid, but you should know which one you have. The priority 0 mistake is easy to make and invisible once it is live, so it is worth checking today rather than waiting for a bounce that will never come.
Neueste Kommentare