A domain that never sends mail should still be locked down, because attackers spoof silent domains precisely because nobody is watching them. For a parked or non-sending domain you can skip the usual slow DMARC rollout and go straight to p=reject on day one, since there is no legitimate mail to break. The full lockdown is four records: an SPF record that authorizes nothing, an empty DKIM key that revokes all selectors, a null MX that refuses inbound mail, and a DMARC record set to reject.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Unlike a live sending domain, where moving to reject too fast can bounce real invoices and password resets, a non-sending domain has zero deliverability risk. Every message that claims to be from it is forged by definition. That makes the aggressive policy not just safe but correct from the first minute.
Why parked domains get spoofed in the first place
Spammers and phishers scan for domains with no DMARC policy because those domains fail open. If your domain has a real registration, a clean reputation, and no published authentication policy, a receiver has no instruction to reject a forged message. The forged mail often lands in inboxes and inherits whatever trust the domain name carries.
Non-sending domains are especially attractive. Think of brand-defensive registrations, old product names, typo variants of your main domain, and internal-only domains. Nobody sends real mail from them, so nobody notices when someone else does. There is no bounce feedback, no help-desk ticket, and no reputation hit that you would see on a domain you actively use. The abuse can run for months.
The fix is to publish an explicit, restrictive policy. When every authentication mechanism says "this domain sends nothing, reject anything that claims otherwise," receivers enforce that on your behalf. This is the cheapest anti-spoofing control you can deploy, and it is covered in more depth in how to stop email spoofing of your domain.
The copy-paste lockdown record set
Here is the complete set for a domain called example.com that will never send or receive mail. Publish all four.
1. SPF that authorizes no senders
example.com. TXT "v=spf1 -all"
The -all mechanism with nothing before it is a hard fail for every source. It says no IP address is ever a legitimate sender for this domain. This is the opposite of the dangerous +all, which authorizes the whole internet. If you want the reasoning behind why +all is a security hole, see why +all in SPF is dangerous. For a parked domain, -all alone is the only correct SPF value.
2. DKIM key that revokes all selectors
Publish a wildcard-style empty public key so any DKIM signature that references this domain fails to verify:
*._domainkey.example.com. TXT "v=DKIM1; p="
An empty p= value is the RFC 6376 way to signal that the key has been revoked. Any signature claiming a selector under this domain cannot validate against an empty public key, so DKIM fails. The wildcard covers every selector name an attacker might invent.
3. Null MX that refuses inbound mail
example.com. MX 0 .
The null MX record, defined in RFC 7505, is a single MX with priority 0 and a target of . (the root, meaning "no host"). It tells sending servers that this domain accepts no mail, so bounces and misdirected replies are rejected at the SMTP layer instead of queuing. It also removes the domain as a useful backscatter target.
4. DMARC straight to reject
_dmarc.example.com. TXT "v=DMARC1; p=reject; adkim=s; aspf=s"
This is the record that does the heavy lifting. p=reject tells receivers to reject any message that fails DMARC, and for a non-sending domain that is every message. The strict alignment tags adkim=s and aspf=s tighten the match, though they are belt-and-suspenders here since nothing should ever pass anyway.
Notice what is missing: there is no rua or ruf reporting address and no pct tag. On a live domain you would collect aggregate reports and roll the policy up gradually, a process covered in how to move DMARC from none to reject. On a parked domain there is no legitimate traffic to learn from, so p=none monitoring adds nothing but delay. If you do want visibility into who is trying to spoof the domain, you can add a rua address, but the policy should still start at reject. For the full meaning of each policy level, see DMARC policy: none vs quarantine vs reject.
Cover the subdomains too
DMARC has a subdomain policy tag, sp, that governs mail claiming to be from subdomains of your domain. If you omit it, subdomains inherit the p value. For a parked domain you want to be explicit so a forged login.example.com is rejected as firmly as the bare domain:
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
Setting sp=reject closes the door on attackers who try to spoof a made-up subdomain to slip past a policy that only names the organizational domain. This matters because a parked domain has no defined subdomains to protect legitimately, so blanket rejection is safe.
Manage dozens of parked domains from one record
If you hold ten or a hundred defensive registrations, editing four records on each one is tedious and drifts out of sync. Use CNAME delegation to point every parked domain at a single master record you control. Pick one domain as the source of truth, for example lockdown.example.com, and publish the real DMARC there:
_dmarc.lockdown.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
Then on each parked domain, publish a CNAME instead of a TXT:
_dmarc.parked-brand-a.com. CNAME _dmarc.lockdown.example.com.
Now every parked domain resolves its DMARC policy from the one central record. Change the master and they all change at once. The same pattern works for DKIM, where CNAME delegation is already the standard approach many providers use. If you want the mechanics of CNAME versus TXT for DKIM, see DKIM CNAME vs TXT record.
Two caveats. First, SPF cannot be delegated with a CNAME at the domain apex in the same clean way, because SPF is looked up on the domain itself and apex CNAMEs conflict with other apex records like the null MX. Keep v=spf1 -all published directly as a TXT on each domain, since it is a single static line that never changes. Second, DMARC CNAME targets must resolve to a valid DMARC TXT record, so keep the master record healthy.
Confirm the lockdown with a free checker
Publishing the records is only half the job. DNS typos, a stray extra SPF record, or a provider that rewrites your MX can quietly break the policy. Run the domain through the scanner and confirm four things: SPF reads exactly v=spf1 -all, DMARC shows p=reject, the MX is the null MX, and no unexpected DKIM key is publishing a real value. A clean parked domain should grade well precisely because it authorizes nothing.
If you are locking down a domain because it has already been abused, also check whether its name is on any blocklists using how to check if a domain is blacklisted, since a spoofed domain can pick up listings from the forged campaigns sent in its name.
Frequently asked questions
Can I really start at p=reject without a monitoring phase?
Yes, for a domain that genuinely sends no mail. The slow rollout from p=none exists to protect legitimate mail streams you might not know about. A parked domain has none, so there is nothing to break and no reason to wait. If you are unsure whether the domain sends anything, run a short p=none with a rua address first, then switch to reject.
Do I need SPF, DKIM, and DMARC all three on a parked domain?
Publish all of them. DMARC is the enforcement layer, but it evaluates SPF and DKIM results. The v=spf1 -all and empty DKIM key make sure both underlying checks fail cleanly, so there is no path for a forged message to pass alignment. The null MX is a separate control that refuses inbound mail. Together they leave no gap.
Why publish a null MX if the domain sends no mail?
Sending and receiving are different. Even a domain that never sends can be probed for inbound mail, used for backscatter, or targeted by servers bouncing forged messages back to it. The null MX from RFC 7505 tells the world the domain accepts no mail, which stops those queues at the source. It also signals clearly that the domain is intentionally dark.
What if I later want the domain to send email?
Remove the lockdown records and build real ones. You would replace v=spf1 -all with an SPF record listing your actual sending sources, publish a genuine DKIM key for your provider, set a normal MX if you want inbound mail, and roll DMARC to reject through monitoring. Start with what DNS records do I need for email and how to set up SPF.