How to protect parked and non-sending domains from spoofing

Most businesses own more domains than they use: old brand names, typo variants, country versions and defensive registrations. If those domains have no email records at all, attackers can send mail "from" them and receivers have nothing to check against. A few DNS records turn each one into a domain that receivers can reject outright.

Why do parked domains get spoofed?

Anyone can put any domain in the From line of an email. CISA's guidance on BOD 18-01 says it directly: "Even if you do not send mail from your domain, anyone can spoof it to give the appearance that mail is coming from you."

Parked domains are attractive because:

• They look official. yourbrand.net or an old company name is convincing in an invoice scam.
• Nobody watches them. There are no reports, no users and no complaints.
• Receivers have nothing to check. With no SPF and no DMARC, a forged message isn't "failing" anything.

M3AAWG adds that domains similar to well-known domains are especially vulnerable. The fix is to publish records that say "this domain sends no mail and receives no mail", so receivers can reject forgeries. For domains that do send mail, see how to stop spoofing of your domain.

Which DNS records does a parked domain need?

The core records come from M3AAWG, the UK NCSC and Microsoft's own guidance. All three recommend the SPF and DMARC records; M3AAWG and the NCSC add the Null MX:

Null MX

A Null MX (RFC 7505) is a single MX record with priority 0 and a target of .. It tells senders that the domain accepts no mail, so delivery fails immediately instead of being retried for days. RFC 7505 says a domain with a Null MX must not publish any other MX record. It also gives receivers a reason code: mail from a sender domain with a Null MX can be rejected with 550 5.7.27, "Sender address has null MX".

M3AAWG explains why it matters even for web-only domains. Some receivers check that a sender's domain can receive replies, and a domain with an A record would otherwise look like it could. You can read more in what is an MX record.

SPF -all

v=spf1 -all lists no authorized servers and ends with a hard fail. Every message using the domain in its envelope sender fails SPF. Microsoft's SPF guide gives exactly this record for parked domains. For more record patterns, see SPF record syntax and examples.

DMARC p=reject

SPF only checks the envelope sender. DMARC protects the visible From address, which is what people actually see. With v=spf1 -all and no DKIM keys, no message can produce an aligned pass, so every forgery fails DMARC. p=reject asks receivers to refuse those messages. Under RFC 9989, the policy also covers subdomains that don't publish their own record.

The rua reporting address is optional. M3AAWG calls it optional, and Microsoft says reports are arguably not needed, because there should be no legitimate mail to fix. The NCSC includes one. Reports can show you who is abusing the domain. If you add rua, it must point to a mailbox on a domain that receives mail. If that domain differs from the parked one, it has to publish an authorization record such as parked.example._report._dmarc.reports.example.net TXT "v=DMARC1".

DKIM: optional, and guidance differs

This is the one point where the sources disagree:

• M3AAWG (2022) says there's no need to publish any DKIM record for a parked domain, and none should be published. A forged signature fails anyway because no public key exists.
• The UK NCSC suggests a wildcard empty key, *._domainkey.example.com TXT "v=DKIM1; p=". It says this isn't strictly required, but some receivers treat a missing record with extra caution, and it revokes any keys that might be cached. In RFC 6376, an empty p= means the key "has been revoked".
• Microsoft says DKIM CNAME records aren't recommended for parked domains.

Both approaches leave a forged signature failing. Pick one and apply it consistently. If the domain once sent mail, the empty key is a tidy way to retire old selectors.

How do you protect subdomains of a parked domain?

Attackers can also invent subdomains, such as billing.yourbrand.net.

• DMARC already covers them. A DMARC record on the parent applies to subdomains that don't have their own record, including subdomains that don't exist. Microsoft's DMARC guide says the same. Don't publish sp=none or np=none, which would leave a gap. Our guide to DMARC subdomain policy explains sp and np in detail.
• SPF and MX don't inherit. Each name needs its own record. M3AAWG suggests wildcards for both, and Microsoft suggests a wildcard SPF record, if your DNS host supports them:

*.example.com.  TXT  "v=spf1 -all"
*.example.com.  MX   0 .

One catch: a DNS wildcard only answers for names that have no records of their own (RFC 4592). If www.example.com has an A record, the wildcard SPF and MX don't apply to it. Add explicit TXT "v=spf1 -all" and MX 0 . records for every host name you keep, as M3AAWG's examples show.

What if the domain has a website but no email?

The same records apply. Keep the A, AAAA or CNAME records for the website and add the Null MX, SPF and DMARC records alongside them. Also add explicit SPF and Null MX records to host names like www, because wildcards won't cover them.

Contact forms are the usual trap. If the website sends form notifications "from" this domain, it isn't a non-sending domain. Either send those notifications from a domain that has proper SPF, DKIM and DMARC, or set this one up properly as a sending domain.

How do you manage many parked domains?

M3AAWG suggests a CNAME so all parked domains share one DMARC record:

_dmarc.example.com.  CNAME  _dmarc.parked.example.net.
_dmarc.example.org.  CNAME  _dmarc.parked.example.net.
_dmarc.parked.example.net.  TXT  "v=DMARC1; p=reject;"

Change the policy or reporting address once, and every parked domain follows. SPF and MX records still need to be on each domain. To keep track of which domains are parked and which still receive mail, see multi-domain email security.

M3AAWG also recommends putting a reachable contact address in the domain's SOA record, since postmaster@ won't work on a domain with a Null MX.

Parked domain checklist

Work through each domain you own but don't use for email:

1. Confirm nothing sends as it. Ask around: old newsletters, web forms, printers, billing systems. CISA strongly encourages publishing p=none with an rua address for a short period first and reading the reports.
2. Remove old MX records, then add MX 0 ..
3. Replace any SPF record with v=spf1 -all. Make sure there's only one SPF record.
4. Publish DMARC at _dmarc: v=DMARC1; p=reject;, with rua if you want reports.
5. Decide on DKIM. Either publish nothing, or add *._domainkey TXT "v=DKIM1; p=". Remove any old DKIM CNAMEs pointing at a mail provider.
6. Cover subdomains. Add wildcard TXT "v=spf1 -all" and MX 0 ., plus explicit records on any host names that exist.
7. Don't forget platform domains. Microsoft says to add a DMARC reject record to your *.onmicrosoft.com domain if you don't send mail from it.
8. Verify. Run the domain through the Email Health Check, which recognizes a Null MX domain and shows its SPF and DMARC results. Use MX Lookup to confirm only the Null MX remains.
9. Re-check after any registrar or DNS hosting change. Make sure every record came across.

If you need help building the records, the SPF Generator and DMARC Generator produce the exact strings.

Common mistakes

These records stop direct forgery of your parked domains. They don't stop attackers registering new lookalike domains, which is covered in lookalike domain phishing.

Next steps

1. List every domain your organization owns, including old and defensive registrations.
2. Apply the checklist to each non-sending domain.
3. Check each one with the Email Health Check.
4. Watch for changes. iBlockSpam's domain monitoring alerts you when MX, SPF or DMARC records change on domains you protect with us.

Browse our other SPF, DKIM and DMARC guides.