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.
How it connects to other RFCs
RFC 7505 extends the DNS MX record system that RFC 5321 uses for mail routing. It is particularly useful alongside RFC 7489 (DMARC), where subdomains used only for web services can be protected from spoofing while also signaling no mail service. It complements RFC 2142 (which defines the postmaster@ mailbox) by clarifying which domains genuinely have no mail infrastructure.
Current status
RFC 7505 is a current standard, published June 2015. Null MX is supported by major MTAs including Postfix, Exim, and PowerMTA. It is a simple, low-cost protection for any domain that does not send or receive email.
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. Sending MTAs seeing this null MX should reject the message immediately with a 550 permanent failure and a status code of 5.1.10 (No answer from host / rejected by administrator). This tells the sender clearly that the address will never work, allowing prompt bounce handling.
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.
Adoption in practice
Null MX sees increasing use for domains that host only websites or APIs with no email function. Company domains hosting purely marketing sites often publish null MX. Cloud infrastructure domains (used only for API endpoints) frequently use it. Adoption is not universal because many domain owners are unaware of the standard; they simply leave the MX record blank, which produces less definitive rejection behavior. If you own a domain that does not receive mail, adding “example.com. IN MX 0 .” to DNS is a small change with real benefit.
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 reject with a definitive 5.1.10 code instead of retrying. 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 . |
| Enhanced status code | 5.1.10 (Recipient address has null MX) |
| Sender action | Reject the send with permanent failure; do not retry |
| 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
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 prevents accidental use as sender |
| 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 immediate 5.1.10 rejection 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?
Yes. A common pattern: transactional-sending subdomain (mail.example.com) has SPF/DKIM/DMARC records for signing outbound mail but does not accept inbound. Adding Null MX to that subdomain is appropriate: it sends but does not receive. Distinct from Null MX on domains that neither send nor receive.
About 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.
