Protecting parked domains from spoofing

Why spoofers love parked domains

Most companies own more domains than they send from: the .net twin of your .com, old product names, defensive registrations, the domain from a project that never launched. They sit parked - no website, no mailboxes, no outbound mail.

To a spoofer, that's the perfect disguise. A parked domain usually has no SPF record, no DKIM keys, and no DMARC policy, which means a receiving mail server has nothing to check a forged message against. Mail claiming to come from your parked domain gets evaluated on content alone, and a clean domain with your brand in it lends the phish real credibility.

The fix is unusually satisfying: because the domain sends nothing, there is no legitimate mail to protect, so you can jump straight to the strictest possible policy with zero risk of breaking anything. No monitoring period, no ramp.

The three records

Publish these three DNS records on every domain that sends no mail. All three go at the domain root (the third under _dmarc).

1. SPF: no server may send

A TXT record on the domain itself:

v=spf1 -all

This is the entire record. It lists no permitted servers and ends with a hard fail, which tells receivers "no machine on the internet is authorized to send mail for this domain." On a sending domain -all deserves care; on a parked domain it's exactly right.

2. DMARC: reject everything that fails

A TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:reports@yourprovider.com

With no legitimate senders, every message claiming this domain fails DMARC by definition - so p=reject tells receivers to refuse all of it outright. Subdomains inherit the same policy automatically (you don't need sp= or np= here), so anything.yourdomain.com is covered too.

Keep the rua= reporting address even though the domain sends nothing. The aggregate reports are how you see the spoofing attempts your policy is blocking - and how you'd notice if someone inside the company quietly started sending real mail from the domain.

3. Null MX: this domain doesn't receive either

An MX record with priority 0 pointing at the root:

MX 0 .

The null MX (RFC 7505) is the receiving-side counterpart: it tells sending servers the domain accepts no mail, so their delivery attempts fail fast instead of retrying for days. Skip this one if the parked domain does receive mail (forwarding, catch-all) - it only belongs on domains with no mailboxes at all.

What about DKIM? Nothing to do. DKIM keys only matter for mail you actually send, and publishing keys for a domain that sends nothing would just be one more credential to manage.

Keep watching the reports

A parked domain at p=reject isn't quite done - it's done when someone is reading its reports. The aggregate reports keep flowing after enforcement, and on a parked domain they tell a beautifully simple story: every line is a blocked spoof attempt. There's no legitimate traffic to separate out.

That's exactly how trustyourinbox treats these domains. A domain with no legitimate senders shows as monitor-only: instead of an alignment percentage (meaningless with no real mail), you see your protection posture and the volume of spoofed mail your policy is turning away. If real mail ever does start flowing from the domain - a new tool someone wired up without telling you - it shows up in the reports before it becomes a deliverability mystery.

Do the whole portfolio

This treatment is cheap enough to apply everywhere: every defensive registration, every dormant brand, every domain you bought and never used. Three records per domain, once, and none of them ever needs a ramp-up period or a second thought. If a parked domain later comes back to life as a sending domain, you replace the SPF record and walk the normal DMARC setup path - the reports you kept flowing will already tell you it's sending.