DMARC for Domains That Never Send Email: Why p=reject Can (and Should) Be Immediate

A domain that never sends email is, paradoxically, one of the easiest domains to spoof — because most people assume "no email" means "no email risk," when it actually means "no legitimate email to compare against, making forgeries harder to distinguish"

The previous articles on this site covered DMARC deployment, XML reports, and alignment. This article addresses domains that don't send email — "parked" domains (registered but not actively used for a website or email), and subdomains that exist for non-email purposes (e.g., a cdn.example.com subdomain serving static assets, never used to send mail) — and why **these specifically benefit from a strict DMARC policy, despite never sending any legitimate email.

The "parked domain" spoofing risk

A domain that's registered, but not actively used (no website, no email) — can still be used as the "From" address in spoofed emails, sent by someone else entirely, from infrastructure the domain owner doesn't control.

Why this is appealing to spammers/phishers: a domain with no established "sending history" has, in one sense, "neutral" reputation — but more importantly, a domain appears legitimate (it's a real, registered domain, potentially with a plausible-sounding name) — recipients seeing an email "from" [email protected] have no easy way to know "this domain never sends email, therefore this is suspicious" — without DMARC, there's no technical signal indicating "email claiming to be from this domain, but not passing SPF/DKIM for this domain, should be rejected."

With no DMARC record at all (or a DMARC record with p=none, the "monitor only" policy covered in the previous deployment article) — spoofed email "from" a parked domain can be delivered, potentially passing through to recipients' inboxes, purely because there's no policy telling receiving systems "reject unauthenticated mail claiming to be from this domain."

The fix: p=reject for domains that never send email

For a domain that genuinely never sends any legitimate email — there's no risk of "breaking legitimate email" by setting p=reject immediately (unlike active, email-sending domains, where the gradual p=none → p=quarantine → p=reject progression, covered in the previous deployment article, is recommended specifically to avoid breaking legitimate mail during the transition).

A minimal DMARC record for a non-sending domain:

v=DMARC1; p=reject; rua=mailto:[email protected]

Combined with SPF and DKIM records that explicitly indicate "no valid senders":

SPF: v=spf1 -all

(an SPF record with no authorized senders, and a hard fail -all — explicitly stating "no IP is authorized to send mail for this domain")

No DKIM record is needed (since no mail is legitimately signed for this domain) — but the absence of any DKIM-signed, aligned mail, combined with v=spf1 -all and p=reject, means: any mail claiming to be "from" this domain will fail both SPF and DKIM alignment (since neither is configured to ever pass) — and, under p=reject, receiving systems are instructed to reject such mail outright.

Subdomains: organizational DMARC policy and subdomain-specific considerations

DMARC policies can apply differently to a domain's subdomains via the sp= (subdomain policy) tag — allowing a different policy for *.example.com (subdomains) than for example.com itself.

Common scenario: example.com itself sends email (with appropriate SPF/DKIM/DMARC configured, per the deployment article) — but various subdomains (cdn.example.com, assets.example.com, staging.example.com, and many others, common in larger organizations) don't send email — yet, without explicit sp= configuration, these subdomains might inherit a less-strict policy (or, depending on DMARC's default-inheritance rules and the parent domain's p= value, might be covered by the parent's policy — but explicit sp= configuration removes ambiguity).

Setting sp=reject (even if the parent domain's p= is less strict, during a gradual deployment) — explicitly protects all subdomains that don't send email — since subdomains, collectively, often represent a larger attack surface (many subdomains, most of which don't send email) than the single primary domain itself, applying a strict sp= policy broadly, while the primary domain's p= policy progresses more gradually (per the deployment article's guidance), addresses a significant portion of overall spoofing risk relatively easily.

BIMI's requirement: DMARC enforcement as a prerequisite

As covered in the previous article on BIMI, BIMI logo display requires — among other things — a DMARC policy of p=quarantine or p=reject (not p=none) — p=none alone, even with otherwise-correct BIMI/SPF/DKIM configuration, does NOT meet BIMI's DMARC-enforcement requirement.

This connects directly to the deployment article's "moving from p=none to p=reject" guidance — organizations pursuing BIMI have a concrete, additional motivation to complete the p=none → p=quarantine/p=reject progression, beyond the general anti-spoofing benefits — p=none represents an incomplete DMARC deployment for BIMI purposes, specifically, regardless of how long it's been at p=none "monitoring" without issues.

How to use the DMARC Lookup on sadiqbd.com

1. For active, email-sending domains: the previous deployment article's gradual progression (p=none → p=quarantine → p=reject) remains the appropriate approach
2. For parked/non-sending domains: p=reject can be applied immediately, combined with v=spf1 -all — there's no "legitimate mail might break" risk to manage, since, by definition, no legitimate mail is being sent
3. For organizations with many subdomains: explicitly configure sp= separately from p= — applying a strict subdomain policy broadly, even while the primary domain's policy progresses more gradually
4. For BIMI-pursuing organizations: verify current p= value is quarantine or reject, not none — p=none blocks BIMI eligibility regardless of other configuration

Frequently Asked Questions

I have dozens of old, unused domains my organization owns (for trademark/defensive purposes). Do I need to configure DMARC for all of them? For domains that are registered but have no email/website use — applying the "non-sending domain" configuration (p=reject + v=spf1 -all) to each is generally recommended precisely because these "forgotten," unused-but-registered domains are attractive spoofing targets (as discussed) — and, being non-sending, configuring p=reject carries no risk of breaking anything — for organizations with many such domains, this configuration is typically simple and uniform across all of them (the same v=spf1 -all and p=reject records, applied to each domain) — making it a relatively low-effort, broadly-applicable security improvement across an organization's full domain portfolio, including domains that might otherwise receive little/no ongoing attention.

Is the DMARC Lookup free? Yes — completely free, no sign-up required.

Try the DMARC Lookup free at sadiqbd.com — check your domain's DMARC policy, including subdomain policy, instantly.