DMARCbis Adds a New Defense Against Subdomain Spoofing

DMARCbis, the first full update to the DMARC standard since 2015, is now official. It published on 19 May 2026 as three new RFCs (9989, 9990, and 9991), replacing RFC 7489 and moving DMARC onto the IETF standards track. Most of the change doesn't require immediate action, but there is one addition worth acting on: a new tag called np= that closes a subdomain-spoofing gap that the old standard left open.

DMARC is the standard that tells receiving servers what to do with mail that fails authentication checks. If you already run it at p=quarantine or p=reject, the ratification of DMARCbis does not break anything you have published. The quieter changes, including the removal of the pct tag and the move away from the Public Suffix List, are covered in our plain-language guide to what DMARCbis means for you. This piece is about the one addition worth acting on today.

Click the links to skip down to a specific section.

• What DMARCbis Made Official
• Where the sp= Tag Falls Short
• What Does the np= Tag Do?
• What Else Changed When DMARCbis Was Ratified?
• What Should You Do Now?
• The Takeaway

What DMARCbis Made Official

DMARCbis is not a single document. It published as three separate RFCs, each owning one part of the standard:

• RFC 9989 defines the core protocol: how policies are published, how alignment is evaluated, and how a receiver processes a DMARC record.
• RFC 9990 defines the aggregate report format, the daily XML summaries your domain receives.
• RFC 9991 defines failure reporting (per-message forensic reports).

Together, these RFCs replace RFC 7489 - the 2015 specification that defined DMARC until now. They also upgrade the standard's status, and this part is worth being precise about. RFC 7489 was classified as Informational, which means it documented DMARC without carrying the IETF's standards-track endorsement. DMARCbis is published as a Proposed Standard, the named maturity level the IETF assigns to a ratified standards-track document. Despite the word "Proposed," this is a finished, official standard, not a draft or a work in progress, and it is the entry rung of the standards track that many widely used internet protocols never move past. In practice, this signals maturity rather than a new obligation. It gives the standard firmer footing in procurement and compliance settings where an Informational document raised questions, but it does not yet require you to touch a record that already works.

Where the sp= Tag Falls Short

DMARC lets you set one policy for your main domain (the p= tag) and a separate policy for your subdomains (the sp= tag). The catch is that sp= only governs subdomains that exist in your DNS. It says nothing about subdomains that were never created.

That is the gap attackers use. A scammer can send mail from accounting.yourbrand.com or payroll.yourbrand.com - addresses you never set up and that hold no DNS records at all. Because that subdomain returns what the DNS world calls an NXDOMAIN response (no such name), some receivers historically treated the absence of a record as the absence of a policy and let the message through.

Most domains leave this exposed. In DMARCeye's Q1 2026 industry report, even among domains at full enforcement (p=reject), 65.15% declare no subdomain policy of any kind. At p=none the figure is 86.67%. A domain can be locked down at the top level and still hand attackers an open door one label to the left.

The full subdomain-policy breakdown, alongside the rest of the Q1 2026 dataset, is in the report:

What Does the np= Tag Do?

The np= tag sets a DMARC policy specifically for non-existent subdomains, i.e., any subdomain that returns no DNS records. It is the missing half of sp=.

With np= published, a receiver evaluating mail from a made-up subdomain follows a clear order. It checks for an np= policy first. If none is set, it falls back to sp=. If that is absent too, it falls back to the main p= policy. The new tag removes the ambiguity that let forged-subdomain mail slip through before.

For most domains, the right value is np=reject. A subdomain that does not exist sends no legitimate mail, so rejecting everything that claims to come from one costs you nothing and shuts the door on a whole class of impersonation. A record that already reads v=DMARC1; p=reject; becomes v=DMARC1; p=reject; np=reject; with one addition. The same logic applies to existing subdomains through sp=, and our guide to the sp= subdomain policy tag walks through when to set each one.

np= only helps once a receiver honors it, though. As a brand-new tag, its support is still rolling out across mailbox providers, so publishing it now is forward-compatible insurance rather than an instant fix.

Enter your domain to see the DMARC record you publish today, including any sp= or np= tag already in place:

What Else Changed When DMARCbis Was Ratified?

Two other changes round out the update, though neither asks much of you today.

The pct tag is gone. It was meant to let you apply a policy to a percentage of your mail at a time, but receivers implemented it inconsistently. In DMARCeye's Q1 2026 dataset, 94.11% of p=quarantine domains and 93.51% of p=reject domains already ignored it and enforced at full strength from day one. DMARCbis replaces it with a simpler t= (testing) flag. The full account of why the staged-rollout dimmer never worked is in our guide to what DMARCbis means for you.

DMARC also stopped leaning on the Public Suffix List to work out where an organization's domain boundary sits. It now walks the DNS directly. Single-domain owners will not notice the difference. Operators of large subdomain estates should confirm their records still resolve the way they expect.

What Should You Do Now?

How much np= matters depends on what you run.

If you operate a single domain or a small business: adding np=reject is a one-line change with no downside, and it closes an impersonation route that does not depend on you remembering every subdomain you ever created. If you do not manage your own DNS, this is a job for whoever does: usually your domain registrar (the company you bought the domain from, such as GoDaddy or Namecheap), your web host, or the IT contractor or agency that set up your email. Send them the record you want published, v=DMARC1; p=reject; np=reject;, and ask them to add or update it on your domain.

If you run an ecommerce store or marketing domains: forged subdomains are a brand-trust problem as much as a security one, because a convincing billing.yourbrand.com lands in customer inboxes looking exactly like you. Pair np=reject with active monitoring so you can see which sources send under your domain before you tighten anything. DMARCeye's free plan covers one domain with full report parsing, which is enough to start.

If you are an agency or MSP: np=reject is a quick, defensible win you can roll out across every client domain you manage. DMARCeye scopes each client account separately, so your team can track subdomain posture across a whole portfolio from one console while each client still sees only their own data.

If you run enterprise mail infrastructure: treat np= as part of subdomain governance. Inventory which business units own which subdomains, set sp= for the ones that legitimately send, and set np=reject for everything else as you fold the change into your next DMARC review.

The Takeaway

DMARCbis becoming an official standard does not force any change to a DMARC record that already works. What it does is formalize a fix for a gap most domains still leave open: the forged, never-created subdomain. The np= tag is the new lever, and np=reject is the safe default for most domains. The only way to know whether you need it is to look at what your domain publishes today.

That visibility is what DMARCeye is built for. It reads the DMARC reports your domain receives and shows you, in plain language, which sources are sending under your name and where your policy leaves you exposed.