Let's start with an observation: Most organizations we audit don't own a single mail domain — they own dozens. Old brands, campaign domains, defensively-registered names sitting parked, addresses kept only for forwarding. Most of them neither send nor receive mail. The problem: DNS doesn't know that. And every domain that doesn't say "no" is a silent lure for attackers and a black hole for undeliverable mail.
RFC 7505 closes exactly that gap. It's a short, little-known 2015 Standards Track document that says one thing: the standard way to announce, over DNS, that a domain accepts no email at all. It's called "null MX".
1. The Problem: No MX Means the System Guesses
When a sending server (MTA) wants to deliver mail to example.com, it follows the sequence described in RFC 5321: first it looks up the MX record. If there is no MX, it falls back to the domain's A/AAAA record and treats that IP as the mail server.
That's the trap. Your domain has an A record because it has a website — but there's no SMTP listener at that address. The sender can't know this up front; it tries to connect, times out, retries… and this loop typically lasts a week. The result: a misaddressed message bounces back to its owner days late, while the sender piles up wasted queue and resources.
2. The Solution: MX 0 .
Null MX announces, in a single definitive record, that the domain accepts no mail. You publish exactly one MX record: preference number 0, and the exchange target set to a single dot — an empty label:
example.com. IN MX 0 .
Because "." is not a valid host name, this record can't be confused with an ordinary MX; its meaning is unambiguous: "there is no mail server here." The rule is strict — a domain that advertises a null MX MUST NOT advertise any other MX record (RFC 7505). The approach is modeled on the same "." used in SRV records to mean "no service available."
The effect is immediate: the sender sees, on the very first attempt, that delivery has permanently failed. No queue, no week of retries, no delayed notification.
3. The Standard Status Codes: 556 and 550
Null MX isn't just a behavior; it also introduced new IANA-registered status codes. If you see these in reports or rejection logs, you'll now know what they mean:
- Recipient side (you wrote to an address whose domain has null MX): basic code
556+ enhanced code5.1.10— "Recipient address has null MX". - Sender side (you received mail whose envelope domain has null MX):
550+5.7.27— "Sender address has null MX". The receiver may reject it because the return path is invalid.
4. Critical Warning: Don't Null-MX a Domain You Send From
Null MX is only for domains that neither receive nor send. RFC 7505 warns explicitly: a mail system SHOULD NOT publish a null MX for any domain it uses in MAIL FROM (envelope-return) or From: addresses. Many receiving systems reject mail with an invalid return address as spam — you'd sabotage your own outbound mail.
Simple rule: a sending domain needs a proper MX/SPF/DKIM/DMARC setup, not a null MX. Null MX is for the silent domains sitting on the sidelines.
5. The Triple Seal: Null MX + SPF -all + DMARC
Null MX alone says "I don't receive." But an attacker doesn't want to send mail to your domain — they want to send mail as your domain. So a non-sending domain must be sealed from three directions:
- Null MX — "this domain accepts no mail" (
MX 0 .). - SPF
-all— "this domain sends no mail":v=spf1 -all. RFC 7505 recommends this directly as an explicit declaration for non-sending domains. - DMARC
p=reject— "if you see forged mail in my name, reject it":v=DMARC1; p=reject; rua=mailto:....
Together, these announce a parked domain in three separate languages: "I don't receive," "I don't send," and "reject my impersonators." We walk through the full authentication layer step by step in our SPF, DKIM, DMARC setup guide.
6. The DMARCbis Link: the np Tag
The new DMARC standard published in May 2026 (RFC 9989, which replaces RFC 7489) added a tag that completes this picture: np — the non-existent domain policy, i.e. the policy for subdomains that don't exist. An organization can request that forged mail from never-created subdomains (e.g. an address like billing.example.com that was never provisioned) be rejected outright with np=reject.
So the table completes itself: null MX covers existing domains that don't receive, SPF -all covers those that don't send, DMARC p=reject covers impersonation of the main domain, and DMARCbis np=reject covers impersonation of subdomains that never existed. Four layers, one goal: no one gets to speak in your name.
7. Why It Matters Now: Silent Domains in the AI Era
This topic being "little known" doesn't make it unimportant — quite the opposite. Let's speak with numbers: in Google Trends worldwide data for January 2024–August 2026, rising queries include "brand impersonation" up 450%, "ai impersonation" up 2,000% and "ai voice impersonation" up 800%. Attackers now generate convincing fake content in seconds and look for a "legitimate-looking" domain to send it from.
The parked domains organizations forget about are tailor-made for this: nobody monitors them, nobody audits them, and DNS says no "no" anywhere. Sealing every unused domain with null MX + SPF -all + DMARC p=reject is the cheapest way to quietly shrink your attack surface. Just remember: authentication stops exact impersonation of your domain; for look-alike domains and compromised real accounts you need a behavioral analysis layer.
8. Security and Verification
A null MX is an ordinary MX record within DNS; it introduces no new security risk and can be signed with DNSSEC like any other record if desired. In fact, DNSSEC shouldn't be neglected on parked domains: if your null MX, SPF -all and DMARC p=reject records are altered in transit, every "no" you published is silently defeated. Verification is simple: query your domain's MX record — if you see a single line with 0 ., you're done.
If you own dozens of domains, checking each by hand is tedious. mailskop.com produces a domain's MX, SPF, DKIM, DMARC and BIMI report card in seconds, so you can see whether your parked domains are actually sealed. The engine was built by Kinetik Bilişim and is free.
Frequently Asked Questions
What is null MX?
A special MX record that announces, over DNS, that a domain accepts no email at all: preference 0 and an empty "." target (MX 0 .). It is defined by RFC 7505.
How do I publish a null MX?
You add the record example.com. IN MX 0 . to DNS and leave no other MX record on that domain.
What's the difference between null MX and SPF -all?
Null MX says "I don't receive mail"; SPF -all says "I don't send mail." On domains that neither receive nor send, use both together.
Can I put a null MX on a domain I send from?
No. RFC 7505 recommends against publishing null MX for domains you use in MAIL FROM or From: addresses; your mail may be rejected.
What does status code 5.7.27 mean?
"Sender address has null MX" — the receiver rejected the message because the sender's envelope domain publishes a null MX. Its recipient-side counterpart is 556 + 5.1.10.
What to do next
If you have ten minutes: list every domain your organization owns and flag the ones that don't send mail. For each, check the MX, SPF and DMARC records — how many say no "no" at all? If the answer bothers you:
- Free posture audit: a report card of all your domains (active + parked) across SPF/DKIM/DMARC/MX, plus missing null-MX and look-alike domain risk.
- Managed rollout: SPF/DKIM/DMARC management on active domains, and null MX +
-all+p=rejectsealing on parked ones — all under one roadmap.
About this article: It is part of our Mail Technologies Series and complements our SPF, DKIM, DMARC guide. Kinetik Bilişim is the Türkiye partner of Check Point Software Technologies at the Advanced Partner 2026 level, holding Email, Endpoint & Browser, Mobile, and SASE Solution Specialization accreditations. The author, Kemal Özleyen, is a cybersecurity engineer certified as a Check Point Workspace Security Expert.
