What DNS records should a domain that sends no email have?

Three records close a non-sending domain. An SPF record of v=spf1 -all, which states that no server anywhere is authorised to send for the domain. A DMARC record of v=DMARC1; p=reject; at _dmarc, which instructs receivers to refuse anything claiming to be from the domain. And, only if the domain also receives no email, a null MX record (preference 0, target '.') per RFC 7505, which declares the domain accepts no mail at all. Microsoft documents the SPF and DMARC pair for parked domains; no DKIM records are needed because there is nothing legitimate to sign.

What is a null MX record and when should I not use one?

A null MX (RFC 7505) is a single MX record with preference 0 pointing at the root '.' — a formal declaration that the domain does not accept email, so senders fail fast instead of queueing or falling back to the web server's address. It must be the domain's only MX record. Never publish one on a domain that receives mail you need — a contact@ address on an old domain, say — because null MX refuses inbound mail by design. Domains that receive but never send keep their real MX and use only the SPF and DMARC records.

Does locking the root domain protect its subdomains too?

Mostly, by inheritance: DMARC policy discovery falls back from a subdomain to the organisational domain's policy (the sp tag governs existing subdomains, and under current DMARC the fallback chain reaches the root's p=reject). Two limits matter. A subdomain with its own records or a delegated nameserver sits outside this protection and must be handled itself, and dangling DNS records pointing at abandoned services can let attackers stand up sending subdomains that pass checks — a lockdown includes sweeping for stale records, not just adding three new ones.

Parked domains · Spoofing · DNS

Your domain sends no email? Lock it down anyway — in three records

First published 20 October 2026 · The record set follows Microsoft's documented parked-domain configuration and RFC 7505 (null MX), read directly for this guide.

OPEN BY DEFAULT No SPF · No DMARC · Anyone can send as this domain

That spare domain — the .net variant, the old brand name, next year's project — currently lets anyone on Earth send email as it, in your business's name, and Yahoo counts spoofed mail in a domain's name toward that domain's enforcement review. Nothing about the domain being “unused” protects it. The opposite is true.

Spoofing cost to attacker: $0Lockdown cost to you: 3 records, 10 minutes

First, the fork — which domain is yours?

Situation	Your record set
A — Sends nothing, receives nothing (true parked/defensive domain)	SPF `-all` + DMARC `p=reject` + null MX. Full set, below.
B — Receives mail, never sends (a monitored contact@ on an old domain)	SPF `-all` + DMARC `p=reject`, and keep your real MX. Null MX would refuse your inbound mail by design — skip it.
C — Sends through any service at all (even one newsletter a year)	Not a parked domain. Close this tab's advice and use the normal setup/rollout guides — a `-all` lockdown here would bounce your own mail.

The records (Situation A; B skips record 3)

Record 1 — TXT at the root (@)

v=spf1 -all

One line that says: no server is authorised to send for this domain — anything claiming otherwise is forged. This is Microsoft's documented parked-domain SPF, verbatim. If the domain somehow has an existing SPF record from a forgotten experiment, replace it with this; one record only.

Record 2 — TXT at _dmarc

v=DMARC1; p=reject;

No ladder, no monitoring phase — there is no legitimate mail to protect, so the rollout logic of our main-domain guide does not apply. Receivers are told to refuse everything. No DKIM records — there is nothing to sign with, and Microsoft's parked configuration includes none. Optional, and recommended: add rua=mailto:dmarc@yourMAINdomain so spoofing attempts report to a mailbox you read (the parked domain can't receive its own reports — if the report address lives on a different domain, add the authorisation record <parked>._report._dmarc.<main> → v=DMARC1 there, per RFC 7489 §7.1). Microsoft considers the report tags optional for parked domains; visibility is why we recommend them.

Record 3 — MX at the root (Situation A only)

Preference 0 · Target: . — a single dot, and it must be the ONLY MX record

