Null MX records explained
A null MX is a single DNS record, MX 0 ., that tells the world a domain accepts no email. It is defined in RFC 7505. A sending server that finds it should fail the message at once, with the reply 556 5.1.10, instead of retrying for days. That is different from having no MX record at all: then senders fall back to the domain's own A or AAAA address. Publish a null MX on domains that never receive mail, such as parked domains, and add SPF -all and DMARC p=reject when the domain sends no mail either.
What the record looks like
RFC 7505, section 3, defines the null MX as exactly one MX record with preference 0 and an empty host name, written as a single dot. A dot is not a valid host name, so the record cannot be mistaken for an ordinary MX record. A domain with a null MX must not publish any other MX record.
example.com. MX 0 .To see whether a domain has one, look up its MX records:
dig +short MX example.comA null MX comes back as the single line 0 ..
Null MX versus no MX at all
Without the null MX, a domain with no MX records still looks like a mail destination. Under RFC 5321, section 5.1, a sender that gets an empty list of MX records treats the domain itself as an implicit MX with preference 0 and tries the addresses in its A or AAAA records. RFC 7505, section 1, describes the result for a web-only domain: if nothing listens for SMTP at those addresses, the sender keeps retrying for a long period, typically a week, before it gives up and tells you.
| What the domain publishes | What a sending server does |
|---|---|
| MX records that point to mail hosts | Delivers to those hosts, in order of preference |
A null MX (MX 0 .) | Fails the message at once |
| No MX, but an A or AAAA record | Tries that address as an implicit MX, and retries if nothing answers |
| No MX and no address record | Reports an error: the implicit MX is unusable |
| Nothing: the domain does not exist | Reports an error |
The null MX turns the third row, a slow failure, into the second, a fast one.
The bounce codes
Sending to a domain with a null MX
RFC 7505, section 4.1, says a submission or relay server that rejects a recipient because of the domain's null MX should answer 556 with the enhanced code 5.1.10, registered as "Recipient address has null MX" (section 6). The reply code 556, "domain does not accept mail", was added by RFC 7504 for this case. Because the recipient's domain has no mail server, the bounce comes from your own side: your sending server or your email platform. See 556 5.1.10 for what to do with the address.
556 5.1.10 Recipient address has null MXSending from a domain with a null MX
The same section lets a receiving server refuse mail whose envelope sender or From domain publishes a null MX. It should then reply 550 with 5.7.27, "Sender address has null MX". Section 4.2 explains the reason: a message without a working return address cannot receive bounces, and an invalid return address often signals spam. It therefore says mail systems should not publish a null MX on domains they use in sender addresses.
Gmail also uses 550 5.7.27, with a different meaning: a bulk sender's message failed SPF. Read the text after the code; the 550 5.7.27 page covers both meanings.
When to publish one
M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group, describes the domains that need one in its Protecting Parked Domains Best Common Practices (updated June 2022):
- Parked and defensive domains, registered so that nobody else can abuse the name, with no plan to use them for mail.
- Web-only domains and subdomains. A domain with an A or AAAA record passes a simple "does this domain exist" test, yet no mail can ever be delivered to it. The UK National Cyber Security Centre makes the same point in Protecting parked domains: without a null MX, a sender may try to deliver to the web server behind the A record, which might not even be yours to control.
Do not publish one on a domain you send from. That includes a "no-reply" domain in your From address: RFC 7505, section 4.2, warns that such mail risks rejection (550 5.7.27, section 4.1). Keep a working MX there, even if nobody reads the replies.
To cover subdomains, M3AAWG uses a wildcard record, *.example.com. MX 0 .. In its example, a subdomain that has its own records, such as an A record, also gets its own null MX.
The full record set for a domain without email
A null MX only stops mail coming in. It does nothing about someone forging your domain on mail going out. For a domain that neither sends nor receives, M3AAWG's example combines it with SPF and DMARC:
example.com. TXT "v=spf1 -all"
example.com. MX 0 .
*.example.com. TXT "v=spf1 -all"
*.example.com. MX 0 .
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:rua@example.net"
example.com._report._dmarc.example.net. TXT "v=DMARC1"- SPF
-allauthorizes no server to send for the domain. In RFC 7208, section 5.1,allis the mechanism that always matches, so a record with nothing before-allfails every sender. RFC 7505, section 4.2, suggests the same record for domains that send no mail. The SPF generator can build it. - No DKIM key. M3AAWG advises publishing none: a forged signature then fails, because there is no public key to verify it. The NCSC post and the UK government's Protect domains that do not send email suggest an empty wildcard key (
*._domainkeywithv=DKIM1; p=) as well; the NCSC calls it not strictly required. - DMARC
p=reject. With no SPF pass and no DKIM key, mail using the domain cannot pass DMARC, so M3AAWG recommends the reject policy straight away. Under RFC 9989, section 4.7,rejectmeans the domain owner considers every failure a clear sign that the use of the domain is not valid. There is no legitimate mail to protect, so the gradual path in DMARC from none to reject is not needed. The DMARC generator writes the record. - Reports to another domain. The
ruaaddress is optional for a parked domain. If you use it, it must be at a domain that receives mail, since this one does not, and that domain must publish the_report._dmarcauthorization record shown above (M3AAWG). DMARC aggregate reports explains what the reports contain. - A contact in the SOA record. Addresses such as
postmaster@cannot work at a null MX domain, so M3AAWG suggests publishing a contact mailbox in the domain's SOA record instead.
The UK government guidance notes that some DNS providers cannot create a null MX. In that case, publish the other records anyway.
Domains that do only one of the two
- Receives mail but never sends it: keep its MX records and still publish SPF
-alland DMARCp=reject. M3AAWG recommends both for any domain that never sends email. - Sends mail but never receives it: do not publish a null MX (RFC 7505, section 4.2). Receivers may check both the envelope sender and the From domain (section 4.1), so give the domain an MX that accepts at least bounces and replies.
How our results report it
Our invalid status has reasons for domains that cannot take mail, such as these two:
no_inbound_mail: the domain turns away incoming messages.no_dns: the domain has no DNS records that tell senders where to deliver mail.
Both carry the action remove. Whatever reason a result shows, a null MX means no address at the domain can receive a message, so sending would only produce bounces.
Many of these addresses are typos. RFC 7505, section 4.1, gives mistakes such as a www. prefix, the wrong top-level domain or a digit in place of a letter as the cases a null MX is meant to catch early. At a sign-up form, ask the person to check the address; email typos covers the common patterns.
Questions
Does a null MX stop others from spoofing my domain?
No. It only affects mail sent to the domain. Spoofing is handled by SPF -all and DMARC p=reject, which is why M3AAWG recommends all three together for a parked domain.
Can I keep a backup MX next to the null MX?
No. RFC 7505, section 3, forbids any other MX record on a domain that publishes a null MX. If the domain should receive mail, remove the null MX and publish real MX records.
Why did my own server send the 556 bounce?
The recipient's domain has no mail server to answer. Your server or email platform read the null MX before connecting anywhere and rejected the address itself, as RFC 7505, section 4.1, describes.
Try it
Check an address in the free email checker to see how its domain is reported, or build the SPF and DMARC records for a parked domain with the SPF generator and the DMARC generator.
Related
- Reason no_inbound_mail: domain does not receive mail.
- Reason no_dns: domain has no mail records.
- Bounce code 556 5.1.10 and 550 5.7.27.
- Glossary: MX record.
Related guides
- Moving DMARC from p=none to p=reject
- Verify an email address without sending a message
- Email typos and did you mean suggestions
- Bounce processing and DSNs explained
- How to read DMARC aggregate reports
- All guides
Sources
- RFC Editor: RFC 7505, A "Null MX" No Service Resource Record for Domains That Accept No Mail: the record (section 3), the 556 5.1.10 and 550 5.7.27 replies (section 4.1), sending domains and SPF (section 4.2), the registered codes (section 6).
- RFC Editor: RFC 7504, SMTP 521 and 556 Reply Codes: the 556 reply code.
- RFC Editor: RFC 5321, Simple Mail Transfer Protocol: the implicit MX rule (section 5.1).
- RFC Editor: RFC 7208, Sender Policy Framework: the
allmechanism (section 5.1). - RFC Editor: RFC 9989, DMARC: the meaning of
p=reject(section 4.7). - M3AAWG: Protecting Parked Domains Best Common Practices (June 2022): which domains need it, the record set, DKIM, reporting addresses, SOA contact.
- NCSC: Protecting parked domains for the UK public sector: null MX for domains with an A record, the optional empty DKIM record.
- GOV.UK: Protect domains that do not send email: the UK government record set and DNS providers without null MX support.
How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.