Skip to content
DMARC
← Blog

Protecting a parked or no-email domain (p=reject)

By Thomas · virtual CISO · August 14, 2026

Almost every organisation owns more domains than it uses to send mail. Secondary brands left fallow, typo-protection domains bought "just in case", names inherited from an acquisition, defensive variants (.net, .co, the hyphen-less spelling): most carry a constellation of dormant domains. And that is precisely where the danger hides. An attacker knows that a domain nobody uses is also a domain nobody watches — an ideal launchpad for sending phishing in a company's name without ever tripping an alert. The good news: locking down a parked domain is simpler, faster and safer than securing an active one. Three DNS records are enough, and the strictest policy can go live from day one, with no gradual ramp-up at all.

Why a no-email domain is still a target

The most widespread misconception is that a domain which doesn't send email has nothing to protect. That's wrong, and the confusion comes from conflating sending with being spoofable. The From: field of an email is free text: anyone can write billing@forgotten-brand.example into a message header, whether or not that domain has a mail server. The absence of an MX record protects nothing — it only says the domain doesn't receive mail, not that no one can claim to send from it.

With no SPF and no DMARC published, a dormant domain is effectively wide open. An attacker can dispatch thousands of messages spoofing it, and since no policy tells recipients what to do with them, a share will land. The mechanics of the threat are laid out in email spoofing explained: the principle is the same for a parked domain, with one detail that makes everything worse. Nobody reads the complaints. On an active domain, a spoofing spike eventually surfaces — a customer worries, support gets feedback, a reply inbox overflows. On a domain the organisation has forgotten, the campaign can run for months without anyone noticing. Silence is not protection; it's a window of opportunity.

Typo-protection domains deserve a special mention. They get bought precisely because they resemble the main domain — one missing letter, an extra hyphen, a neighbouring extension. That is exactly what makes them credible phishing vehicles: the victim reads fast, recognises a familiar name and clicks. A defensive domain left without a DMARC policy defends nothing at all; it hands the attacker a near-perfect name and the freedom to spoof it.

The three records that shut the door

The fix comes down to three DNS records, plus a bonus. The goal is to tell the whole world, as categorically as possible: this domain sends no legitimate email, so reject anything that claims to come from it. Here is the logic behind each.

1. An SPF that authorises no one

SPF declares which servers are allowed to send for a domain. For a domain that sends nothing, the answer is simple: none. The record reduces to its strictest form.

forgotten-brand.example.  TXT  "v=spf1 -all"

The trailing -all means "reject (hardfail) any sender not listed" — and since nothing is listed before it, that covers literally everyone. It's the most categorical SPF mechanism; its exact meaning and the nuances between -all, ~all and ?all are dissected in SPF mechanisms and the meaning of -all. Here there's no room for hesitation: a parked domain has no reason to use a softfail. The hardfail is the right call, and it applies from the first minute.

2. A DMARC at immediate p=reject

This is the heart of the lockdown, and it's also where the parked domain reveals its decisive advantage. On an active domain, p=reject never goes up overnight: the reports come first, then the identification of every legitimate source (the CRM, the marketing tool, billing, the helpdesk), a check that they all align, then a tightening in stages. Skipping that step would reject legitimate mail — an operational disaster. That whole ramp-up choreography is described in getting to p=reject without breaking legitimate email.

On a domain that sends nothing, that risk does not exist. There is no legitimate traffic to break, so no reason to wait. The maximum policy goes up directly.

_dmarc.forgotten-brand.example.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@primary-domain.example"

Two details matter. First, the immediate p=reject: it's legitimate, safe and recommended precisely because the domain is dormant. It's one of the rare cases in DMARC where gradual caution is pointless — distinguishing it from an active domain matters, because applying the same timidity here would only delay protection for no benefit. Second, the rua tag: even an unused domain deserves a watchful eye. We come back to that right after.

3. A revoked DKIM: the empty public key

SPF and DMARC cover the essentials, but one extra signal reinforces the posture: publishing a DKIM record that explicitly declares no signing key is valid for this domain. The convention is a wildcard record with an empty public key.

*._domainkey.forgotten-brand.example.  TXT  "v=DKIM1; p="

The value-less p= means "empty public key", that is "this key is revoked / no valid key here". The wildcard *._domainkey makes that verdict apply to any selector an attacker might try to invoke. In plain terms, the domain doesn't merely refrain from publishing a DKIM key: it publishes the active assertion that none is valid. That's the difference between an unlocked door and a bricked-up one.

Bonus: the null MX

Finally, a domain that doesn't receive email either — which is the case for most parked domains — should signal it with a "null" MX record, defined by RFC 7505.

forgotten-brand.example.  MX  0 .

The . as the target, with priority 0, explicitly says "this domain accepts no mail". It's not strictly an anti-spoofing measure, but it completes the picture: sending servers stop trying to deliver messages to the domain (including the bounces of a spoofing campaign), which cuts needless noise. It's the hygiene gesture that finishes telling the world: there's no email here, inbound or outbound.

Why keep rua monitoring on an unused domain

