What DMARCbis RFC 9989 Means for Email Administrators

What DMARCbis RFC 9989 Changes Mean for Email Administrators Today

RFC 9989, published in May 2026, is the first Standards Track revision of DMARC. It obsoletes RFC 7489 and RFC 9091. In plain terms: DMARC is now a proper Internet Standard, not just an Informational RFC that receivers chose whether to implement. If you manage email authentication for a domain, here is what actually changed and what you may need to act on.

What Changed: The New Tags in RFC 9989

RFC 9989 made several changes to the DMARC tag registry. Two are practically significant.

The np (No Policy) tag

This is the most consequential new tag. np stands for "No Policy." It applies to domains that do not send email at all. When a receiver queries the DMARC record for a non-existent subdomain and gets an NXDOMAIN response, RFC 9989 specifies that receivers should look upward for an np record at the parent domain. This lets large organizations set one policy for all their non-existent subdomains instead of managing records for each one individually.

Example: if mail.example.com does not exist but example.com publishes v=DMARC1; p=none; np=rpt=reject, a receiver handling mail for mail.example.com would see the np record and know the domain never sends legitimate mail.

What np means for real domains

If your domain sends any email, even occasionally, you should not add np to your DMARC record. Setting np on a domain that actually sends mail tells receivers to treat your domain as one that never sends anything. That will not end well.

The pct tag is now ignored

RFC 9989 formally removes the pct (percentage) tag from the DMARC specification. pct was used to apply DMARC policy to only a percentage of messages, intended as a gradual rollout mechanism. It never worked well in practice because receivers had to track percentage independently for each message, and it created unpredictable policy application.

If you have pct in your DMARC record today, receivers ignore it. If you had pct:100, you can simply remove the tag. If you had pct with a lower value, you no longer have a gradual rollout mechanism -- you need a different migration strategy.

Other changes worth knowing

RFC 9989 also formalizes several clarifications around Organizational Domain determination and policy discovery that affect how receivers walk up the DNS tree to find applicable DMARC records. These changes mostly affect large organizations with complex DNS hierarchies.

The np Tag DNSSEC Reliability Problem

Here is the part that is causing real headaches in practice.

The np tag only works reliably when DNSSEC validation is working end-to-end. When a receiver cannot validate the DNSSEC chain for your domain, the np tag behavior becomes inconsistent across different receivers.

The problem in one sentence: when DNSSEC validation fails or returns SERVFAIL, some receivers treat a domain with np as if p=none were set (monitoring mode, message passes). Other receivers reject the message because the np guarantee cannot be cryptographically verified. The same message to two different receivers can get two different outcomes.

This is the "reliably unreliable" problem with np. The tag assumes DNSSEC is universally and consistently available. In practice, DNSSEC deployment is uneven. Some large receiver platforms validate DNSSEC thoroughly. Others treat DNSSEC validation failures as non-fatal and fall back to treating the domain as if it had no DMARC policy at all.

What this looks like in aggregate reports

If you are testing np on domains that never send mail and you have DNSSEC configured, you may see:

Some receivers reporting np failures for your non-existent domains

Inconsistent pass/fail rates across receiver platforms for the same mail stream

DKIM or SPF alignment failures that seem to vary by receiver even though your DNS setup has not changed

These are symptoms of the np DNSSEC reliability problem.

The fix

Do not set np unless you have validated your entire DNSSEC chain. Test with a single subdomain first, and monitor aggregate reports from all major receivers before rolling np out more broadly. If you see inconsistent results across receivers, pull back np until DNSSEC validation is consistently working.

What Domain Owners Should Do Now

1. Remove pct from your DMARC record if it is still there. It has no effect and removing it cleans up your record.
2. Do not add np without testing it first. If your domain sends any email, np is not for you.
3. If you are considering np for a domain that genuinely never sends mail, validate your DNSSEC chain end-to-end before deploying it. Use a DNSSEC checker tool to confirm your records are properly signed and that your resolver is returning validated responses.
4. Read your aggregate reports and look specifically for receiver-specific variation in pass/fail rates. Unexplained variation by receiver is often a DNSSEC-related symptom.
5. If you are rolling out DMARC for the first time, ignore np for now. Start with p=none, monitor for two to four weeks, then move to p=quarantine and eventually p=reject as you validate your legitimate mail streams.

How DMARCFlow Fits

The np DNSSEC reliability problem is hard to detect without aggregate reports that break down authentication results by receiver. If you are testing np or removing pct from your record, you need to see whether your pass rates are changing differently across Gmail, Microsoft 365, and other large receivers. That kind of receiver-specific variation is the clearest symptom of np inconsistency, and it is exactly what DMARCFlow is designed to surface.

DMARCFlow's aggregate report monitoring parses incoming DMARC reports and organizes authentication results by receiver. When some receivers start handling your domains differently after a configuration change, DMARCFlow flags that discrepancy automatically. Without that level of breakdown, you would have to manually compare report XML from each receiver to notice the pattern.

If you are evaluating np in a DNSSEC environment, DMARCFlow's receiver-level breakdown makes it practical to catch the inconsistency before it affects legitimate mail delivery. If you are simply removing pct from your record, DMARCFlow helps you establish a baseline of pass rates by receiver so you can confirm nothing regresses.

For this particular topic, DMARCFlow earns its mention as a practical necessity for anyone testing new DMARC tags in a DNSSEC configuration. The np tag is an advanced feature. Monitoring it properly requires report parsing that goes beyond what most builtin DMARC dashboards provide.

FAQ

What is the DMARC np tag?

The np tag (No Policy) is a new tag added in RFC 9989. It tells receivers that the domain in question never sends email. It applies specifically to non-existent domains and is intended for large organizations that want a single policy covering all subdomains they do not use for mail.

Why does the np tag have reliability issues with DNSSEC?

When DNSSEC validation fails or is unavailable, different receivers handle np differently. Some treat it as p=none (monitoring mode). Others reject the message because the np guarantee cannot be cryptographically verified. The same message can get different outcomes depending on the receiver's DNSSEC stack. This makes np unreliable in environments where DNSSEC validation is not consistently available.

What happened to the pct tag in RFC 9989?

The pct tag was formally removed. Receivers ignore it. If you have pct in your DMARC record, remove it. The tag was intended for gradual DMARC policy rollout but created unpredictable behavior in practice.

Should I add np to my DMARC record?

Only if your domain genuinely never sends email AND you have validated that your DNSSEC chain is working end-to-end. If your domain sends any legitimate mail, do not use np. If you are not sure whether your DNSSEC is working correctly, do not use np.

How does DMARCbis differ from RFC 7489?

RFC 9989 is the Standards Track revision of RFC 7489 (which was Informational). The main practically significant changes are: the np tag addition, the pct tag removal, and clarifications to Organizational Domain determination and policy discovery. The core DMARC mechanism (SPF + DKIM alignment) is unchanged.