Introduction
When the IETF published DMARCbis in May 2026 as RFC 9989, RFC 9990 and RFC 9991, the headline for most people was the removal of familiar tags like pct. Less discussed, but just as important for anyone managing DMARC at scale, is what got added. The core specification, RFC 9989, introduces three new tags: np, psd and t. Each closes a specific gap in the original 2015 protocol, and each has a clear place in an MSP's playbook once you understand what it controls.
This article explains all three in plain terms, shows simple record examples, and points out where each one earns its keep and where it should be left alone. It is written for MSP owners, technical account managers and security engineers who need to make confident configuration decisions across many client domains. For the broader transition, see the DMARC for MSPs pillar.
Why these tags matter
DMARC has always evaluated mail by aligning the visible From domain against an authenticated SPF or DKIM result — that logic is unchanged, and a message still passes when aligned SPF or aligned DKIM passes. What the original specification handled less cleanly were the domains and subdomains that do not send mail at all, the registry-level names that sit above ordinary organizational domains, and the awkward period when an owner has published an enforcing policy but is not yet fully confident in it. The three new tags address exactly those situations. For an MSP, that means new, precise levers for the parts of a client's namespace that attackers most like to abuse.
np — policy for non-existent subdomains
The np tag sets the policy a receiver should apply to mail that claims to come from a subdomain which does not exist in DNS. This is different from sp, which governs subdomains that do exist. Non-existent subdomains — names with no A, AAAA, MX or other records at all — are a favourite of spoofers precisely because no legitimate mail uses them, so a strict policy there carries essentially zero risk of breaking real traffic.
Before DMARCbis, mail from a made-up subdomain like invoices.no-such-name.example.com fell back to the organizational domain's handling, which was often looser than an administrator would choose if asked directly. The np tag lets you name a hard policy for that entire class of names without touching the policy for real subdomains:
“ v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:[email protected] “
Here the organizational domain is at reject, real subdomains are quarantined, and any non-existent subdomain is rejected outright. For most clients, np=reject is a safe and sensible hardening step. The place to slow down is where a client uses wildcard DNS or provisions subdomains dynamically, because a wildcard record can make names "exist" in ways that change how np applies. The non-existent subdomains deep-dive covers those cases in detail.
psd — the Public Suffix Domain flag
The psd tag marks whether a DMARC record is published at a Public Suffix Domain — a registry-level name such as co.uk or gov.uk that sits above ordinary organizational domains. Setting psd=y tells receivers the record is a PSD-level policy intended to help protect the family of names beneath that suffix; psd=n explicitly declares that a name is not a public suffix, which is occasionally useful for overriding a receiver's boundary heuristics at an unusual delegation point.
“ v=DMARC1; p=reject; psd=y; rua=mailto:[email protected] “
For the vast majority of MSP clients, psd should simply be left unset. It is relevant to national registries, government-domain operators and others who run a public suffix, not to a typical business domain. Its importance to an MSP is mostly interpretive: when a client's domain sits under a suffix whose operator publishes a PSD policy, you may see that policy referenced in reports, and you should understand why. Note also that RFC 9091, the earlier experimental PSD extension, is now obsoleted, with PSD handling folded directly into core RFC 9989 — so there is one standard behaviour to reason about rather than an add-on. The Public Suffix Domains and organizational domain discovery article goes deeper for engineers.
t — test and transitional mode
The t tag signals whether a published policy is live or still being tested. The default, t=n, means the policy is in force as written. Setting t=y tells receivers you are in a testing or transitional state — you have published a quarantine or reject policy, but you are still validating your sender inventory and want that acknowledged.
“ v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected] “
Conceptually, t is the successor to the intent behind the old pct tag, but it works very differently. Where pct asked receivers to apply enforcement to a percentage of failing mail, DMARCbis makes enforcement all-or-nothing — a policy is applied at full strength or not — and uses t=y as a clean, honest signal that the owner is still in a transitional period. It is a communication mechanism, not a dial. The right way to use it is briefly: turn it on while you finish confirming senders, then remove it once you are confident. Leaving t=y in place indefinitely defeats the point, because it tells the world you are perpetually "just testing." The reasoning behind this change is covered in pct is going away.
When each tag matters, and when to avoid it
Taken together, the three tags reward a bit of judgement. np=reject is a strong, low-risk default for almost any domain and an easy win on parked and infrastructure domains that send no mail. psd should be left unset unless you genuinely operate a public suffix; setting it on an ordinary business domain is a misconfiguration waiting to confuse a receiver. t=y is valuable for a defined window during a move to enforcement and should be removed on schedule rather than left to linger. None of the three should be applied blindly across a portfolio; each is a deliberate choice tied to how a specific domain is used.
The MSP hook: finding clients at risk
The practical value of np in particular is that it lets you close a gap attackers actively exploit. Several common client situations raise the risk of non-existent-subdomain abuse, and they are worth screening for across your book of business.
- Clients using wildcard DNS, where a broad record can quietly change which names count as existing and how
npandspinteract. - Clients onboarding SaaS platforms that provision per-customer or per-service subdomains, which can leave a trail of names that look plausible to a spoofer.
- Parked domains and defensive registrations that send no mail at all, which should be locked down with
p=rejectandnp=rejectrather than left with a permissive or missing policy.
For a parked domain, the whole record can be as tight as this, since nothing legitimate will ever be blocked:
“ v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected] “
Screening a portfolio for these patterns — then applying np and the right policy per domain — is exactly the kind of high-value, low-risk hardening MSPs can deliver quickly. Build and validate the records with the DMARC generator, and confirm the result on each domain before you move on.
Related articles
- DMARC for MSPs — complete guide
- Non-existent subdomains and the DMARC np tag
- DMARCbis, Public Suffix Domains and organizational domain discovery
- pct is going away: rethinking partial DMARC enforcement
Authoritative references
- RFC 9989 — core DMARC protocol, including np, psd and t
- IANA DMARC parameters registry — the authoritative tag list
- RFC 7489 — the obsoleted 2015 specification
Author: DMARC AI editorial team Last updated: August 2026