How to protect domains that never send email

Most organizations own domains that never send email: defensive registrations of typos and old brand names, domains bought for a campaign, domains that only host a website. Nobody watches them, and without the right DNS records a receiver has no way to know that mail claiming to come from them is fake. M3AAWG points out that domains resembling well-known ones are especially attractive for abuse.

A handful of DNS records say “this domain neither sends nor receives mail”. They cost nothing and need almost no maintenance.

The records at a glance

For a domain example.net that never sends or receives email:

example.net.          3600  IN  MX   0 .
example.net.          3600  IN  TXT  "v=spf1 -all"
_dmarc.example.net.   3600  IN  TXT  "v=DMARC1; p=reject"

Optionally add a DKIM revocation wildcard and an address for DMARC reports. The sections below explain each record and how to cover subdomains.

SPF: nobody may send

v=spf1 -all contains a single mechanism, all, which matches every sending server, with the - (fail) qualifier — so every server gets the result fail. RFC 7505 points to exactly this record as the way a domain that sends no mail can say so explicitly.

SPF is not inherited: a check for shop.example.net looks only at shop.example.net. Publish the record at every name that exists, or add a wildcard, as M3AAWG suggests:

*.example.net.        3600  IN  TXT  "v=spf1 -all"

A wildcard only answers for names that don’t otherwise exist in the zone. A name with records of its own — say www.example.net with an A record — doesn’t receive the wildcard TXT, so it needs its own v=spf1 -all.

DMARC: reject everything

With SPF authorizing nobody and no DKIM key in use, no message can produce an aligned SPF or DKIM pass for this domain. Every message with example.net in the From header therefore fails DMARC, and p=reject asks receivers to reject it.

Because sp defaults to p, and np defaults to sp and then p (RFC 9989), this one tag covers subdomains as well. Guidance such as the UK government’s also spells out sp=reject and strict alignment (adkim=s; aspf=s); that is harmless. Receivers still implementing RFC 7489 don’t know np, but they fall back to sp or p, which reject too.

p=reject is a strong request, not a command. RFC 9989 tells receivers to weigh other evidence before rejecting, and some quarantine such mail instead.

Reports are optional

M3AAWG considers the rua tag optional for parked domains: there are no legitimate mail streams to fix, though the reports do show how much abuse is being stopped. If you want them, the address has to be in a domain that receives mail — not the parked domain with its null MX. A report address outside the parked domain’s organizational domain must be authorized by the domain that receives the reports (RFC 9990, section 4):

_dmarc.example.net.                       IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net._report._dmarc.example.com.   IN  TXT  "v=DMARC1"

A wildcard *._report._dmarc.example.com authorizes reports for all your parked domains at once — and for any other domain that names your address, so use it only if you are prepared to receive those. The DMARC checker shows whether each report address is authorized.

Many parked domains

M3AAWG shows a way to manage dozens of domains from one place: point each _dmarc name at a shared record with a CNAME.

_dmarc.example.net.          IN  CNAME  _dmarc.parked.example.com.
_dmarc.example.org.          IN  CNAME  _dmarc.parked.example.com.
_dmarc.parked.example.com.   IN  TXT    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Each parked domain still needs its own authorization record at the report domain, or the wildcard.

Null MX: no mail in, either

example.net.  3600  IN  MX  0 .

A null MX (RFC 7505) is a single MX record with preference 0 and a lone dot as the host. It must be the only MX record of the domain.

Without it, a sender whose message is addressed to the domain falls back to its A or AAAA record and, if no mail server answers there, keeps retrying — RFC 7505 says typically for a week. With a null MX, delivery fails at once; RFC 7505 recommends reply code 556 with enhanced status 5.1.10. Receivers may also reject mail whose envelope sender or From domain has a null MX (550 with 5.7.27). That is why RFC 7505 says not to publish it for domains you send from.

For subdomains, M3AAWG suggests a wildcard *.example.net. MX 0 .. Some DNS panels can’t create a null MX; if yours can’t, leave the MX out — SPF and DMARC still protect the domain against spoofing. Check the result with the MX lookup.

With no mailboxes, postmaster@ and abuse@ addresses don’t work either. M3AAWG suggests using the contact mailbox in the zone’s SOA record so that people can still reach whoever runs the domain. More on the record itself in Null MX: declaring that a domain accepts no email.

DKIM: publish nothing, or revoke explicitly

There are two schools of thought, and both lead to the same DMARC result:

• Publish nothing. M3AAWG recommends no DKIM records for parked domains: a forged signature claiming the domain can’t be verified because no key exists.
• Revoke everything with a wildcard. The UK government’s guidance publishes an empty key for every selector and asks you to revoke all existing selectors, both TXT and CNAME records:

*._domainkey.example.net.  3600  IN  TXT  "v=DKIM1; p="

An empty p= means the key has been revoked (RFC 6376), so every selector a forger picks now returns an explicit “revoked” answer instead of “no key”.

Either way, look for leftovers. Selectors that are published explicitly take precedence over a wildcard, and a CNAME that still points to a former provider’s key is a valid signing key someone else controls. Remove or revoke them. With the wildcard in place, the DKIM checker should report a revoked key for any made-up selector.

Subdomains: sp, np and web-only hosts

The same ideas protect the non-sending parts of a domain that does send mail. Say example.com sends email, but www.example.com and shop.example.com only host websites.

• Each existing subdomain that sends no mail gets its own v=spf1 -all and, because it has an A record, a null MX (M3AAWG’s example for web-only names).
• Its DMARC policy comes from the record at example.com, through sp (or p). If example.com is still at p=none, publish a separate record such as _dmarc.www.example.com with p=reject; receivers look for the subdomain’s own record first.
• Subdomains that don’t exist are covered by np. Phishers like invented names such as invoices.example.com, and np=reject rejects them even while p is still quarantine:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"

For DMARC, a name is non-existent when the DNS answers NXDOMAIN for it — which also means that nothing below it exists (RFC 9989, section 3.2.13). A wildcard record therefore makes every name “exist”: with *.example.com records in your zone, np never applies and sp decides. np is new in RFC 9989 (it comes from RFC 9091); receivers still on RFC 7489 ignore it and use sp or p.

Before you lock a domain down

• Make sure it really sends nothing. Old invoicing tools, website contact forms and automatic notifications sometimes use a forgotten domain in From. Auto-replies and forwarding from mailboxes on the domain count as sending too. If you are not sure, publish p=none with a rua address for a few weeks and read the reports first — see How to read DMARC aggregate reports.
• Receiving but not sending is a different case. If the domain receives mail — for example an alias forwarded to your main mailbox — keep its MX and skip the null MX. v=spf1 -all and p=reject still fit as long as nothing is sent with the domain in From or in the envelope sender.

Check your work

1. MX lookup: the domain shows a null MX and nothing else.
2. SPF checker: a single valid record, v=spf1 -all.
3. DMARC checker: p=reject, the effective subdomain policies and authorized report addresses.
4. DKIM checker: with a made-up selector, a revoked key if you use the wildcard; no leftover selectors from former services.

For the full DMARC rollout on domains that do send email, see How to configure DMARC correctly.