Current standard
What this RFC defines
RFC 7505 defines the Null MX record, a DNS resource record that explicitly signals that a domain does not accept incoming email. Before this RFC, domains without mail service either had no MX record (which some servers tried to deliver to the A record as a fallback) or a dummy MX record, both of which caused unnecessary delivery attempts and bounce loops.
Where you see it in practice
If your company uses yourdomain.com for web only and a different domain for email, adding a Null MX record (0 .) to yourdomain.com prevents mail servers from attempting delivery and generating backscatter bounces when they inevitably fail. When you try to send email to an address at a domain with a Null MX, a properly configured MTA will immediately reject the delivery attempt rather than retrying for days.
The Null MX concept
RFC 7505 defined the Null MX record for domains that accept no email. Published in June 2015, the standard specifies that a domain can publish an MX record pointing to “.” (a single dot, indicating no valid host) to declare that it does not accept mail. A submission or relay server that refuses a recipient because of a null MX SHOULD answer with reply code 556 (domain does not accept mail, defined in RFC 7504) and enhanced status code 5.1.10 (Recipient address has null MX). The sender learns at once that the address will never work, instead of hours or days later.
Why null MX helps
Before RFC 7505, domains that did not want to receive email had two options: omit the MX record entirely (in which case receivers would fall back to the A record and try to deliver, producing timeouts) or point the MX to a dummy host that would reject all mail (which required maintenance and produced ambiguous error messages). Null MX is unambiguous: the domain has explicitly declared no-email-here. It also protects the domain from being used as the return-path for spam campaigns, since bounces cannot be delivered.
The two status codes RFC 7505 defines
| Situation | Reply code | Enhanced status code | Meaning |
|---|---|---|---|
| You send to a domain with null MX | 556 | 5.1.10 | Recipient address has null MX: the domain accepts no mail |
| You send from a domain with null MX (MAIL FROM or From) | 550 | 5.7.27 | Sender address has null MX: the receiver refuses mail it could never reply to |
The second row is the trap: a null MX also tells receivers that the domain cannot get replies or bounces, so mail sent from it is likely to be rejected.
RFC 7505 (June 2015) defines the Null MX record: a DNS convention for domains that do not receive email. Format: example.com. IN MX 0 . (target is a bare dot). Sending MTAs recognize this and fail with 556 5.1.10 instead of retrying; mail sent from a null MX domain can be refused with 550 5.7.27. Reduces useless bounce processing, decreases attack surface (no mail server means no mail-related exploits), and provides clear signal that a domain is intentionally mail-less. Widely supported; recommended for any domain not intended to receive mail.
RFC 7505 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Signal that a domain does not accept email |
| DNS record | example.com. IN MX 0 . |
| Reply codes | 556 5.1.10 for a recipient at a null MX domain; 550 5.7.27 for a sender from a null MX domain |
| Sender action | Reject the send with permanent failure; do not retry |
| Rule | A domain with null MX MUST NOT publish any other MX record |
| Published | June 2015 |
Null MX vs alternatives
| Approach | Semantics | Sender behavior |
|---|---|---|
| Null MX (RFC 7505) | Definitive: this domain does not accept mail | Immediate 5.1.10 reject, no retry |
| No MX record, A record present | Fall back to A record per RFC 5321 (implicit MX) | Attempt SMTP to A record IP; often accepted or ambiguously rejected |
| MX pointing to invalid host | Configuration error | Temporary failure retries for days; wasted resources |
| MX pointing to blackhole | Accepts and discards | Silent data loss; sender does not know |
Null MX DNS configuration
Zone file format:
example.com. IN MX 0 .
The critical elements:
– Preference 0 (RFC 7505 specifies 0)
– No other MX record at the same name
– Target is a single dot (the DNS root, semantically “nowhere”)
At a DNS provider UI (Cloudflare, Route 53, etc.):
Type: MX
Name: @ (or the domain)
Priority: 0
Target: . (single dot)
Some UIs reject the bare dot; workarounds:
– Enter . directly
– Enter empty (some UIs accept)
– Use Terraform/API for direct DNS records
Verification:
dig example.com MX
; Should return:
; example.com. 3600 IN MX 0 .
Effect at SMTP time:
Sender’s MTA looks up MX for example.com; sees Null MX.
Sender immediately fails the send with 556 5.1.10:
Recipient address has null MX
Companion record for a domain that sends no mail (SPF, RFC 7208):
example.com. IN TXT “v=spf1 -all”
When to use Null MX
| Scenario | Why Null MX helps |
|---|---|
| Domain used only for HTTPS (marketing site, static content) | Signal that mail attempts should not be retried; reduces backscatter |
| Legacy domain that once had mail but no longer does | Prevents spurious mail delivery attempts to expired addresses |
| Test domain not intended for production mail | Definitive rejection, and receivers can refuse mail forged from it (5.7.27) |
| Vanity subdomain (blog.example.com) with mail served from parent | Explicit Null MX on the subdomain prevents accidental delivery attempts |
| Anti-phishing hardening for a critical brand domain | Complements DMARC p=reject; makes fake mail delivery even more difficult |
Common Null MX mistakes
MX 0 nullmx.example.com or similar; this creates a valid MX pointing at nullmx.example.com and mail is delivered there. Only MX 0 . is Null MX.Related standards and further reading
- SPF Record Guide: signal that domain does not send
- DMARC Record Guide: outbound domain protection
Frequently asked questions
Should every non-mail domain use Null MX?
Recommended for domains that will not receive mail. Benefits: reduces backscatter (retries of mail that will never succeed), clarifies intent to sender infrastructure, reduces attack surface (no phantom mail servers to test). Costs: nothing except a small DNS record. Verify no mail flow depends on the domain before setting.
What is the difference between Null MX and no MX record?
No MX: sender falls back to the A record per RFC 5321 implicit MX rules; may attempt delivery to the A record’s IP address. Null MX: sender sees definitive “no mail here” signal; immediate permanent failure with 5.1.10. Null MX is unambiguous; no MX is fallback behavior that varies by sender implementation.
Does Null MX affect DMARC reporting?
Yes. If your DMARC record specifies rua=mailto:dmarc@example.com and example.com has Null MX, the DMARC reports cannot be delivered. Either set the DMARC report addresses to a domain that accepts mail, or ensure the reporting-address domain does not have Null MX. Common pattern: use a separate reporting subdomain with real MX (dmarc-reports.example.com) while marketing/apex domain has Null MX.
How do I test my Null MX configuration?
DNS lookup: dig example.com MX should return example.com. IN MX 0 . (target is a dot). Send-test: send a test message to any@example.com; expect an immediate 556 5.1.10 rejection (or a bounce citing it) from your sending MTA. Third-party checkers: various DNS analysis tools recognize Null MX and confirm.
Can I use Null MX on a domain that only sends mail?
No, avoid it. RFC 7505 section 4.2 says mail systems SHOULD NOT publish a null MX for domains they use in the MAIL FROM or From address, because receivers reject mail whose return address cannot receive replies or bounces (550 5.7.27, Sender address has null MX). A domain that sends but should not receive human replies still needs a working MX for bounces; route it to a mailbox or bounce processor instead. Null MX is meant for domains that neither send nor receive, paired with v=spf1 -all.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.