What is DMARCbis? RFC 9989 explained

DMARCbis is no longer a draft. The IETF published the core specification as RFC 9989 in May 2026. It is a Standards Track replacement for RFC 7489 and RFC 9091. Existing v=DMARC1 records remain the starting point, but policy discovery and several tags have changed.

Quick takeaways

• RFC 9989 is the current core DMARC specification.
• RFC 9990 now defines aggregate reporting.
• RFC 9991 now defines failure reporting.
• DNS Tree Walk replaces Public Suffix List dependency for policy discovery.
• The np, psd, and t tags were added.
• The pct, rf, and ri tags were removed from the current specification.

What happened to DMARCbis?

The IETF published the DMARCbis work as three Standards Track documents in May 2026:

• RFC 9989 defines the core DMARC protocol.
• RFC 9990 defines aggregate reporting.
• RFC 9991 defines failure reporting.

RFC 9989 obsoletes RFC 7489 and RFC 9091. Calling DMARCbis an upcoming draft or saying it is still in IETF Last Call is now out of date.

What changed in RFC 9989?

DMARC is now on the Standards Track

RFC 7489 was published as an Informational RFC. RFC 9989 is an Internet Standards Track document that reflects the IETF process and community review.

Policy discovery uses DNS Tree Walk

RFC 9989 replaces reliance on a Public Suffix List with DNS Tree Walk. A receiver starts from the relevant domain and walks upward through DNS labels while looking for a valid DMARC policy record. The algorithm limits the process to eight queries.

This matters for public suffix operators and organizations with deeper or less conventional DNS structures. The psd tag helps distinguish a Public Suffix Domain from an Organizational Domain during discovery.

Three tags were added

• np specifies policy for non-existent subdomains.
• psd identifies whether the record belongs to a Public Suffix Domain.
• t requests test handling for an enforcement policy and replaces part of the old pct behavior.

Do not add these tags without understanding how receiving systems implement RFC 9989. A valid record can remain simple.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example reporting address with one you control and verify external report authorization when the destination uses another domain.

Three tags were removed

RFC 9989 removes:

• pct, which requested policy application to only a percentage of messages.
• rf, which requested a failure-report format.
• ri, which requested an aggregate-report interval.

Receivers may still encounter older records containing these tags. Current implementations should follow the active tag registry and RFC 9989 behavior.

Do existing DMARC records still work?

Existing records still use v=DMARC1. The familiar p, sp, rua, ruf, adkim, and aspf tags remain in RFC 9989. You do not need to replace a working record merely because the standard moved from RFC 7489 to RFC 9989.

You should review records that depend on pct, rf, or ri, and test domains whose policy discovery relies on a complex organizational boundary.

How should operators prepare?

1. Inventory current records

Check each domain and active sending subdomain. Record the current policy, report destinations, alignment mode, and any removed tags.

2. Verify real sending paths

Use receiver-added Authentication-Results headers and DMARC aggregate reports. A DNS record can be syntactically valid while a production sender still fails alignment.

3. Review complex domain structures

Pay special attention to deep subdomains, private organizational boundaries, and Public Suffix Domain use cases. Compare the result of current DNS Tree Walk discovery with the policy you expect receivers to find.

4. Test before enforcement changes

Do not use the publication of RFC 9989 as a reason to move directly to p=reject. Account for legitimate sources, verify SPF or DKIM alignment, and observe the results before tightening policy.

Where Palisade fits

Palisade is AI-first DMARC software for MSPs and teams managing 10 or more domains. Its agent investigates sending sources, works through SPF and DKIM alignment, and moves domains toward p=reject. For RFC 9989, that means carrying the inventory and remediation work across the portfolio while keeping operators in control of policy decisions.

Try the Palisade DMARC agent on your own domain before rolling the workflow out to clients.

Frequently asked questions

Is DMARCbis still a draft?

No. The core work became RFC 9989 in May 2026. Aggregate and failure reporting became RFC 9990 and RFC 9991.

Does RFC 9989 change v=DMARC1?

No. Current DMARC policy records still begin with v=DMARC1.

Does every domain need the new tags?

No. The np, psd, and t tags address specific policy and discovery cases. Many domains can continue using a straightforward record built around p and rua.

What should I do with pct?

RFC 9989 removes pct. Review why it is present, decide what policy you can safely apply, and test that policy using current DMARC data before editing the record.

Did aggregate-report XML disappear?

No. Aggregate reporting moved into RFC 9990. A separate document now owns that part of the specification.

Does RFC 9989 guarantee that receivers will enforce my policy?

No. DMARC expresses the domain owner's assessment policy. Receiving systems use DMARC as one input to their own message-handling decisions.