DMARC for Parked Domains (You Still Need It)

Most DMARC guides assume you're sending mail. But every domain you own — including parked domains, brand-protection domains, project subdomains, and your spouse's vanity domain — needs DMARC protection too. Without it, those domains become the easiest spoofing targets in your portfolio.

This guide covers the defensive DMARC pattern for no-mail and parked domains: what to publish, why each tag is set the way it is, and how to know if anyone is spoofing you.

Why parked and no-mail domains need DMARC

A domain that doesn't send mail has no SPF, no DKIM, and no DMARC by default. To an attacker, that's a green light. They can send phishing emails with From: [email protected] and the receiver has no way to verify anything. The mail will land in inboxes or quarantine based on content heuristics alone.

Once you publish DMARC p=reject plus a null SPF, that same attempt produces a hard fail at the receiver gateway. Gmail, Yahoo, Microsoft, and most enterprise mail systems will reject the message outright.

This is one of those infrastructure tasks where a 10-minute DNS change prevents an entire class of attacks. There's no reason not to do it.

The defensive DMARC record

The minimum effective configuration:

; SPF — no one is authorized to send
yourdomain.com.            TXT  "v=spf1 -all"

; DKIM — declare empty policy
*._domainkey.yourdomain.com.  TXT  "v=DKIM1; p="

; DMARC — reject everything
_dmarc.yourdomain.com.     TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

What each piece does:

• SPF -all: hard-fail any IP claiming to send for this domain
• DKIM wildcard with empty p=: declare that no DKIM keys are valid
• DMARC p=reject; sp=reject: reject both the primary domain and subdomains
• rua=mailto:: send aggregate reports to a monitored mailbox on a different domain

Use a rua mailbox on a domain you actively monitor — not the parked domain itself. You'll get daily reports listing every spoofing attempt.

What MTA-STS adds (for the truly thorough)

For brand-protection-grade defense, also publish an MTA-STS policy that requires TLS for any mail to the domain (even though you shouldn't be receiving any):

_mta-sts.yourdomain.com.   TXT  "v=STSv1; id=20260516000000"

With a hosted policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. See the MTA-STS setup guide for the full workflow.

Practitioner note: I tell every client to inventory all the domains they own (current registrations + expired typos still resolving + legacy product domains) and publish defensive DMARC on every single one. The exercise usually surfaces 5-30 forgotten domains and at least one that's been spoofed for years.

What aggregate reports show on no-mail domains

Once DMARC reporting is in place, expect:

• Most days: empty or near-empty reports. Nothing is legitimately sending, and most attackers don't bother spoofing high-value-looking parked domains.
• Occasional spoof attempts. A few hundred to a few thousand fails per day from random IPs. The reject policy is doing its job.
• Active phishing campaigns. If your brand becomes a target, you'll see large spikes — often 10,000+ messages in a day from a single botnet IP range. Document and forward to your CISO and any abuse desks.

For reading the actual XML reports, see reading DMARC aggregate reports.

Setting the rua mailbox correctly

The rua= mailbox should:

1. Live on a domain you monitor — not the parked domain
2. Be a real mailbox or DMARC processing service inbox
3. Not be a personal mailbox (reports can be high volume during attacks)
4. Use a parser (dmarcian, Postmark DMARC, EasyDMARC) to convert XML to readable dashboards

If the rua mailbox is on a different domain than the DMARC record, you also need a small authorization record on the rua domain:

yourparkeddomain.com._report._dmarc.yourrealdomain.com.  TXT  "v=DMARC1"

This tells the receiver that yourrealdomain.com is authorized to receive reports for yourparkeddomain.com. Without it, RFC-compliant receivers will refuse to send reports cross-domain.

Subdomain protection: don't forget sp=

The sp= tag sets policy for subdomains. If absent, subdomains inherit the primary domain's p= value. For parked domains, explicitly set sp=reject so subdomains like mail.yourparkeddomain.com or secure.yourparkeddomain.com (favorites of phishers) are also locked down.

Practitioner note: Half the phishing attempts I've seen against client domains targeted invented subdomains (secure-login.brandname.com, account.brandname.com). If your DMARC doesn't explicitly cover subdomains with sp=reject, that loophole is open.

When to relax this for "no-mail" domains

You might think a domain doesn't send mail when it actually does. Common surprise sources:

• Marketing automation tools using vanity sending domains
• HR or recruiting platforms
• Survey or feedback tools
• Old CRM integrations
• Customer-success outreach platforms

If you publish p=reject and then notice rejection messages from legitimate vendors, walk back to p=none for 30 days, identify what's sending, decide whether to authorize it, and try again. See the DMARC none to reject guide for the staged rollout.

If you have a portfolio of brand-protection or legacy domains that need defensive DMARC, book a consultation. I do DMARC rollouts including parked-domain protection, subdomain audit, and centralized aggregate report monitoring.

Sources

• RFC 7489 — DMARC — IETF
• Postmark DMARC guide — Postmark
• dmarcian: Yahoo and Google require DMARC — dmarcian
• Cloudflare DMARC record reference — Cloudflare
• M3AAWG DMARC deployment guide — M3AAWG

---

v1.0 · May 2026