Null MX Records (RFC 7505): How to Say a Domain Takes No Mail

A null MX record is a single MX record with preference 0 and a bare dot for the mail server: example.com. MX 0 .. Defined in RFC 7505 (June 2015, Standards Track), it declares that a domain accepts no email at all. Senders that honour it fail immediately with a 556 5.1.10 error instead of queueing the message and retrying for days.

It is one of the most useful and least used records in DNS. This guide covers the syntax, why "no MX at all" does not mean "no mail", what a null MX looks like from the sender's side, and the full no-mail setup for domains that should never send or receive.

The syntax

A null MX is one MX record, preference 0, exchange ., and nothing else. RFC 7505 section 3 defines it as "a single MX RR ... with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as '.'". The same section adds: "A domain that advertises a null MX MUST NOT advertise any other MX RR."

In a zone file:

example.com.    3600    IN    MX    0 .

In most DNS provider panels, you create an MX record on the root (@) with priority 0 and a mail server value of .. Some panels reject a lone dot; if yours does, check its documentation or support, because the dot is the record.

Here is what dig returned on 7 October 2026 (UTC) for the IANA example domains, which publish exactly this:

$ dig +short MX example.com
0 .

Why "no MX record" still receives mail attempts

Without any MX record, senders fall back to the domain's A or AAAA record and try to deliver there. RFC 5321, section 5.1, says: "If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host."

So a domain that only hosts a website, with an A record and no MX, has implicitly told the world "send mail to my web server". RFC 7505's introduction describes the result: if there are no SMTP listeners at those addresses, "message delivery will be attempted repeatedly for a long period, typically a week, before the sending Mail Transfer Agent (MTA) gives up." The person who mistyped the address finds out a week later, if at all.

This is common, including among very large organisations. On 7 October 2026 we looked up several well-known domains that are obviously not meant to receive mail:

Domain	MX records	SPF	A record	What a sender does
example.com	0 . (null MX)	v=spf1 -all	Yes	Fails immediately
t.co	None	v=spf1 -all	Yes	Falls back to the A record
goo.gl	None	v=spf1 -all	Yes	Falls back to the A record
amzn.to	None	v=spf1 -all	Yes	Falls back to the A record
gov.uk	None	v=spf1 -all	Yes	Falls back to the A record

All four of the others already declare with SPF that they send no mail. None of them declare that they receive none, so under RFC 5321 a sender should try their web servers. You can run the same check on any domain with the MX lookup tool.

What senders see

RFC 7505 gives a specific reply code for each direction, so the failure is unambiguous.

Situation	Reply code	Enhanced code	Registered text
You send to an address at a null MX domain	556	5.1.10	"Recipient address has null MX"
You send from a null MX domain and the receiver checks	550	5.7.27	"Sender address has null MX"

The 556 code itself comes from the companion RFC 7504, which defines it as "domain does not accept mail". RFC 7505 says a submission or relay server that rejects a recipient for this reason "SHOULD use a 556 reply code ... and a 5.1.10 enhanced status code". In practice the rejection usually comes from your own outgoing server, because it reads the null MX before trying to connect anywhere. That is the point: the error arrives while the sender is still at the keyboard.

One trap with the second code. Google's sender FAQ uses 5.7.27 for a different reason: "This message was blocked because it didn't pass SPF authentication." So a 5.7.27 from Gmail is about SPF, not null MX. Read the text after the code.

Null MX and email verification

For a verifier, a null MX domain is the easiest invalid there is: no SMTP connection is needed. Any address at a domain that publishes MX 0 . cannot receive mail, by the domain's own declaration. The MX layer of verification catches it before the mailbox check runs, as covered in syntax vs MX vs SMTP checks.

RFC 7505 calls out typos as a main use case, with examples like alice@www.example.com and alice@examp1e.com. If a typo domain publishes a null MX, a signup form can reject it on the spot; for typo domains that don't, see catching email typos at signup.

Don't send from a null MX domain

A domain you send from must be able to receive replies and bounces, so it must not publish a null MX. RFC 7505 section 4.2 is direct: "mail systems SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses. If a system nonetheless does so, it risks having its mail rejected."

This catches people in two ways:

• A sending subdomain inherits a wildcard. If you publish *.example.com MX 0 . and later start sending from news.example.com, receivers see that bounces to the subdomain cannot be delivered. Give any sending subdomain its own real MX, or a Return-Path on a domain that has one.
• A "no inbound" domain that sends notifications. If an app sends from noreply@app.example.com, that domain still needs to be able to receive bounces. "No reply" is a mailbox convention, not a DNS one.

RFC 7505 also notes that a null MX does not replace the null reverse-path (MAIL FROM:<>) that bounce messages themselves use.

The full no-mail setup for parked domains

A domain that neither sends nor receives should publish four things: null MX, SPF -all, DMARC p=reject, and no DKIM. This is the configuration in M3AAWG's Protecting Parked Domains Best Common Practices (updated June 2022):

Record	Value	Purpose
MX on @	0 .	Accepts no mail
MX on *	0 .	Covers subdomains
TXT on @	v=spf1 -all	Authorises no sending IPs
TXT on *	v=spf1 -all	Same for subdomains
TXT on _dmarc	v=DMARC1; p=reject	Tells receivers to reject forgeries
DKIM	None	M3AAWG: "There is no need to publish any DKIM record for a parked domain and in fact none should be published."

The logic is that a forged message using the domain cannot pass SPF (no IPs are allowed) or DKIM (no keys exist), so it fails DMARC and the p=reject policy tells receivers to refuse it. M3AAWG notes the rua reporting address in DMARC is optional for a parked domain. The IANA example domains above publish essentially this set, with strict alignment added.

You can build the SPF and DMARC values with the SPF generator and DMARC generator. M3AAWG also suggests using the domain's SOA record for a contact address, since postmaster@ will not work on a domain that accepts no mail.

When to use a null MX

Publish one on every domain you own that should never receive mail. Typical cases:

• Parked and defensively registered domains, including typo variants of your brand.
• Link shorteners and asset or CDN domains that serve web content only.
• Old brand domains you keep for redirects after a rebrand. Check first that no forgotten mailbox still uses them.

Do not publish one on a domain that sends any mail, or on one where you might still have a mailbox. A null MX does not delay mail; it makes every delivery attempt fail straight away.

The short version

1. MX 0 . is the null MX. It must be the only MX record on that name.
2. No MX at all is not the same: senders fall back to the A record and retry for days.
3. Senders get 556 5.1.10 when sending to it. A Gmail 5.7.27 means SPF failure, not null MX.
4. Never publish it on a domain or subdomain you send from.
5. For parked domains, pair it with v=spf1 -all, p=reject and no DKIM, on the root and a wildcard.