Every domain owner eventually faces the same question: what should happen to mail sent to an address that does not exist? Most people assume the answer is “it bounces,” and that assumption is half right. The bounce only happens if the DNS and the mail server agree on who is supposed to answer. A null MX record is the formal way to tell the internet, at the DNS layer, that a domain has no mail service at all, and it is the cleanest tool available for stopping catch-all mailboxes from swallowing traffic nobody wants.
What MX records actually do, and what a null MX changes
MX records route inbound mail to a mail server. That is their only job. When a sending server has a message for user@example.com, it queries DNS for the MX records on example.com, sorts them by preference number, and opens an SMTP connection to the highest-priority host. If no MX record exists, the sending server falls back to the domain’s A or AAAA record, which is why a domain with a web server but no mail configuration can still receive accidental connection attempts on port 25.
A null MX is a single record with preference 0 and a target of a root dot: 0 . (the dot stands for the DNS root, meaning “no host”). RFC 7505 defines it, and it is the standards-correct way to declare that a domain receives no mail. A compliant sender that reads a null MX must not attempt delivery. It should reject the message immediately with a permanent 5xx error, typically a 550, and never touch an SMTP server. That is the whole point: the conversation ends at DNS, before a single byte of SMTP traffic is exchanged.
This matters because a null MX short-circuits catch-all setups at the DNS layer. A catch-all email accepts every message sent to a domain, including addresses that were never created, and that behavior is configured on the mail server, not in DNS. If a domain has both a catch-all rule in Postfix or Exim and a null MX record, the null MX wins for any sender that respects RFC 7505, because the sender never reaches the server to trigger the catch-all. The misconfigured relay that used to accept invented addresses and quietly queue them now gets a definitive answer from DNS.
Why a null MX beats a broken catch-all, and where it does not apply
Null MX versus catch-all, alias, and forwarding
People conflate these constantly. A catch-all differs from an alias, forwarding, and disposable addresses. An alias maps one known address to another known address. Forwarding relays mail from a real mailbox to a real destination. A disposable address is a real, short-lived mailbox. A catch-all is a fallback rule on the mail server that says “if no local mailbox matches this recipient, deliver it here anyway.” Without that rule, a standard mail server replies with 550 no such user when no mailbox matches, which is exactly the behavior a null MX is trying to guarantee.
The myth is that a null MX is the same as deleting your MX records. It is not. Deleting MX records triggers the A-record fallback and leaves senders guessing; some will try the web host, some will retry for days, and you get a mess of deferred bounces instead of one clean rejection. A null MX is explicit. set up a catch-all address in Cloudflare offers additional context worth reviewing. It says the domain is reachable for HTTP and everything else, but mail is not accepted, full stop. That is a cleaner 550 than any misconfigured relay can produce, because the rejection happens at the resolver, not after a server has already accepted the connection and started a transaction.
Catch-all domains are genuinely useful for unlimited unpredictable addresses in automation and sign-ups, where you want a unique address per service without pre-creating mailboxes. But catch-all carries the risk of accepting spam to invented addresses, and it also poisons email verification. Verification tools that probe a domain and get a 250 back from a catch-all cannot tell a real mailbox from a fabricated one, so every address on that domain reads as “risky” or “unknown.” A domain that should receive no mail at all should say so in DNS, not rely on a server-side rule that may be missing or misconfigured.
Getting the DNS and the server to agree
A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients. A working null MX requires the opposite discipline: DNS declaring no mail, and the server not contradicting it. If you publish 0 . but your Postfix or Exim instance still has a catch-all alias or wildcard mailbox, you have created a contradiction that only some senders will honor. The null MX is the authoritative statement, so remove the catch-all rule at the same time. Check every MX record on the zone; a null MX must be the only MX record, or it is invalid and should be ignored by receivers.
For domains that do receive mail, the reverse applies. Point MX records at the real host, set up SPF, DKIM, and DMARC, and remember those three govern outbound mail only. They have no bearing on whether inbound mail reaches a catch-all. If you use Cloudflare for DNS, its email routing feature can forward mail, but that is a separate path from MX records and does not create a catch-all on your own server. In cPanel, catch-all configuration lives in the mail delivery settings, and it is worth auditing because a forgotten catch-all on a domain you thought was quiet is a common source of spam. AllMail.one publishes a guide to catch-all email that walks through the trade-offs, and it is a reasonable reference when you are deciding which side of this line a domain belongs on.
The practical test for any domain is simple. Run a DNS lookup for MX and confirm exactly one record, preference 0, target a single dot. Then send a test message from an external account and confirm the bounce arrives as a 550 from the sending server, not from your own. If it comes back as a delivery failure from your mail server, the null MX is not being honored and something downstream is still accepting unknown recipients. Fix the server or fix the DNS so both tell the same story, and the domain stops generating ambiguous traffic that verifiers and spam filters have to guess about.