Null MX: Protect Domains That Don't Accept Email

Most companies own several domains that never touch email: landing pages, redirect domains, technical subdomains, parked names. By default, any of them can be used as a spoofing vector or a backscatter sink. One DNS record closes that gap permanently.

A domain without email is not a domain without risk

Take promo.example.com, a landing page for an ad campaign. No mailboxes, no mail server. Sounds harmless.

SMTP disagrees. Per RFC 5321, when a sending server finds no MX records for a domain, it falls back to the domain's A or AAAA record and tries to deliver directly to that IP. A landing page almost always has an A record — otherwise the site wouldn't resolve. Anyone can attempt to send mail to anything@promo.example.com.

Two things go wrong. First: backscatter. Spammers put your domain in the From field. When the receiving server rejects the message it generates a bounce notification and sends it back to the apparent sender, which is you. Your inbox fills with NDRs for messages you never sent.

Second: spoofing. If someone sends phishing mail from your domain and you have no SPF or DMARC (because "we don't use this domain for email"), recipients have no way to detect the forgery.

What Null MX is

RFC 7505, published in 2015, defines Null MX as an explicit signal to every mail server on the internet: "This domain accepts no email. Do not attempt delivery."

The record looks like this:

example.com.    IN    MX    0    .

Priority 0, hostname is a dot. In DNS, a bare dot means the root zone — effectively "nothing." This must be the only MX record for the domain. No other MX entries alongside it.

When a sending server gets this response it must stop immediately. No A-record fallback, no retries. The address is rejected on the spot — equivalent to an SMTP 556 response.

How it works at the protocol level

Without Null MX, delivery to a domain with no mail server goes through eight steps:

1. Sender queries MX records for example.com
2. DNS returns NODATA or NXDOMAIN
3. Per RFC 5321, sender looks for an A/AAAA record
4. Finds an IP (say, 93.184.216.34 — the web server)
5. Tries to open an SMTP connection on port 25
6. Connection refused or times out
7. Message queued for retry
8. Retries continue for 1–5 days

With Null MX it collapses to two:

1. Sender queries MX records for example.com
2. DNS returns MX 0 . — sender generates an immediate bounce

One DNS query, instant rejection. No retry queue, no stale connections, no load on your web server.

How to set up Null MX

You need access to the domain's DNS panel — Cloudflare, Route 53, or any registrar. The whole thing takes about five minutes.

Step 1. Add the Null MX record

Create an MX record with priority 0 and value . (a single dot). Delete any other MX records that exist.

; Null MX — this domain accepts no mail
example.com.    IN    MX    0    .

In Cloudflare: Name = your domain, Priority = 0, Mail server = a dot. Some control panels don't accept a bare dot in the MX field — use the provider's API or switch to a DNS provider with full RFC support.

Step 2. Add SPF that blocks all senders

Null MX says "we don't receive." SPF with -all says "we don't send." Together they cover both directions.

example.com.    IN    TXT    "v=spf1 -all"

No include mechanisms, no permitted IPs. Just a hard fail for everyone.

Step 3. Add DMARC with p=reject

For a domain with no email, there's no reason to start at p=none. Nobody should ever send from this domain — go straight to p=reject.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Point rua to a mailbox on your main domain. The reports will show whether anyone tries to send from this one.

The complete record set

Three records, full protection:

; 1. Reject incoming mail
example.com.        IN    MX     0    .

; 2. No authorized senders
example.com.        IN    TXT    "v=spf1 -all"

; 3. Reject everything claiming to be us
_dmarc.example.com. IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Verifying the setup

After publishing, wait for the old TTL to expire (usually 5 minutes to a few hours), then check:

$ dig MX example.com +short
0 .

The response 0 . confirms Null MX is set correctly. If any other MX records appear alongside it, the configuration is invalid — Null MX must be the only entry.

$ dig MX example.com

;; QUESTION SECTION:
;example.com.                IN      MX

;; ANSWER SECTION:
example.com.         3600    IN      MX      0 .

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Note the TTL (3600 = 1 hour). A high TTL makes sense for Null MX — the record never changes, and longer TTLs reduce the number of DNS lookups from mail servers checking your domain.

$ dig TXT example.com +short
"v=spf1 -all"

$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

All three return expected values — the domain is protected.

Which domains need Null MX

Any domain or subdomain with no mailboxes and no plans for any. Specifically:

• Parked domains. Bought for brand protection or future use. Without Null MX, spammers can use them in From headers.
• Service subdomains. cdn.example.com, static.example.com, api.example.com — they serve traffic, not mail.
• Campaign domains. A short-lived promo domain. No one sends email through it.
• Redirect domains. An old company domain pointing to the new one. Mail moved long ago, but DNS records remain.
• Typosquat domains. Common misspellings registered defensively. None should have mailboxes.

Null MX and email address validation

