PSD DMARC and the “np” tag — protecting non-existent cousin domains

You manage a public-suffix-style domain — a registry TLD, or a SaaS platform issuing customer subdomains — and keep seeing “PSD DMARC” and the np tag mentioned as ways to stop cousin-domain spoofing of subdomains that don't even exist.

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

The np tag — “requested policy for non-existent subdomains” — was introduced experimentally by RFC 9091 for Public Suffix Domain (PSD) operators, and DMARCbis (RFC 9989) folds it into the core standard with status “active” in the IANA DMARC Tags Registry. For DMARC purposes, a subdomain counts as non-existent when the DNS returns NXDOMAIN or NODATA for its A, AAAA and MX records — all three, not just one. Publishing np=reject on your organizational domain tells receivers to reject mail from any cousin subdomain that doesn't actually exist in your DNS (a classic BEC pattern: a look-alike subdomain impersonating a real one), without touching the policy for subdomains you do use. Source: RFC 9091 §2.7 “Non-existent Domains” and §3.2 “np” tag definition · verified 2026-07-17.

What to do about it

Step 1. Add np=reject (or np=quarantine to start softer) to your organizational-domain DMARC record — it only applies to subdomains that don't exist, so it can't disrupt real senders.
Step 2. Confirm which of your subdomains genuinely have no A, AAAA or MX records — those are exactly what np= protects.
Step 3. Remember np is ignored on records published at a subdomain or PSD level itself — it only takes effect via the record at your organizational domain.
Step 4. If you operate a registry-style PSD (a TLD or a multi-tenant platform), review whether your setup matches the “Branded PSD” or “Multi-organization PSD” case in RFC 9091 §1.2 — the right np posture differs between the two.

Frequently asked

Do I need to change my DMARC record because of DMARCbis?

No, not immediately. RFC 9989 keeps the same v=DMARC1 tag syntax your current record uses — it mainly changes how receivers discover the record (the DNS Tree Walk) and adds optional new tags like t= and np=. Nothing about your existing record becomes invalid.

Is DMARCbis a completely different standard from DMARC?

No — RFC 9989 explicitly obsoletes RFC 7489 as a refinement of the same DMARC standard, based on years of implementation experience. Aggregate and failure reporting moved into their own documents, RFC 9990 and RFC 9991, all published May 2026.

Where can I read the actual standard instead of a summary?

RFC 9989 (core), RFC 9990 (aggregate reports) and RFC 9991 (failure reports) are all published free at rfc-editor.org, no registration required.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →