Introduction
Most clients picture their domain as a single thing: the name on their website and the part after the @ in their email addresses. In reality, a domain is the root of a whole tree of possible names, and attackers pay close attention to the branches nobody is using. One of the more counter-intuitive facts in email security is that a criminal can attempt to send mail from a subdomain that has never existed — a name with no website, no mailbox and no DNS records at all — and, without the right policy, that attempt can still reach an inbox looking convincingly like the client.
DMARCbis, the modernized DMARC standard the IETF published in May 2026 as RFC 9989, RFC 9990 and RFC 9991, gives you a precise tool for this exact problem: the np tag, which sets the policy a receiver should apply to non-existent subdomains. This article explains what non-existent subdomain abuse is, how it differs from ordinary subdomain handling, and how MSPs put np to work in practical domain-hygiene projects. It is written to be readable enough to share the core idea with a client while staying precise enough for the engineer configuring the record. For the full set of new tags, see new DMARC tags explained.
Three kinds of names, and why the difference matters
To use np well, it helps to separate three categories of name that clients often blur together.
The organizational domain is the main name — client.com — where the primary website and mailboxes live. This is what the p= tag governs.
A real subdomain is a name beneath it that actually exists in DNS: mail.client.com, vpn.client.com, newsletter.client.com. It has records — an A record, an MX record, a CNAME, something — because it is used for a real purpose. Existing subdomains are governed by the sp= tag when it is present, or they inherit the organizational policy when it is not.
A non-existent subdomain is a name that resolves to nothing at all: no A or AAAA record, no MX, no CNAME. invoice.client.com might be one today if the client has never created it. From a mail-security point of view this is the interesting category, because no legitimate mail can ever originate from a name that does not exist — which means a strict policy there breaks nothing while closing a real avenue of abuse.
Why attackers target names that don't exist
It seems strange that a spoofer would choose a subdomain the victim has never set up, but the logic is straightforward. Recipients read domains from right to left without realizing it, and a made-up subdomain of the real domain — accounts.client.com — can look more trustworthy at a glance than a lookalike domain registered somewhere else. Because the subdomain never existed, there is no history, no security team watching it, and, crucially, often no policy explicitly covering it.
> "Even if invoice.client.com does not exist, attackers may still try to send mail pretending to be from it. DMARC policy needs to account for this."
That single sentence is usually enough to make the risk land with a non-technical client. They understand that they never created invoice.client.com; the surprise is that its absence is precisely what makes it attractive to an attacker, and that protecting it is something they have to do deliberately rather than something that happens by default.
What the np tag actually does
Before DMARCbis, mail claiming to come from a non-existent subdomain fell back to the organizational domain's handling, which was frequently looser than an administrator would have chosen if asked the question directly. A domain sitting at p=none for good monitoring reasons offered no protection at all to the infinite space of subdomains beneath it.
The np tag closes that gap by letting you name a policy specifically for non-existent subdomains, independent of everything else. Consider this record:
“ v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:[email protected] “
Here the organizational domain is enforced at reject, real subdomains are quarantined, and any non-existent subdomain is rejected outright. The three policies are set independently, which is what makes np valuable: you can be cautious with the names that carry real mail while being uncompromising with the names that never should. None of this changes the underlying DMARC logic — a message still passes when it produces an aligned SPF or an aligned DKIM result — np simply decides what happens to failing mail from names that do not exist.
np is not sp: keep the two straight
The most common point of confusion is the line between np and sp. They look similar and both concern subdomains, but they answer different questions. sp sets the policy for subdomains that do exist; np sets the policy for subdomains that do not. A client running a busy set of real subdomains might reasonably keep sp=quarantine while they finish authenticating those services, yet still set np=reject immediately, because the non-existent space carries no legitimate traffic to disrupt. Treating the two as interchangeable is how administrators either over-restrict real services or under-protect the empty namespace.
Safe defaults for parked and infrastructure domains
The clearest win for np is on domains that send no mail at all: parked domains, defensive registrations, brand-protection names and old domains kept only so a competitor cannot buy them. These are frequently left with a weak or missing DMARC record on the assumption that a domain nobody uses cannot be abused. The opposite is true — an unused domain with no enforcing policy is an open invitation to spoofing, and its very silence means no legitimate mail will ever be caught in the net.
For a domain like this, the record can be as tight as the standard allows, because nothing real will ever be blocked:
“ v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected] “
Applying this pattern across every non-sending domain in a client's portfolio is one of the fastest, lowest-risk improvements an MSP can make. It requires no sender inventory and no rollout window, because there are no senders to inventory and nothing to break.
Using np in domain-hygiene projects
For active domains, np fits naturally into the domain-hygiene work MSPs already do. The starting point is knowing the shape of the namespace: which subdomains exist, which are actually used for mail, and which are leftovers from old projects. A DNS lookup across the domain and its known subdomains gives you that map, and the aggregate reports arriving at your rua address show you where mail is really coming from.
From there, a few client situations deserve extra care rather than a blanket np=reject. Clients using wildcard DNS are the main one: a wildcard record can make every conceivable subdomain "exist" as far as DNS is concerned, which changes how a receiver decides whether a name is non-existent and therefore how np applies. Clients who provision per-customer or per-service subdomains through SaaS platforms are another, because those platforms can create and retire names faster than anyone documents them. In both cases the right move is to understand the naming behaviour first, then choose np and sp deliberately, rather than assuming the empty-namespace shortcut is safe.
When you build or revise these records, the DMARC generator produces clean, standards-current records with np set correctly, and it is worth confirming each one on the live domain before moving on. The Public Suffix Domains article is the companion read for engineers who need to understand exactly how a receiver decides where an organizational domain ends and its subdomains begin, since that boundary is what determines when np comes into play.
The takeaway for MSPs and clients
Non-existent subdomains are a genuine attack surface hiding in plain sight, and until DMARCbis there was no clean way to address them without also constraining real subdomains. The np tag removes that trade-off. For parked and non-sending domains it is close to a free hardening step; for active domains it is a deliberate choice made alongside sp once you understand the namespace. Either way, it turns a vague "we should be covered" into a specific, defensible policy — which is exactly the kind of concrete improvement that makes a domain-hygiene engagement worth the client's money.
Related articles
- DMARC for MSPs — complete guide
- New DMARC tags explained: np, psd and t
- DMARCbis, Public Suffix Domains and organizational domain discovery
Authoritative references
- RFC 9989 — core DMARC protocol, which defines the np tag
- RFC 7489 — the obsoleted 2015 specification
Author: DMARC AI editorial team Last updated: August 2026