For email validators, Null MX is an unambiguous signal. When a domain returns MX 0 ., every address on it is invalid — not "risky," not "needs further checking," just invalid. No A-record fallback, no SMTP handshake.

Compare that to a domain with no MX at all: the validator has to check the A record, attempt a connection, and wait for a timeout. With Null MX the check takes milliseconds — one DNS query, done.

If someone enters an address on a Null MX domain in your signup form, a validator catches it at the earliest possible stage, keeping your list clean and protecting your bounce rate.

Null MX vs. no MX records at all

These are meaningfully different, even if the end result looks similar: mail doesn't arrive.

No MX records (NODATA). The sender must apply the RFC 5321 fallback — look up A/AAAA, try port 25. Slow, resource-intensive, and unpredictable. Some servers retry for days.

Null MX (MX 0 .). Explicit rejection. Fallback is prohibited. The sender must stop immediately and generate a bounce. Clean, unambiguous.

# Domain without MX — falls back to A record
$ dig MX no-mail-configured.com +short
(empty)

$ dig A no-mail-configured.com +short
93.184.216.34
# Sender will try port 25 on this IP

# Domain with Null MX — immediate rejection
$ dig MX null-mx-configured.com +short
0 .
# Sender generates a bounce right away

Think of it as the difference between a locked door with no sign (visitors knock, wait, leave, come back) and a sign that reads "No one is here." Both stop entry, but only one saves time.

Compatibility

RFC 7505 is over ten years old. Every major MTA supports it: Postfix, Exim, Microsoft Exchange, Gmail, Yahoo Mail. When a sending server encounters Null MX, it handles the rejection correctly.

The one edge case is very old software — pre-2015 MTAs that have never been updated. They may not recognize Null MX and fall back to the A-record lookup. By 2026 these are rare, and for them you have SPF -all and DMARC p=reject as extra layers.

Common mistakes

• Null MX alongside other MX records. RFC 7505 requires Null MX to be the only entry. If MX 10 mail.example.com sits next to it, the configuration is invalid and behavior is unpredictable.
• Priority other than zero. MX 10 . is not Null MX. The RFC requires priority 0. Some servers may handle a non-zero value anyway, but you can't rely on it.
• Skipping SPF and DMARC. Null MX blocks inbound delivery. It does not block outbound spoofing. Without SPF and DMARC the domain is still vulnerable to impersonation.
• Applying Null MX to a domain with active mail. Before adding it, run dig MX against the current state and confirm there are no live mailboxes.
• DNS panel rejects the dot. Some registrars won't accept . in the MX field. Use the provider API (Cloudflare API, Route 53 API) or move to a DNS provider with full RFC support.

Checking Null MX across many domains

Checking a dozen domains by hand gets tedious. A small shell script handles it:

#!/bin/bash
# check-null-mx.sh — batch Null MX check

DOMAINS="promo.example.com cdn.example.com old.example.com"

for domain in $DOMAINS; do
  mx=$(dig MX "$domain" +short 2>/dev/null)

  if [ -z "$mx" ]; then
    echo "[$domain] WARNING: no MX records (A-record fallback active)"
  elif echo "$mx" | grep -q "^0 \.$"; then
    echo "[$domain] OK: Null MX configured"
  else
    echo "[$domain] WARNING: MX records present — $mx"
  fi
done

$ bash check-null-mx.sh
[promo.example.com] OK: Null MX configured
[cdn.example.com] WARNING: no MX records (A-record fallback active)
[old.example.com] WARNING: MX records present — 10 mail.old.example.com.

Two of three domains need attention: one has no MX (fallback active), the other has live MX records even though email on that domain is unused.

Full checklist for a non-mail domain

All the DNS records a domain that neither sends nor receives email needs:

• MX: 0 . — reject all inbound mail
• SPF: v=spf1 -all — no server is authorized to send on our behalf
• DMARC: v=DMARC1; p=reject — reject all unauthenticated mail
• DKIM: publish no DKIM keys. No key means no valid signature, which means auth fails on anything claiming to be from this domain.
• MTA-STS: not needed. MTA-STS is for domains that accept mail and want to enforce TLS on inbound delivery.

Setting Null MX via the Cloudflare API

If your DNS provider's GUI won't accept a dot in the MX field, use the API:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "MX",
    "name": "example.com",
    "content": ".",
    "priority": 0,
    "ttl": 86400
  }'

TTL 86400 (one day) is sensible for a record that never changes — it cuts down repeated DNS queries from mail servers checking your domain.

Summary

Null MX is a small change with a clear payoff. One DNS record tells every mail server on the internet to stop trying. Setup takes minutes, every modern MTA understands it, and paired with SPF -all and DMARC p=reject it covers every angle — inbound, outbound, and spoofed.

If your company has unused domains or technical subdomains without email, check them now. Run dig MX yourdomain.com +short — an empty response means the fallback is active and the domain is exposed. Five minutes of DNS work closes it permanently.