Null MX, RFC 7505, and Why 'No MX' Does Not Mean Invalid

A null MX record is a single line in DNS that tells every sender a domain accepts no email. It is defined in RFC 7505 and written as an MX record with priority 0 pointing at a single dot: MX 0 .. Crucially, it is not the same as a domain that simply has no MX record at all. Under RFC 5321, a domain with no MX can still receive mail through its A or AAAA address, so "no MX" does not mean an address is invalid. A null MX is the only way a domain explicitly says "do not deliver here," and collapsing those two cases into one is among the most common and costly mistakes in email address validation.

What is a null MX record?

A null MX record is a domain's machine-readable statement that it does not accept mail. It was standardized in June 2015 in RFC 7505, by John Levine and Mark Delany, on the IETF Standards Track. The record itself is deliberately minimal. A domain publishes a single MX resource record whose preference is 0 and whose exchange, the mail server field, is a single dot, the DNS root:

example.com.   IN   MX   0   .

Read left to right, that is the owner name, the DNS class (IN for internet), the record type (MX), the preference value (0), and the exchange (.). The dot is the whole trick. A single dot is not a valid hostname, so a null MX can never be mistaken for an ordinary MX record that happens to point somewhere. RFC 7505 borrowed this convention from the SRV record in RFC 2782, where a target of . already meant "no service here."

Two properties matter for anyone reading these records in the wild. First, a domain that publishes a null MX must not publish any other MX record; the null MX stands alone or not at all. Second, a null MX is an ordinary MX record in every other respect, which means it can be signed with DNSSEC like any other record and needs no special server, no listener, and no infrastructure. Publishing one dot in a zone file is the entire implementation.

What does RFC 7505 actually require?

RFC 7505 exists to solve a specific, old problem: the fallback that email delivery performs when a domain has no MX record. Section 5 of RFC 5321 tells a sender to look up an MX record first and, if none is found, to fall back to the domain's A or AAAA address and attempt delivery there. That fallback was never meant to be a way of saying "no mail." It simply reflects that mail predates MX records. The unfortunate side effect is that a domain used only for a website, with an A record pointing at a web server, looks to a naive sender like a mail destination. Mail sent to it is not refused; it is queued, retried, and only bounced after the sending server gives up, which RFC 7505 notes is typically about a week.

A null MX collapses that week into a single failed lookup. Because the domain now has an MX record, the A or AAAA fallback never triggers. And because that MX record points at ., there is no host to connect to, so the sender knows immediately that delivery is impossible. The requirement is exact: to declare no mail service, advertise one MX record with preference 0 and an exchange of ., and advertise no other MX record.

RFC 7505 also specifies how a well-behaved server should report the rejection, which is where it hands off to RFC 7504. When a submission or relay server refuses an envelope recipient because that recipient's domain has a null MX, it should return a 556 reply code paired with the enhanced status code 5.1.10, "Recipient address has null MX." There is a matching rule for the opposite direction. If a message arrives whose sender domain (the RFC 5321 MailFrom or RFC 5322 From) publishes a null MX, a receiver that rejects it should use a 550 reply and the enhanced status code 5.7.27, "Sender address has null MX." That second rule is a warning to domain owners, and I will come back to it: do not publish a null MX on a domain you actually send mail from.

One more recommendation from the spec is worth carrying into practice. A domain that sends and receives no mail should pair its null MX with a Sender Policy Framework (SPF) record of -all, an explicit statement that no host is authorized to send as the domain. The null MX says "nothing delivers here"; the SPF -all says "nothing sends from here." Together they close both directions.

Why does "no MX" not mean an email address is invalid?

This is the part that trips up validators, and it is worth stating plainly: a domain with no MX record is not an invalid mail domain. RFC 5321, Section 5.1, is explicit. If an MX lookup returns an empty list, the sender treats the domain as if it had an implicit MX record, at preference 0, pointing to the domain itself, and then delivers to that domain's A or AAAA address. In other words, "no MX record" resolves, by the standard's own rule, into "deliver to the address record." A domain can accept mail perfectly well without ever publishing an MX record.