The null MX (RFC 7505): a formal “this domain accepts no email.” Senders fail immediately instead of retrying for days or delivering to the web server's address by fallback. RFC's own scope, quoted so nobody over-applies it: null MX is for a domain that “does not send or receive” — which is why Situation B keeps its real MX.

Cover the subdomains

DMARC inheritance works in your favour: policy discovery for a subdomain falls back to the root's policy, so p=reject at the root reaches subdomains that have no records of their own (the sp tag governs subdomains explicitly if you ever need it separate).
Microsoft also documents a wildcard SPF for parked domains (its scenario writes the host in the form _*.yourdomain) — add it if your host supports wildcard TXT, so no subdomain can be given a permissive SPF by accident.
Sweep for dangling records: read the whole DNS zone once. A stale CNAME pointing at a service you cancelled can let an attacker claim that subdomain and send passing mail from it — the “SubdoMailing” campaigns abused exactly this at scale. Delete records for services that no longer exist. The lockdown is the three records plus this sweep.

Prove it worked

Read-backs: a DNS lookup shows exactly v=spf1 -all at the root, v=DMARC1; p=reject; at _dmarc, and (Situation A) a single MX: 0 .
The spoof test: from any external account, send a message forged as the parked domain to a Gmail/Outlook address you control (several free “send as” test tools exist, or a throwaway SMTP sender). Expected, healthy result: rejected or spam-foldered with DMARC fail. If it lands in the inbox cleanly, a record is missing or misread — recheck the read-backs.
Days later: if you added rua, aggregate reports begin documenting who is trying to use your name — intelligence you cannot act on beyond this lockdown, and do not need to: the policy is the action.

Traps specific to this job

Trap	Consequence
Null MX on a Situation-B domain	Inbound mail refused by design — silently, for as long as the record stands. Training material in the wild recommends null MX for receiving domains; that is a misreading of RFC 7505, whose scope is send-nothing and receive-nothing.
“The domain also hosts our website, so we can't touch DNS”	These are TXT/MX records; they do not affect the site's A/CNAME records. The only overlap risk is a careless edit — read back, don't bulk-delete.
Registrar defaults already sitting in the zone	Some registrars pre-place records (GoDaddy's post-April-2025 domains carry a default DMARC pointing reports at GoDaddy — see our GoDaddy guide). A second DMARC record disables DMARC; edit what's there, don't stack.
Assuming the lockdown covers a delegated subdomain	Policy discovery checks the subdomain first; a subdomain on its own nameservers is its own kingdom. Inventory delegations (NS records) in the sweep.

FAQ

DMARC's spec was updated (RFC 9989). Do the records change?

No — the record set above is identical under the current specification. What the update refined is subdomain policy vocabulary (an np tag for non-existent subdomains); the fallback chain still lands on your root's p=reject, so nothing extra is required here.

Should I do this for typo variants and old domains too?

Yes — every domain you own that doesn't send is the same open door, and attackers shop for exactly the forgotten ones. The whole portfolio takes an afternoon.

Can I sell/transfer the domain later with these records on?

They're three ordinary DNS records; a buyer's own setup replaces them in minutes. Nothing here encumbers the domain.

Sources

Microsoft Learn — SPF scenarios (“Parked domains”: v=spf1 -all, wildcard form) and DMARC configuration (parked-domain p=reject, no DKIM) · RFC 7505 — A “Null MX” No Service Resource Record (§3 form, §4.2 scope) · RFC 7489 §7.1 (external report authorisation) and the current DMARC specification RFC 9989 (subdomain policy fallback) · Yahoo Sender Hub via this site's earlier verified research (spoofed mail counts toward the claimed domain's enforcement review) · Guardio's SubdoMailing research (dangling-record abuse), labelled as the case study it is.

Verification note: the record values and the null-MX form were confirmed against Microsoft Learn and RFC 7505 on 20 October 2026. Whether every registrar's panel accepts “.” as an MX target is panel-specific; if yours refuses it, the SPF+DMARC pair alone still delivers the anti-spoofing protection — say so in our feedback below and we'll document the workaround per host.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.