The DMARC np tag: locking down subdomains that don't exist

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

np vs sp vs p: who covers what

This is the most common confusion. The three tags split the cases:

• p — the policy for the root domain itself (example.com).
• sp — the policy for subdomains that exist (mail.example.com, news.example.com).
• np — the policy for subdomains that don't exist (invoice-thing.example.com).

Before DMARCbis, only p and sp existed. An attacker targeting a non-existent subdomain fell into a gray zone. np removes that gray zone. In practice, a well-run domain often carries all three at the same strict value: p=reject; sp=reject; np=reject.

Why it's a fast, high-priority win

Most DMARC hardening takes work: inventorying the senders, aligning them, watching the reports (see how to get to p=reject). np is the opposite: zero inventory, zero risk, immediate effect. Since no legitimate service sends from a non-existent subdomain, nothing can break. That's why we recommend it early — often as soon as the root domain is healthy, before the whole estate has even finished ramping to p=reject.

This is especially true for organizations with a large subdomain surface — banks, large groups, the public sector — that run dozens of real subdomains and leave just as many imaginable. There, np=reject shuts down an entire category of attacks at once. We cover the financial case in banks.

A few useful clarifications

• np is only interpreted by receivers updated to DMARCbis. During the transition, some will still ignore it — harmlessly, they fall back to the prior behavior. Nothing to lose by publishing it now.
• np does not replace sp. Both are needed: sp for the real subdomains, np for the phantoms. Omitting one leaves half the surface exposed.
• "Non-existent" is judged via DNS. A subdomain is considered non-existent if it doesn't resolve (no record). That's where the DNS Tree Walk comes in, the mechanism by which DMARCbis figures out the domain tree.
• Parked domains love np. A domain that's owned but never sends should be at p=reject; np=reject — the same goes for dormant domains.

The DNS wildcard caveat

One configuration quietly undermines np: a wildcard record in the zone. Where a wildcard is published (a catch-all entry that matches any name under the domain), every subdomain an attacker invents suddenly resolves — and a subdomain that resolves is, by definition, no longer "non-existent." Those names then fall under sp, not np, and the carefully placed np=reject never fires for them. This isn't a reason to avoid wildcards where one is genuinely needed, but it changes the calculus: with a wildcard in place, sp must carry the strictness np was expected to bring, so it belongs at reject too. When auditing a domain, checking for wildcards is part of judging what np will actually cover in practice.

How to confirm it's in place

Once np=reject is published, two checks:

1. Re-reading the record with an analyzer confirms the tag is present and the syntax is valid — our free analyzer does it in seconds.
2. Watching the aggregate reports: a spoofed non-existent subdomain will now show a reject disposition rather than slipping through. Reading them is covered in how to read aggregate reports.

A concrete attack scenario

A real attack shows np at work. A company, example.com, did its homework: p=reject on the root domain, sp=reject for its known subdomains (mail.example.com, news.example.com). It believes it's protected.

An attacker prepares a phishing campaign. Rather than spoofing example.com (refused by p=reject) or mail.example.com (refused by sp=reject), they choose From: billing@accounts.example.com. That subdomain accounts.example.com does not exist in example.com's DNS. Without an np tag, many receivers land in a gray zone: should they apply the root policy? the subdomain one? none? Depending on the implementation, the message may pass — and land in the victim's inbox with a perfectly believable address.

Now, the same attack with np=reject published: the receiver finds that accounts.example.com has no record (via the DNS Tree Walk), applies the np policy, and refuses the message. The attack fails, without example.com ever having to create or watch a single fictional subdomain. That's the whole value of np: covering the infinite set of subdomains nobody ever created.

Recommended settings by case

• Normal sending domain, already at p=reject: p=reject; sp=reject; np=reject. The strict trio, no second-guessing.
• Domain still ramping (p=quarantine): np=reject can go in already, independently of p. No legitimate mail comes from a non-existent subdomain, so there's no risk in locking it down right away.
• Purely "corporate" domain with no sending subdomains: np=reject is almost mandatory — that's exactly the kind of domain spoofed via invented subdomains.
• Parked domain (no sending): p=reject; sp=reject; np=reject everywhere. Nothing goes out, everything should be refused.

Frequently asked questions about np

Can np=reject block legitimate mail? No, by construction. The tag only applies to subdomains with no DNS record. A legitimate service sending from a subdomain necessarily has records (at minimum for SPF/DKIM). If it has them, the subdomain "exists" and falls under sp, not np.

What happens when a real subdomain is created later? As soon as it has DNS records, it "exists" and moves under the sp regime. It then needs authenticating (SPF/DKIM) before it sends — like any source.

Is np mandatory? No, nothing is mandatory in DMARCbis. But it's one of the new features with the best benefit-to-risk ratio: real effect against phishing, zero risk, a single tag.

Do all receivers already honor np? Not all yet — DMARCbis adoption is gradual. Those that don't know it simply ignore it (harmlessly). The more the ecosystem updates, the stronger the protection. No reason to wait before publishing.

np and subdomain governance

Beyond the tag itself, np is a chance to ask a rarely-addressed question: who creates subdomains in an organization, and who knows about it? In many organizations, any team can point summer-campaign.example.com at a vendor without telling security. Every real subdomain is a surface to authenticate; every subdomain nobody deliberately created is a surface to refuse. np=reject settles the second category at a stroke, but the first takes real discipline: inventorying the sending subdomains, aligning them, and keeping sp coherent.

A good habit: treating the subdomain list as a security asset, just like the inventory of sending sources. The aggregate reports help here too — they reveal mail sent from forgotten subdomains, legitimate or not. Once that mapping is done, the sp/np pair becomes simple to set: strict sp for what exists and sends, np=reject for everything else.

This matters especially where BIMI is on the roadmap: displaying a logo assumes a coherent brand and a strict policy across the whole namespace. A spoofable subdomain is a crack in that trust story. Locking down non-existent subdomains with np is therefore as much an anti-phishing measure as a brand-consistency building block. And because the tag is risk-free, there's no reason to treat it as a "later" item — it's one of the few security wins that can ship today and then be forgotten about.

In short

DMARCbis's np tag sets the policy for subdomains that don't exist — a gap sp never covered. Setting np=reject is risk-free (nothing legitimate sends from a non-existent subdomain) and immediately effective against an entire category of phishing. Three tags to keep straight: p (root), sp (real subdomains), np (phantom subdomains). Publishing it now costs nothing: receivers that don't yet support DMARCbis simply ignore it, so there's no downside to being early — only the upside of closing a gap attackers actively probe.

Thomas sets the right policy

np, sp, p: three tags, and only one needs to be wrong to leave a door open. Thomas, the virtual CISO, generates the complete, coherent DMARCbis record for a domain — root, real subdomains and non-existent ones — and checks in the reports that no legitimate source is affected before tightening.

Analyze a domain for free or create an account. For the full DMARCbis context, see this new standard explained simply.