The DMARC subdomain policy: sp and np

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

The np tag: locking down non-existent subdomains

This is DMARCbis's most useful contribution on subdomains. The np tag (non-existent subdomain policy) sets the policy for subdomains that don't exist in DNS — that is, that have no A, AAAA or MX record.

Why does it matter? Because an attacker doesn't need invoice.example.com to exist in order to write it in a From:. They forge the address, send it, and count on the policy not covering that case. With np=reject, the domain declares: "any mail claiming to come from a subdomain that doesn't exist is to be refused."

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

np's big advantage: it's an immediate, risk-free win. No legitimate mail leaves a subdomain that doesn't exist, by definition. So np=reject can be set very early in a rollout, before all the real sources are even aligned — there's nothing to observe, nothing to break. The tag has its own detailed guide: the np tag (non-existent subdomain).

How the receiver picks the right record

To apply sp or np, the receiver must first determine which DMARC record governs a given message, and whether the subdomain exists. Historically, this determination of the organizational domain relied on the Public Suffix List (PSL). DMARCbis replaces it with the DNS Tree Walk: a sequence of DNS queries (eight at most) that climbs the name tree until it finds the applicable DMARC record.

In practice, for a message claiming to come from a.b.example.com, the receiver looks for a DMARC record on that name, then climbs level by level up to the organizational domain, and applies the most specific policy found — distinguishing an existing subdomain (sp or its own record) from a non-existent one (np). The mechanism is explained in detail in the DNS Tree Walk. The Tree Walk itself needs no configuration; all it takes is publishing consistent sp/np.

The attack scenario it blocks

Here is the mechanism made concrete. A bank's root bank.com sits at p=reject, with no np. A fraudster sends a phishing campaign from security.bank.com — a subdomain that doesn't exist. Since it doesn't exist, it has no record of its own; and depending on the implementation, inheritance of p may be applied unevenly to a non-existent name. The message can therefore pass, with a credible sender address that inspires the victim's trust.

With np=reject, that scenario collapses: the receiver sees a non-existent subdomain, applies np, refuses the message. This is exactly the kind of "sideways" spoofing big brands suffer, and that sp/np neutralize for near-zero configuration cost. What makes it so effective for the attacker is trust transfer: a victim who has learned to distrust unknown domains will still trust anything ending in a familiar brand name, and a non-existent subdomain wears that brand just as convincingly as a real one. The topic of heavily targeted brands is developed in DMARC for banks.

Recommended settings

For most domains, the target configuration is simple and symmetric:

• p=reject on the root, once the sources are aligned.
• sp=reject so existing subdomains with no record of their own are protected too.
• np=reject to close non-existent subdomains — to set early, without waiting.

If a legitimate subdomain has special needs (a not-yet-aligned vendor), it deserves its own DMARC record rather than a weakened sp across the whole root. It's more surgical and preserves overall protection.

When a subdomain deserves its own record

Inheritance via sp covers the general case, but some subdomains have a life of their own that warrants a dedicated DMARC record — published directly on _dmarc.the-subdomain.example.com. Three typical situations:

• A distinct, high-volume sending flow. If mail.example.com serves exclusively the marketing platform, giving it its own record allows a separate rua address and tracks that flow independently of the root. Dedicated reports then show at a glance whether that specific source is healthy.
• A different hardening pace. A subdomain whose sources aren't all aligned yet can stay at quarantine while the root moves to reject. Rather than lowering sp for the whole organization, the lag stays isolated on the one subdomain concerned.
• Delegation to a third party. A subsidiary, secondary brand, or vendor running a whole subdomain: handing it its own DMARC record clarifies responsibilities and keeps a mistake on their side from affecting the root policy.

The mental rule is simple: the most specific record wins. A _dmarc on the subdomain always beats sp inherited from the root. That specificity is what handles exceptions locally, without ever weakening overall protection at the organizational-domain level.

The case of parked and mail-less domains

A frequent blind spot: owned domains (or subdomains) that send no email at all — defensive brands, old names, "just in case" registrations. Many organizations leave them without DMARC, thinking a domain that sends nothing risks nothing. It's the opposite: a domain with no DMARC policy is a domain anyone can spoof without resistance. Best practice is the strictest policy from the start — p=reject; sp=reject; np=reject — since, by construction, no legitimate mail leaves them. np takes on its full meaning here: on a parked domain, every subdomain is non-existent, so np=reject shuts down the entire namespace beneath it in one line. Every domain in a portfolio deserves this treatment, not just the ones that send — an unused domain is often the easiest to impersonate precisely because nobody is watching it, and a fraudster only needs one forgotten name to launch a convincing campaign against a brand's customers.

Subdomains have a lifecycle — sp and np follow it

One last thing worth internalizing: the boundary between sp and np isn't fixed. It's evaluated by the receiver at the moment a message arrives, based on what DNS says right then. Spinning up a campaign microsite with a single A record makes that name exist — mail forged in its name is judged under sp, not np. Decommissioning an old service and deleting its DNS records silently drops the name back under np. Two practical consequences. First, sp should stay exactly as strict as np: if sp is laxer, merely publishing a web-only subdomain weakens its mail protection without anyone touching email at all. Second, DNS cleanup belongs in every decommissioning — the deleted record is what hands the name back to the strictest policy.

Common mistakes

• Hardening the root and forgetting subdomains. This is the most common gap after a successful migration: p=reject on the root, nothing on sp/np, and a side door wide open.
• Confusing sp and np. sp covers subdomains that exist; np those that don't exist. Both are needed; one doesn't replace the other.
• Waiting to set np. Since it's risk-free, deferring np=reject only prolongs exposure needlessly.
• Thinking subdomain policy handles alignment. sp and np say what to do with failing mail; they don't make the real subdomain sources aligned — that remains separate work.

In summary

Bringing the root to reject without settling subdomains is locking the front door while leaving the window open. sp protects existing subdomains, np closes non-existent ones — and np is a free win to grab at the very start of a rollout. Together, they remove the "sideways" attack angle that too often survives an otherwise successful DMARC migration.

To confirm that root and subdomains are properly covered — including the non-existent cases — a pass through the free DMARC analyzer shows the effective policy as seen from outside, exactly as a receiver (or an attacker) would discover it — the fastest way to confirm the side door is actually closed.