RFC 9989: What DMARCbis Means for Customers

Introduction

DMARC has had a significant standards update. What many people have called DMARCbis, and sometimes DMARC 2.0, was published in May 2026 as a set of three RFCs:

• RFC 9989 - the main DMARC specification
• RFC 9990 - DMARC aggregate reporting, commonly called RUA reporting
• RFC 9991 - DMARC failure reporting, commonly called RUF reporting

The short version for VerifyDMARC customers is: you probably do not need to change anything.

Your existing DMARC records still use v=DMARC1. Your existing RUA reporting address still works. VerifyDMARC supports the updated RFC 9990 aggregate reporting format and its new extension structure, so reports from mail providers adopting the new format continue to be processed.

Is This Really DMARC 2.0?

Not in the way most domain owners would think of a “version 2.0” product upgrade.

The protocol has been cleaned up, split into clearer documents, and moved onto the IETF Standards Track. That matters for implementers, mail receivers, and reporting platforms like VerifyDMARC. It does not mean your DNS record suddenly changes from v=DMARC1 to something else.

You may see “DMARC 2.0” used in articles because RFC 9990 uses a new XML namespace for aggregate reports. That is report-format detail, not a new DNS record version for domain owners to publish.

What Changed in RFC 9989?

RFC 9989 replaces the older DMARC specification in RFC 7489 and also rolls in lessons from the public suffix domain experiment in RFC 9091.

For customers, the important changes are mostly about clarity and edge cases:

• DMARC is now an Internet Standards Track protocol.
• Policy discovery has been updated, including a DNS tree walk approach.
• Public suffix domain handling is now part of the main DMARC specification.
• The newer DMARC tags np, psd, and t are defined.
• Older tags including pct, rf, and ri are now historic.
• Reporting is split into its own documents: RFC 9990 for aggregate reports and RFC 9991 for failure reports.

Most organisations should still focus on the same practical DMARC goals: publish a valid record, collect aggregate reports, fix legitimate senders that are not aligned, and progress toward p=reject when ready.

If you are new to the protocol, start with our introduction to DMARC. If you already have DMARC but are not collecting reports, read why RUA reporting still matters with p=none.

What RFC 9990 Means for RUA Reports

RFC 9990 gives DMARC aggregate reporting its own specification. These are the RUA reports that VerifyDMARC processes to show which services are sending email for your domain, whether SPF and DKIM are passing, and whether those results align with the visible From domain.

The useful part for customers is that aggregate reports remain the practical way to operate DMARC. They provide enough detail to identify legitimate senders, misconfigured services, suspicious sources, and policy readiness without collecting individual email content.

RFC 9990 also defines an updated XML structure with extension points. This lets report senders include future structured data while allowing processors to ignore extension data they do not understand. VerifyDMARC supports the updated aggregate reporting format and the new extension structure, so early adoption by mail receivers should not disrupt your reporting.

If you are migrating to VerifyDMARC or checking your DNS, the key tag is still rua=. For example:

v=DMARC1; p=none; rua=mailto:your-reporting-address@reports.verifydmarc.com

You can learn more in our guide to RUA and RUF DMARC reports.

What RFC 9991 Means for RUF Reports

RFC 9991 covers DMARC failure reports, often called RUF reports or forensic reports. VerifyDMARC does not support RUF reports, and we do not recommend adding your VerifyDMARC reporting address to a ruf= tag.

That is intentional.

RUF reports can contain message-specific information, including personal or sensitive data. In practice, many large mail providers limit or disable them, and the privacy trade-off is rarely worth it for normal DMARC operations. Aggregate RUA reports give MSPs and IT teams the visibility they actually need to find authorised senders, fix authentication gaps, and move domains safely toward enforcement.

This matches our broader privacy-first approach. We avoid collecting more data than is needed to deliver the service. For more background, see Enhancing Email Security with Privacy in Mind.

What Customers Should Do Now

For most VerifyDMARC customers, there is no action required.

If you are reviewing an older hand-written DMARC record, use these checks as a cleanup pass:

1. Keep your existing v=DMARC1 record.
2. Keep your rua= tag pointed at your VerifyDMARC reporting address.
3. Do not add your VerifyDMARC reporting address to ruf=.
4. Remove historic tags such as pct, rf, and ri if they are present.
5. Continue reviewing senders and alignment results in VerifyDMARC.

VerifyDMARC’s DMARC generator does not include these historic tags.

VerifyDMARC already checks for some insecure configurations that can arise from the newer DMARC tags. For example, a non-existent subdomain policy (np) set to none can matter as more receivers adopt the updated specification.

If you want to check a domain quickly, use our free domain security check.

Conclusion

RFC 9989 is a milestone for DMARC, but it is not a disruptive migration for most domain owners. The fundamentals are unchanged: authenticate your legitimate email with SPF and DKIM, make sure at least one of them aligns for DMARC, collect RUA aggregate reports, and move toward enforcement when the data says you are ready.

VerifyDMARC supports the updated RFC 9990 aggregate reporting format and its extension structure, while continuing not to support RUF reports because they add privacy risk without much operational value.

In other words: DMARC has matured. Your day-to-day DMARC work remains refreshingly familiar.