DMARC for parked domains: reject policy, SPF, and DKIM without guesswork

dmarc

If a domain does not send email, that domain should still have an email authentication posture.

That sounds odd at first, but parked or unused domains are frequent spoofing targets precisely because nobody watches their mail flow. Attackers can forge From: yourbrand@example.com from a quiet domain and hope recipients trust the name.

The clean baseline is simple:

  • DMARC at enforcement (p=reject)
  • SPF that authorizes nobody
  • No active DKIM signing setup for that domain

Yes, it is intentionally strict.

The record set that works in practice

For a parked domain such as example.com, publish:

_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"
example.com TXT "v=spf1 -all"

That is enough for a strong "this domain does not send" signal.

A few notes worth keeping in plain language:

  • p=reject tells receivers to reject DMARC-failing messages for the exact domain.
  • sp=reject extends the same posture to subdomains unless they publish their own DMARC record.
  • v=spf1 -all means no host is authorized to send mail for that domain.
  • Strict alignment (adkim=s; aspf=s) is a good fit here because there is no legitimate sender to accommodate.

If adkim and aspf feel rusty, the alignment refresher in DMARC identifier alignment deep dive helps quickly.

Why SPF and DMARC both matter for parked domains

Sometimes teams ask: if DMARC is already reject, why bother with SPF?

Because different systems evaluate and score messages differently. DMARC is the policy anchor, but SPF still feeds local filtering decisions, abuse tooling, and operational diagnostics. A hard SPF deny (-all) reduces ambiguity and makes triage easier.

No need to overthink DKIM here. For a truly parked domain, there should be no legitimate signer, so there is nothing to configure. If a DKIM signature appears in DMARC aggregate reports for that domain, that is usually a signal to investigate, not something to "make pass."

The one mistake that causes surprise outages

A domain is called parked, then six months later someone uses it for a scanner, ticketing tool, or "just one" legacy notification stream.

With p=reject, those messages will fail unless SPF/DKIM and alignment are designed intentionally.

So before enforcing, do a quick reality check:

  1. Search recent DMARC aggregate data for any legitimate-looking sources.
  2. Confirm with internal teams that no app sends as example.com.
  3. If any sender exists, either move it to a dedicated subdomain or treat the domain as active and configure it properly.

Using dedicated subdomains (alerts.example.com, billing.example.com) keeps the apex parked and strict. If that pattern is new, DMARC subdomain policy best practices is the right next read.

Recommended DNS patterns

Parked apex domain:

_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
example.com TXT "v=spf1 -all"

Active sender moved to a subdomain:

_dmarc.news.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
news.example.com TXT "v=spf1 include:_spf.example.net -all"

This split is operationally calm: locked down where nothing should send, flexible where mail actually exists.

Provider docs worth bookmarking

When explaining this posture internally, official provider references help avoid debates:

A practical default to keep

For any domain that does not send mail today, and is not expected to send soon, the safest default is:

  • DMARC: p=reject; sp=reject
  • SPF: v=spf1 -all
  • No DKIM signing setup

Then revisit only if business requirements change.

That approach prevents most parked-domain spoofing attempts before they become incident tickets.

Previous Post