This is not a rare edge case. Plenty of small domains, personal domains, and older setups run mail on the same host as their website and never bothered with an MX record, and mail to them is delivered through exactly this fallback. In our own August 2026 data report, 26,386 of the disposable domains that were live that day had no MX record and qualified as reachable only through the RFC 5321 address-record fallback. Those are domains a naive "MX or reject" validator would have thrown away as invalid, even though mail could route to them.

Two honest caveats belong here, because the fallback is a weaker signal than a real MX record. Relying on it is discouraged in practice: not every sending system still performs the A or AAAA fallback, and the address record usually points at a web server that is not listening for mail anyway. So a domain with an A record but no MX might accept mail, or might not. But "might not accept mail" is a completely different statement from "is invalid," and it calls for a completely different action. The only DNS state that means a definitive, standards-based "no mail" is a null MX. Everything else is a spectrum from "probably yes" to "probably no," and none of it is "invalid."

Null MX vs no MX record: what is the difference?

The two are opposites, not variants. A domain with no MX record is leaning on a decades-old fallback that usually still works; a domain with a null MX has taken a deliberate action to shut mail off. One is an absence, the other is a declaration. A validator that treats them the same way will either reject deliverable domains or accept undeliverable ones, depending on which way it errs.

The clearest way to hold this straight is to map each DNS state to what it means for delivery and what a validator should do about it.

DNS state	What it means	Can mail be delivered?	What a validator should do
One or more valid MX records	The domain names mail servers that accept its mail	Yes	Accept the domain as mail-capable
No MX, but an A or AAAA record	RFC 5321 implicit MX: mail routes to the address record at preference 0	Yes in principle, though many senders no longer try	Do not reject for the missing MX; the address can receive mail
Null MX (`MX 0 .`)	RFC 7505: the domain declares it accepts no mail	No	Treat as undeliverable; safe to reject
No MX and no A or AAAA (name resolves, no usable records)	No route to any mail server	No	Treat as undeliverable
NXDOMAIN (the domain does not exist)	There is no such domain	No	Reject as an invalid domain

The pattern in that table is the whole point of this article. There is exactly one row where the correct action is a confident, standards-based rejection: the null MX. There is exactly one row that a careless validator most often gets wrong, the "no MX, but an A or AAAA record" case, which is deliverable and should not be rejected. Get those two rows right and you have solved most of what this topic is about.

What SMTP reply codes does a null MX trigger?

Null MX has its own dedicated signaling, spread across two RFCs published the same month. RFC 7504 defined the two three-digit reply codes, and RFC 7505 registered the two enhanced status codes that go with them. If you parse bounces, or you want to log why an address was refused, these are the codes to recognize.

Code	Type	Meaning	Who sends it	Defined in
521	SMTP reply	Host does not accept mail	The destination host itself, on connection	RFC 7504
556	SMTP reply	Domain does not accept mail	A relay or sender that reads the null MX, before connecting	RFC 7504
5.1.10	Enhanced status	Recipient address has null MX	Paired with a 556 reject of a null-MX recipient	RFC 7505
5.7.27	Enhanced status	Sender address has null MX	Paired with a 550 reject when a null-MX domain is used as the sender	RFC 7505

A few notes on reading them. The 521 and 556 codes look similar but come from different places in the delivery path. A 521, "Host does not accept mail," is returned by the destination host itself, on the initial connection, to say it never handles mail. A 556, "Domain does not accept mail," is returned earlier and more efficiently: a relay or sending server determines from DNS, typically from a null MX, that the domain accepts no mail, and refuses without ever opening a connection. RFC 7504 calls the null MX lookup the only standardized way, at the time it was written, for a relay to make that determination.

