Null MX: declaring that a domain accepts no email

A null MX is a single DNS record that says “this domain does not accept email”. It is defined in RFC 7505 from 2015, and it is the right choice for parked domains, domains that only host a website, and host names such as www that should never receive mail.

What it looks like

example.com.  3600  IN  MX  0  .

A null MX is an MX record with preference 0 and an exchange (target) of . — a zero-length name, the root of the DNS. RFC 7505 (section 3) defines it as the domain’s only MX record. Because . is not a valid host name, it can’t be mistaken for a real mail server.

Why not simply publish no MX record?

Because “no MX” doesn’t mean “no mail”. When a domain has no MX records, RFC 5321, section 5.1 tells senders to treat the domain itself as an implicit MX and deliver to its A or AAAA address — usually a web server.

What happens next wastes everyone’s time:

• If nothing listens on port 25 at that address, the sending server can’t connect and keeps retrying. RFC 7505 notes that this typically goes on for about a week before the sender gives up and tells the person who wrote the message.
• If the web server does run an SMTP service, as some hosting setups do, it may accept mail nobody reads.

With a null MX, the sending server learns on the first attempt that the domain takes no mail and fails the message immediately. Someone who mistyped an address — RFC 7505’s example is alice@www.example.com instead of alice@example.com — gets a bounce within seconds, not days later.

A domain that doesn’t exist at all already fails fast: RFC 5321 requires a non-existent domain to be reported as an error. The problem is specifically names that do exist, typically because they have A or AAAA records for a website.

How mail servers handle it

RFC 7505 assigns two status codes:

Situation	Reply code	Enhanced status code	Meaning
The recipient’s domain has a null MX	556	5.1.10	Recipient address has null MX
The sender’s domain (envelope MAIL FROM or From header) has a null MX	550	5.7.27	Sender address has null MX

The first is what a person sees in the bounce after writing to such a domain. The 556 reply code itself comes from RFC 7504 and means “domain does not accept mail”.

The second matters for spoofing. A receiving server may reject mail claiming to come from a domain with a null MX, because no bounce or reply could ever be returned to it. RFC 7505 recommends the code to use; whether to reject is the receiver’s decision.

Servers that don’t implement RFC 7505 can’t find an address for . either. RFC 5321 says that when MX records exist but none of them is usable, the situation must be reported as an error — so the mail still isn’t delivered. The difference is how quickly and how clearly the sender is told.

Don’t publish a null MX on a domain that sends mail

RFC 7505 (section 4.2) says mail systems should not publish a null MX for domains they use in the envelope sender (MAIL FROM) or the From header. Many receivers reject mail whose return address can’t receive bounces, and they may use the 5.7.27 code above to do it.

That rules out a null MX for:

• a “no-reply” domain your application sends notifications from;
• the bounce or return-path subdomain your email service uses, such as bounce.example.com — bounces have to reach it;
• any subdomain you send newsletters or transactional mail from.

If a domain sends mail but shouldn’t get replies, keep a working MX and discard or auto-answer incoming messages on the server.

The full set for a domain that neither sends nor receives

A null MX only covers incoming mail. To stop people from sending in the domain’s name, add SPF and DMARC. RFC 7505 itself points to an SPF -all record for domains that send no mail.

parked.example.          3600  IN  MX   0 .
parked.example.          3600  IN  TXT  "v=spf1 -all"
_dmarc.parked.example.   3600  IN  TXT  "v=DMARC1; p=reject;"

• v=spf1 -all — no server is authorized to send for the domain (see What is SPF).
• p=reject — receivers that apply DMARC should reject mail with this domain in the From header. Under RFC 9989 the policy also covers subdomains unless sp or np say otherwise. Add rua= if you want reports showing who tries to use the domain.
• No DKIM keys. Without a published key, no signature for the domain can verify.

Domains that don’t send email covers this setup, and parked domains in general, in more detail.

Subdomains need their own null MX

MX records aren’t inherited. www.example.com with an A record for your website has an implicit MX like any other name with an address — even if example.com itself has proper MX records. If you want mail to such names to fail immediately, give them their own null MX:

www.example.com.  3600  IN  A   203.0.113.10
www.example.com.  3600  IN  MX  0 .

Two details:

• A wildcard doesn’t help here. *.example.com. MX 0 . only applies to names that don’t exist in the zone, and www does exist.
• A CNAME can’t have other records next to it. If www is an alias, you can’t add an MX record at www. Mail lookups then follow the alias (RFC 5321, section 5.1), and the result depends on the records of the target name.

Common mistakes

A null MX next to other MX records. RFC 7505 says a domain that advertises a null MX must not advertise any other MX record. The combination usually appears after a migration, or when a DNS panel adds default records. The RFC doesn’t define what senders should do with it, so results vary. Decide whether the domain receives mail, and keep either the real MX records or the null MX — not both.

A preference other than 0. MX 10 . is not a null MX in the form RFC 7505 defines, and software that checks for exactly that form won’t recognize it. Use 0.

Replacing the dot with something else. If your DNS panel won’t accept a bare . as the target, don’t enter the domain name or @ instead: @ stands for the zone itself, so MX 0 @ sends mail to the domain’s own address — in effect the implicit MX you wanted to avoid. Ask your DNS host how to enter a null MX.

Old workarounds. Before RFC 7505, administrators pointed MX records at localhost or at a host name that doesn’t exist. Such records give senders no clear answer and lead to delays and confusing errors instead of an immediate, explicit failure. Replace them with a null MX.

Relying on the null MX alone. It says nothing about sending. Without SPF and DMARC, forged mail “from” the domain can still be delivered — rejecting it because of the null MX is optional for receivers.

Check your records

The MX lookup recognizes a null MX and warns when it is combined with other MX records or published with a preference other than 0. From a terminal:

$ dig +short MX parked.example
0 .

On Windows:

Resolve-DnsName parked.example -Type MX

Then run the SPF checker and the DMARC checker on the same domain to confirm that the sending side is closed as well.