Part of the security audit tool stack. See the pillar post for the full catalog of sibling audits.
Most advice about SPF, DKIM, and DMARC assumes you send email. Set up your sender, publish the right records, watch the reports, tighten the policy. But a lot of domains never send a single message. The landing page for a book. A redirect domain you bought to protect a brand name. A project that lives entirely on a web app. A client site whose email runs on a completely different domain. These are parked domains, and the usual guidance quietly skips them.
That's a problem, because a parked domain is the easiest domain in your portfolio to spoof. There's no mail to break, no deliverability to protect, and almost always no policy telling the world "nothing legitimate ever comes from here." An attacker can send phishing and invoice-fraud mail with your domain in the From line, and nothing stops it. I recently went through about forty of my own non-sending domains and found every single one of them wide open this way. Two DNS records each closed the hole.
Why "I don't send email" is not protection
When a receiving mail server gets a message claiming to be from yourparkeddomain.com, it looks for two things: an SPF record (which IPs are allowed to send) and a DMARC record (what to do when checks fail). If neither exists, the server has no instructions. Most will deliver the message anyway, because the safe default for the open internet is "don't break mail you can't evaluate." So the absence of records is not neutral. It's an open invitation.
This is exactly the surface behind business email compromise. The FBI's Internet Crime Complaint Center put BEC losses in the U.S. at over $2.9 billion in 2023, and the cheapest version of the attack is simply forging a domain that published no policy. Your parked domains are perfect raw material: they carry a name people recognize, and they say nothing about who's allowed to use them.
The lockdown: two records, no DKIM, no ramp
For a domain that genuinely sends no mail, the correct configuration is the strictest possible one, and you can publish it immediately:
SPF (TXT record at the apex):
v=spf1 -all
That says "no server on earth is authorized to send mail as this domain." The -all is a hard fail.
DMARC (TXT record at _dmarc.yourdomain.com):
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s
That tells receivers to reject anything that fails, including on subdomains (sp=reject), with strict alignment.
Two things make this different from the usual sender setup:
- No DKIM. DKIM signs outbound mail. If you send none, there's nothing to sign and no key to publish. A DKIM warning on a parked domain is a false alarm.
- No
p=noneramp. The standard DMARC rollout starts atp=none(monitor only) and tightens over weeks while you confirm you aren't blocking your own legitimate mail. A parked domain has no legitimate mail to block, so you skip the ramp entirely and go straight top=rejecton day one. This is the rare case where "most aggressive setting, immediately" is the safe move.
Optionally add rua=mailto:you@yourrealdomain.com to the DMARC record if you want aggregate reports showing who's been trying to forge the domain. It's not required for protection, and reports to an address on a different domain may need a small authorization record on the receiving side, so treat it as a nice-to-have.
This guidance lines up with what the major mailbox-operator group M3AAWG and U.S. CISA both recommend for non-sending and parked domains: publish a restrictive SPF and an enforcing DMARC so the names can't be abused.
How to find your parked domains
The signal is simple: a parked domain has no MX record. No MX means it can't receive email, which in practice means it isn't running mail at all. Combine that with "no DKIM selectors" and "no SPF that authorizes a sender," and you've found a non-sending domain that should be locked.
Run any domain through the DNS / Email Auth Audit and it now detects this case directly. When a domain has no MX, no DKIM, and no sending SPF, the tool stops giving sender advice and instead tells you to publish the two lockdown records, flags a dedicated "Parked / non-sending domain" finding, and scores the result on a spoofing-resistance basis where DKIM and MTA-STS are correctly marked not-applicable. A properly locked parked domain reads as a strong result instead of being penalized for missing things it doesn't need.
If you manage a stack of domains, the cheap way to handle this is to check each one's MX record, and for every domain that has none and isn't already locked, publish the two records. It's a few minutes of work per domain and it takes a whole category of impersonation off the table. For the operational side of managing a fleet of small domains like this, I wrote about the systems that make it sustainable in The $20 Dollar Agency.
What this does and doesn't cover
- It stops your parked domain's exact name from being forged in the From line. It does nothing for lookalike domains (
yourbrand-support.com), which are a separate trademark-and-monitoring problem. - If a parked domain ever starts sending mail (you launch a newsletter, wire up contact-form notifications from the domain, add Google Workspace), you must update SPF to authorize the real sender and add DKIM before that
p=rejectstarts bouncing your own messages. Lock it down now; revisit if the domain's role changes. - Receiving (MX) is untouched. This is purely about preventing forgery of a domain that doesn't send.
Related reading
- DNS + Email Auth Audit and its deep-dive — now parked-domain aware
- Seven Security Layers In One Scan: Mega Security Analyzer — generates these records for you
- Email infrastructure for small business — the sending-domain side of the same coin
- Modern security headers — the HTTP-layer companion
Fact-check notes and sources
- FBI IC3 2023 Internet Crime Report — business email compromise losses exceeded $2.9 billion in the U.S. https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf
- SPF, RFC 7208 — the
-all(hardfail) qualifier. https://www.rfc-editor.org/rfc/rfc7208 - DMARC, RFC 7489 —
p=,sp=, and alignment tags. https://www.rfc-editor.org/rfc/rfc7489 - M3AAWG guidance on protecting parked and non-sending domains with restrictive SPF + enforcing DMARC. https://www.m3aawg.org/
- CISA guidance recommending DMARC at enforcement for federal domains, including non-sending. https://www.cisa.gov/
This post is informational, not security-consulting or compliance advice. SPF/DMARC behavior varies by receiver. Only change DNS for domains you control. Test against your own setup before applying broadly.