The enhanced status codes carry the precise reason. A refused recipient at a null-MX domain gets 5.1.10; a message refused because its sender domain has a null MX gets 5.7.27. In a bounce, you will usually see the reply code and the enhanced status code printed together, for example a 556 with a 5.1.10. Because the decision is made from DNS before any connection, a null MX bounce arrives almost immediately, not after the usual days of retries. That speed is a feature: you learn on the first attempt that the address will never work.

How do you check whether a domain publishes a null MX?

You can read any domain's MX records from the command line in a second, and a null MX has an unmistakable signature. With dig, ask for the MX records in short form:

dig +short MX example.com

If the domain publishes a null MX, the entire answer is a preference of 0 followed by a single dot:

0 .

That one line, 0 ., is the null MX. A normal mail domain returns one or more hostnames instead, each with its preference, like 10 mail.example.com.. A domain with no MX record at all returns nothing from that command, at which point you would check for an address record with dig +short A example.com to see whether the RFC 5321 fallback has anything to route to.

If you prefer nslookup, the equivalent query is:

nslookup -type=mx example.com

and a null MX shows up as an MX preference of 0 with the mail exchanger given as the root, the single dot. The tool matters less than the signature. Whatever you use, you are looking for exactly one MX record, preference 0, target ., and no others. Anything else is not a null MX.

What happens if your validator rejects every domain without an MX record?

You reject real people. This is the practical cost of the confusion at the center of this article, and it is worth being concrete about who gets hurt. A validator that rejects any address whose domain lacks an MX record will refuse every domain that relies on the RFC 5321 address-record fallback, which, as the data above showed, is a real and populated category. Some of those are throwaway domains you would happily block anyway, but many are legitimate small or personal domains that run mail on their web host. To the person signing up, the result is identical and infuriating: a valid address they use every day, rejected at your form with no good reason.

The failure is asymmetric, which is what makes it dangerous. Rejecting a deliverable address is an immediate, visible loss: a real signup, a real customer, gone at the door. Accepting an undeliverable one is a smaller, later cost that you can manage. So when a validator has to guess, the safer default for a "no MX but has an A record" domain is to accept, not reject, because the downside of a wrong rejection is worse than the downside of a wrong acceptance. The one case where rejection is clearly correct, and carries almost no risk of a false positive, is the null MX, because the domain itself has told you not to deliver. Reserve your hard "no" for the state that actually means no.

For a signup form, the useful way to think about a null MX is that it is the one DNS answer you can act on without hesitation. If the domain a user typed publishes a null MX, mail to that address will never be delivered, full stop, so there is no reason to accept it into your list. It is a clean, standards-based rejection with essentially no false-positive risk. A domain with no MX but a working address record is the opposite: accept it, because it can receive mail. And a domain with real MX records is your normal, deliverable case. The August report found 3,271 tracked domains, about 1.54 percent, publishing a null MX on a single day. Small in proportion, but every one of them is an address that will hard bounce the instant you mail it.

That last point is where the real risk lives, and it is worth being precise about where it does not. Accepting addresses that bounce does not damage your sending reputation at Gmail, Outlook, or Yahoo in the way people often assume. Those mailbox providers judge your reputation on how their own users engage with your mail, and a null-MX domain has no users at any of them. The damage lands one layer closer to home, at your email service provider (ESP). When you mail an address that bounces, and a null-MX or no-route domain bounces every time, that hard bounce counts against your list quality. A spike in hard bounces is one of the strongest signals an ESP watches, and platforms like Mailchimp and SendGrid act on it: a warning, a throttle, a forced list cleaning, or a suspended account. So the reason to catch a null MX at the signup form is not a vague reputation worry with Gmail; it is keeping your bounce rate low enough that your own sending platform stays happy.

Doing this well means validating the address the moment it is entered, rejecting the definitive "no mail" states, and letting the deliverable ones through, including the no-MX-with-address case that a blunt filter would wrongly reject. That is exactly the distinction this article is about, and it is the logic behind our own detection: isitdisposable.com checks a domain against a live dataset of more than 216,000 disposable domains from six upstream sources, MX-validated and refreshed daily, and returns the DNS reality, a real MX, an address-record fallback, or a null MX, in a single API call or a JavaScript snippet. It is built to fail open, so if the service is ever unreachable your signups keep working rather than stalling, and there is a free plan with 250 lookups a month plus a 14-day full-access trial, no credit card, if you want to test it against your own traffic.

