A null MX explicitly declares that a domain does not accept email. It is useful for a domain that intentionally has no mail service, because simply omitting MX can cause senders to try the domain's A or AAAA addresses instead.
IN THIS ARTICLE
Check access and requirements
Confirm that nobody uses the domain for incoming mail, account recovery, automated replies or sender addresses. Review subdomains separately. Preserve the existing MX set and obtain approval from the person responsible for the domain's communication services.
01 Publish a null MX for a domain that intentionally receives no email
- Inventory mailboxes, forwarding, catch-all handling and website-generated mail involving the exact domain. Do not use null MX as a temporary repair for a broken mailbox provider.
- At the authoritative DNS provider, replace the domain's MX set with one null MX record: preference 0 and exchange target
.. Follow the editor's supported null-MX format. - Remove other MX records at that same owner name. A null MX must not coexist with ordinary MX entries that suggest mail is also accepted.
- Keep website A/AAAA records when the domain still hosts a website. Null MX affects mail routing, not ordinary web resolution.
- For a domain that also sends no mail, separately review an appropriate SPF non-sending policy and other anti-spoofing controls. These express different policies from inbound null MX.
02 Example: publish a null MX only for a domain that receives no mail
A null MX explicitly states that a domain does not accept email. Use it only after confirming there are no required receiving mailboxes, aliases or verification workflows on that exact domain. This is the standard BIND-style record shape.
example.com. 3600 IN MX 0 .
dig example.com MX +noall +answerRead the result: The priority is zero and the exchange is a single dot. This is not the same as an empty MX field or an MX pointing at localhost. A null MX must not be combined with ordinary MX records for a mail-receiving service.
Before publishing, check account recovery addresses, contact forms and automated replies that may still expect incoming messages. Keep mail-sending authentication as a separate design decision. After the reviewed change, confirm the authoritative answer and allow existing cached MX data to expire.
Confirm the expected result
Query authoritative MX data and confirm the single 0 . result. Test an external message to a controlled address at the domain and confirm the expected non-delivery behaviour after cached old records expire.
Resolve setup problems
If the DNS interface refuses the dot target, ask the authoritative provider whether it supports null MX. Do not replace it with a fake mail hostname or a documentation IP. Restore real MX records if the no-mail decision was mistaken.
A common question
Can my application continue using this domain in its From or return address?
That can cause recipient systems to reject the message because replies or delivery failures cannot reach the sender domain. Use a properly configured sending domain that can receive the necessary responses, rather than publishing null MX for an active sender identity.