← RFC Reference

RFC 7505: Null MX — No Service for Domain

Why This Exists

Not every domain receives email. A domain used purely for a website, an API, a CDN, or a brand-protection registration has no need for inbound mail. But before RFC 7505, there was no clean way to declare "this domain does not accept email" in DNS.

Without an explicit signal, sending servers encountering mail addressed to a no-mail domain would:

• Fall back to the A/AAAA record. Per RFC 5321, if no MX record exists, the sender tries delivering to the domain's A or AAAA address. This connection attempt fails (there's no SMTP server listening), but only after a timeout — typically 30+ seconds.
• Generate backscatter. If a spammer forges a return address at the no-mail domain, the bounced spam notification (DSN) gets sent to the forged address. The domain's A record accepts the TCP connection (it's a web server), but the SMTP conversation fails. The sending server queues retries for hours or days.
• Waste resources. Each failed delivery attempt consumes DNS queries, TCP connections, and queue slots on the sending server.

RFC 7505 introduces the Null MX record: a single MX entry with preference 0 and a target of . (the root domain). This tells any sending server: "This domain does not have a mail service. Don't try."

How It Works

The Null MX Record

The record has two defining characteristics:

• Preference 0: The lowest possible priority, ensuring this record is processed first (and, since it's the only MX, last).
• Target . (dot): The DNS root label. This is not a valid hostname and cannot be resolved to an IP address. It's the DNS equivalent of /dev/null.

Sender Behavior

When a sending server looks up the MX records for a recipient domain and finds a Null MX:

1. It recognizes the . target as a Null MX.
2. It immediately generates a permanent failure (5.1.0 — "Other address status") without attempting any SMTP connection.
3. The sender returns a bounce to the original sender (or discards the message if it was a bounce itself).

Contrast: Without Null MX

Without a Null MX, here's what happens when mail is sent to a domain with no MX records:

Key Technical Details

Rules for Null MX

• The Null MX must be the only MX record for the domain. You cannot mix a Null MX with real MX records.
• The preference value must be 0.
• The target must be exactly . (a single dot, the DNS root).
• If a sender encounters a Null MX, it must not fall back to A/AAAA records. The Null MX is definitive.

Combined with SPF and DMARC

For domains that don't send or receive email, Null MX should be part of a complete no-email DNS configuration:

This combination provides comprehensive protection: Null MX stops inbound delivery attempts, SPF -all tells receivers to reject spoofed outbound mail, and DMARC p=reject enforces the policy with reporting.

SMTP Response Codes

Impact on SMTP VRFY and EXPN

If a server is asked to verify or expand an address at a Null MX domain, it should return a permanent failure. There are no valid recipient addresses at a domain that doesn't accept mail.

Common Mistakes

• Mixing Null MX with real MX records. A Null MX must be the sole MX record. Adding MX 0 . alongside MX 10 mail.example.com creates an invalid configuration. Some resolvers may ignore the Null MX; others may reject all mail.
• Using Null MX on a domain that sends email. Null MX only affects inbound mail. But many services use the same domain for sending and receiving. If you set Null MX on your sending domain, you won't receive bounces, delivery status notifications, or replies to your messages.
• Forgetting SPF and DMARC. Null MX prevents inbound delivery, but it does nothing to stop someone from spoofing the domain as a sender. Always pair Null MX with v=spf1 -all and v=DMARC1; p=reject.
• Using MX 0 localhost instead of Null MX. Some admins use a bogus hostname instead of .. This doesn't work as a Null MX. Senders will try to resolve "localhost" and may connect to their own loopback interface, creating mail loops.
• Not applying to subdomains. If example.com has proper MX records but unused.example.com doesn't, set Null MX on the subdomain explicitly. Subdomains do not inherit MX records from parent domains.
• Assuming all senders support Null MX. RFC 7505 is well-supported by major MTAs (Postfix, Exim, sendmail, Exchange), but some older or niche systems may not recognize it and will fall back to A/AAAA lookups anyway.

Deliverability Impact

• Faster bounce processing. When a sender encounters Null MX, it bounces immediately instead of queuing retries for hours or days. This reduces queue pressure on the sending infrastructure and gives the original sender faster feedback.
• Eliminates backscatter. Spammers who forge return-path addresses at Null MX domains won't trigger delivery attempts. This protects the domain from being buried in misdirected bounces and protects sending servers from wasting resources on undeliverable backscatter.
• Brand protection for parked domains. Organizations that register multiple domains for brand protection can set Null MX + SPF + DMARC on every unused domain, preventing them from being exploited for phishing.
• Reduces DNS and network load. Without Null MX, a sending server may make multiple connection attempts over hours before giving up. Null MX eliminates all of those attempts with a single DNS query.
• Clean sending infrastructure. For email service providers, Null MX reduces the volume of undeliverable mail in outbound queues, freeing resources for legitimate delivery and improving overall throughput.

Related RFCs