How and when should you publish a null MX?

If you own a domain that does not receive email, publishing a null MX is good hygiene, and it is genuinely one line. In your DNS zone, add a single MX record with priority 0 and the target set to a dot:

example.com.   IN   MX   0   .

Most DNS providers expose this through a web form: choose record type MX, set the priority or preference to 0, and set the value, mail server, or target field to a single .. Some control panels want the dot typed literally, and some accept an empty value that they render as the root; if the form rejects a bare dot outright, that provider does not yet support null MX and it is worth asking them. Publish no other MX record for the domain, because RFC 7505 requires the null MX to stand alone. Pair it with an SPF record of -all so the domain also declares that nothing is authorized to send as it. The two records together tell the world the domain neither receives nor sends mail, which is exactly the statement a parked domain, a website-only domain, or a brand-protection registration wants to make.

There is one case where you should not do this, and RFC 7505 is direct about it: do not publish a null MX on a domain you actually send mail from. Sending domains need a working return path so that bounces and delivery status notifications can come back, and a receiver that sees a null MX on your sender domain is entitled to reject your mail outright with a 550 and a 5.7.27 status. If a domain sends but genuinely never needs to receive anything, that is a more delicate configuration than this article covers, and the safe general rule is simpler: null-MX the domains that neither send nor receive, and give any domain that sends a real, monitored mailbox for replies and bounces.

Are relay services like Apple Hide My Email affected by a null MX?

No, and it is important not to confuse the two, because they sit at opposite ends of the deliverability spectrum. A relay or alias service, Apple Hide My Email, Firefox Relay, SimpleLogin, addy.io, DuckDuckGo Email Protection, or a Proton alias, gives a real person a masked address that forwards to a real, permanent inbox they read. Those domains publish real, working MX records, because they very much do receive mail in order to forward it. A null MX is the exact opposite signal: a domain announcing that nothing is delivered there at all. The two never overlap.

This matters for validation because relay addresses are deliverable and belong to engaged, often paying users, so they should pass your signup form, not fail it. We detect relay and forwarding domains and flag them as their own category, separate from both disposable domains and null-MX domains, precisely so that they can be recognized and allowed rather than swept up in a filter. Blocking a relay address to stop throwaway signups turns away a real customer; it is a self-inflicted wound, and it is a different mistake from the one this article is mostly about. Keep three buckets in mind, not one: real mail domains, including relays, that you accept; no-MX-but-addressable domains that you also accept; and definitive no-mail domains, null MX and no route at all, that you reject.

Null MX record FAQ

Is a null MX record the same as having no MX record? No. A null MX (MX 0 .) is a deliberate declaration that a domain accepts no mail. No MX record at all means a sender falls back, under RFC 5321, to the domain's A or AAAA address and may still deliver. One is a definitive "no"; the other is "probably yes."

Does "no MX record" mean an email address is invalid? No. Under RFC 5321, a domain with no MX can still receive mail through its address record, so a missing MX is not grounds to treat an address as invalid. Only a null MX is a standards-based "do not deliver."

Can a domain with a null MX still send email? It should not. RFC 7505 warns against publishing a null MX on a domain used as a sender, because receivers may reject that mail with a 550 and a 5.7.27 enhanced status. Null MX is for domains that neither send nor receive.

What bounce code does a null MX produce? A recipient at a null-MX domain is refused with a 556 reply and a 5.1.10 enhanced status, "Recipient address has null MX," usually within seconds, because the decision is made from DNS before any connection.

How do I see whether a domain has a null MX? Run dig +short MX example.com. If the only answer is 0 ., the domain publishes a null MX. Any other result, including no result at all, is not a null MX.