A domain with no MX record is not necessarily a domain that refuses mail. SMTP can fall back to an address lookup when MX data is absent. Null MX exists to state that a domain does not accept email and avoid that ambiguous fallback.
Publish the explicit no-service answer
References: RFC 7505 §3.
RFC 7505 defines Null MX as a single MX record with preference zero and the root domain as its exchange: example.com. 300 IN MX 0 .. The dot is meaningful. It is not a placeholder for a hostname, and localhost is not equivalent. A domain advertising Null MX must not also advertise another MX record.
Use Null MX only after establishing that no addresses at that exact domain need to receive mail. Include account recovery, procurement, legal notices, role accounts and low-volume operational addresses in the inventory. An apparently inactive domain can still be somebody's recovery address.
Separate receiving from sending controls
References: RFC 7505 §4.2, RFC 7208 §5.1, RFC 9989 §4.10.1.
Null MX is a receiving declaration. It does not authenticate outbound mail, publish an SPF policy or make a domain immune to impersonation. RFC 7505 advises against Null MX on domains used in SMTP MailFrom or message From addresses because receivers may reject that mail. Use a reviewed receiving and return-address design for legitimate senders rather than treating Null MX as a harmless outbound setting.
For a domain intended neither to send nor receive, evaluate explicit outbound controls as a separate change. SPF v=spf1 -all is an illustrative denial for the exact SPF identity when no sender is authorized. A DMARC policy requires an explicit assessment of policy scope, subdomains and reporting. Do not paste a generic control set into a domain whose sending inventory is incomplete.
Test the negative route deliberately
References: RFC 5321 §5.1, RFC 7505 §3.
In an isolated zone, fixture A has noreceive.example. IN MX 0 . and an A record for its website. Expected mail routing recognizes Null MX rather than falling back to that web address. Fixture B has the A record but no MX; SMTP's implicit-MX behavior is a different case. Fixture C combines Null MX with an ordinary exchange and is an invalid configuration, not a supported failover design.
Query dig @AUTH noreceive.example. MX +norecurse for each valid fixture and retain the complete answer. Confirm that the Null MX case returns exactly the intended single record. Then use a controlled SMTP sender to inspect its handling without sending unsolicited traffic to unrelated infrastructure. The DNS cases are test specifications here; actual sender behavior remains pending execution.
Confirm the exact scope
References: RFC 4592 §3.3, RFC 8767 §4.
A Null MX at example.com is not automatically an MX record at sub.example.com. Test names separately, including wildcard and delegated branches. DNS absence, wildcard synthesis and explicit records can lead to different routes.
Document the nonreceiving decision with the business owner and have a second reviewer check the non-sending control plan where applicable. This guide does not claim that such approval has occurred. Roll back through the approved DNS process if a required address is discovered, allowing for cached records. Closure needs the intended published route and an independently reviewed inventory, not just a successful DNS save.
Retained lookup and reviewable control plan
The retained historical capture from 7 November 2026, inspected but not rerun for this review, records that a loopback authoritative UDP query for the synthetic noreceive.example MX returned exactly 0 .; the retained capture includes query, wire response, UTC time and authority endpoint. The accompanying concrete non-sending plan combines that MX with one SPF -all policy and an illustrative DMARC reject policy for a fixture explicitly assumed to have no legitimate mail. It lists recovery-address and subdomain preflight checks, reporting-data restrictions, receiver-test limits and rollback. Independent assessment of that plan is a review gate, not business-owner approval. The actual customer inventory and any public deployment remain unverified.
Keep the evidence scope explicit
The historical Null MX answer is preserved with its wire bytes and loopback endpoint. Its associated non-sending plan remains a synthetic proposal with inventory assumptions; neither its retention nor this content review supplies customer approval or tests actual receiver handling.