At first glance, setting a rua address on a dormant domain seems superfluous — it sends nothing, so what would it report? Precisely the opposite of what intuition suggests. The aggregate reports of a parked domain don't surface legitimate traffic (there is none): they surface spoofing attempts. Every line of a RUA report on such a domain is, by definition, an IP address that tried to send in the brand's name and got rejected. It's pure intelligence on the attacks aimed at that brand.

Concretely, the rua points at an inbox someone already reads — typically the primary domain's collection address, to centralise everything in one place. The day that address starts receiving an abnormal volume of reports for a typo-protection domain, the signal is strong: someone is running an active impersonation campaign. Without rua, that rejection would still happen — but in silence, and the targeting would go entirely unnoticed. Collecting the reports turns a passive lock into an alarm system. The detailed setup of that address is covered in the general introduction to the standard, which lays the foundations of the whole mechanism.

A word on load: a properly locked parked domain generates few reports in normal times, precisely because there's no traffic. The volume only rises when spoofing begins — which makes the spike all the more legible. A hundred dormant domains don't call for a sophisticated dashboard; they call for all of them shouting to the same place the day one of them is attacked.

The case of inactive subdomains

The parked-domain reasoning also applies, one level down, to the subdomains nobody uses. A main domain may be active and well protected, but what about vpn.example.com, old-crm.example.com, or a subdomain that never existed at all? Attackers love to forge addresses on plausible subdomains precisely because they often escape the root domain's policy.

Two DMARC tags cover this ground. The sp tag sets the policy for existing but not explicitly configured subdomains — how it works is detailed in the rule that governs subdomains. The newer np tag sets the policy for non-existent subdomains — those no DNS record defines, and which are spoofable all the same. Setting np=reject shuts that entire category with a single gesture, with zero risk to legitimate mail, exactly like the p=reject of a parked domain. The subject has its own article: the np tag to lock down non-existent subdomains. On an organisation's root domain, a complete policy therefore looks like this.

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

This p + sp + np at reject locks the domain, its active subdomains and its phantom subdomains in one move. For a parked domain that has no legitimate subdomain anyway, the same logic applies out of an abundance of caution: nothing sends, so everything gets rejected.

The recap: a parked domain locked down in full

Here are all four records lined up for a typical dormant domain, say my-secondary-brand.com, which neither sends nor receives email.

my-secondary-brand.com.             TXT  "v=spf1 -all"
_dmarc.my-secondary-brand.com.      TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@primary-domain.example"
*._domainkey.my-secondary-brand.com. TXT  "v=DKIM1; p="
my-secondary-brand.com.             MX   0 .

Four lines, and the domain goes from "wide open" to "bricked up and watched". SPF says no server may send; DMARC orders the rejection of anything that claims otherwise and repatriates the attempts; DKIM asserts that no signature is valid; the null MX closes reception. There's nothing to maintain day to day: no source to align, no ramp to steer. It's a "set and forget" operation, except that the rua inbox raises the alarm if the domain suddenly becomes interesting to an attacker. Those four lines are worth only as much as the zone that carries them, though: an attacker able to slip forged records into it bypasses the whole set without ever having to break it, and it is DNSSEC signing of the zone that closes this last door.

The mistake to avoid: treating a parked domain like an active one

The only real trap is misplaced timidity. Some teams, out of reflex, apply the same caution to their dormant domains as to their production domain: they set p=none, promise themselves to "observe first", and leave the domain in observation-only mode for months. That's a reasoning error. p=none on an active domain is a legitimate precautionary step while the sources get identified; p=none on a parked domain protects strictly nothing, since there is no source to discover. It documents the spoofing instead of blocking it, for no benefit whatsoever.

The distinction is fundamental, and worth internalising: gradual ramp-up exists solely to avoid breaking legitimate traffic. Where there is no legitimate traffic, there is no reason to ramp up gradually. A parked domain deserves p=reject from the first minute, full stop. Grasping this principle also clarifies why an active domain, for its part, deserves patience — the two cases are two sides of the same alignment logic, which the foundation of mail protection and the DMARC pillar place in context.

One last nuance on the domains slated for activation someday. A secondary brand that's dormant today but meant to send mail in six months still gets locked down at p=reject now. Activation day then follows the normal go-live procedure — SPF published with the real servers, DKIM enabled with a real key, then the ramp steered as usual. Nothing stops a bricked-up door from being reopened; a door left gaping "because we might use it", on the other hand, is a standing invitation. Locked by default, opened on demand.

Checking dormant domains before an attacker finds them

The first reflex is free and takes seconds. Each domain — active and dormant alike — can go through our free DMARC analyzer, which shows at a glance which are already locked and which remain wide open. The count of defensive domains carrying, today, no policy at all is usually a surprise. To place an overall posture against a whole sector, the DMARC Observatory shows just how much secondary-domain spoofing remains a widespread blind spot.

Mapping every domain, distinguishing the active from the dormant, generating the right DNS for each, and monitoring the spoofing reports that come back from both: that is exactly what Thomas, the virtual CISO, automates. He names every source on the active domains, proposes the full lock on the parked ones, and raises the alarm when one of them suddenly becomes a target. Analyze a domain for free · explore the Observatory · get started with Thomas.

Related guides

About the author

Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.