DMARCbis: What Changes with the New RFC 9989, 9990 and 9991

DMARCbis has now been published as a set of new RFCs. This update replaces the older RFC 7489, published in 2015 as an Informational RFC, and gives DMARC a more modern standards foundation.

For SMBs, IT teams, system administrators and marketing teams, the key point is straightforward: DMARC itself is not being reinvented, but its specification is now clearer, more structured and better aligned with how email authentication is used today.

Direct Answer

DMARCbis does not replace the principle of DMARC. It modernizes the specification, clarifies behavior, separates the protocol and reporting into multiple RFCs, and prepares the ecosystem for better interoperability between receivers, auditing tools and reporting platforms.

Existing DMARC records remain broadly valid. DMARCbis does not mean every organization must urgently change its DNS zones. It does mean this is the right time to audit policy records, XML reports, subdomains and the tools that process DMARC data.

In Short

• DMARCbis is the modern evolution of DMARC.
• RFC 7489 is replaced.
• RFC 9989 defines the core DMARC protocol.
• RFC 9990 defines DMARC aggregate reports.
• RFC 9991 defines DMARC failure reports.
• Existing DMARC records remain largely usable.
• Organizations should mainly review their records, reporting flows and reporting tools.

Why DMARCbis Matters

DMARC was already widely deployed by domains, mailbox providers, marketing platforms and security tools. But its historical foundation was RFC 7489, an Informational RFC from 2015 that sat outside the main IETF standards track.

Since then, the email ecosystem has changed. SPF, DKIM, DMARC, domain alignment, rejection policies, sending subdomains, XML reports and domain reputation have become operationally important for organizations of all sizes.

DMARCbis gives implementations a clearer foundation. Mailbox providers, auditing tools and DMARC reporting platforms can now rely on recent Standards Track documents that separate the core protocol, aggregate reporting and failure reporting.

DMARC is still an email authentication and phishing protection signal. It is not a complete spam filter and it does not guarantee inbox placement.

What Changes with the New RFCs

Previous model	New DMARCbis model	Practical impact
Single RFC 7489	RFC 9989, RFC 9990 and RFC 9991	The documentation is split by role: protocol, aggregate reports and failure reports.
Informational DMARC RFC	Standards Track RFCs	DMARC now has a stronger standards foundation for implementations.
Protocol and reporting in one broad specification	Separate protocol / aggregate reporting / failure reporting documents	Tools can follow the exact scope of each RFC more precisely.
Organizational domain discovery historically tied to the Public Suffix List	Clarification through DNS Tree Walk logic	Organizational domain and policy domain discovery become more explicit.
Aggregate reports in the historical specification	Dedicated RFC 9990	Parsers and reporting platforms have a specific reference for aggregate XML reports.
Failure reports in the historical specification	Dedicated RFC 9991	More sensitive reports are handled separately, with stronger attention to privacy.
Existing policy records	Generally still valid, but worth auditing	Organizations should review tags, reporting destinations, subdomains and alignment.

The IETF DMARC working group documents page now lists these RFCs as new DMARC Proposed Standard RFCs alongside the group’s other work.

Should You Modify Your DMARC Record?

Not necessarily right away. A well-formed DMARC record with v=DMARC1, a clear p= policy, valid reporting destinations and consistent alignment does not become obsolete overnight.

But yes, you should review it. The priority audit points are:

• p=: the main domain policy.
• sp=: the policy applied to subdomains.
• rua=: aggregate report destinations.
• ruf=: failure report destinations, if used.
• adkim=: DKIM alignment mode.
• aspf=: SPF alignment mode.
• fo=: failure report trigger behavior.
• Old, unnecessary or misunderstood tags.
• Validity of reporting addresses.
• Subdomain handling.
• SPF and DKIM alignment with the visible From domain.
• Actual processing of XML reports.

For a progressive method, start with How to Configure SPF, DKIM and DMARC Without Breaking Email Delivery, then use DMARC XML reports to identify real sending flows.

Example DMARC Record to Audit

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

In this example:

• p=none enables monitoring without asking receivers to quarantine or reject messages.
• rua requests aggregate reports.
• adkim and aspf control DKIM and SPF alignment.
• The next step is to analyze sending flows before moving to quarantine or reject.

That is the spirit of DMARC: understand legitimate sources, fix what is not aligned, then enforce gradually. Marketing, transactional and human email flows should be identified separately, especially when several platforms send mail for the same domain.

Impact for SMBs

For an SMB, DMARCbis should not be treated as a DNS emergency. It is better understood as a maturity signal: email authentication is now a structured, auditable and expected part of the email ecosystem.

The practical business impact is mostly about operations:

• Clearer standards.
• Better future compatibility across tools.
• More rigorous DMARC audits.
• A stronger need for real DMARC report supervision.
• A reason to separate marketing, transactional and human sending flows.
• A reason to keep DMARC enforcement progressive and documented.

If you use Brevo, ActiveCampaign, Mailjet or another marketing platform, a dedicated sending subdomain helps isolate reputation and makes reports easier to interpret.

Impact for Reporting Tools

DMARC reporting tools will need to follow RFC 9990 for aggregate reports. These reports remain essential for identifying legitimate senders, spotting suspicious sources, measuring SPF/DKIM alignment and preparing stricter policy enforcement.

Parsers also need to be robust across report variants sent by different receivers. In practice, an organization should not merely receive XML files: it should consolidate them, interpret them and map them back to real sending platforms.

Failure reports, now covered separately by RFC 9991, are more sensitive because they may contain data about individual messages. They should be used carefully, taking privacy, volume and operational value into account.

What Dharmail Recommends

• Inventory all legitimate senders.
• Check SPF and DKIM.
• Verify DMARC alignment.
• Review p=, sp=, rua= and ruf=.
• Audit subdomains.
• Analyze XML reports.
• Remove unnecessary configuration.
• Document sending flows.
• Move progressively toward quarantine, then reject, once flows are under control.

This checklist should be connected to your broader deliverability diagnosis. If messages land in spam or Gmail Promotions, authentication is an important prerequisite, but it should be combined with reputation, content, complaint and bounce analysis. The guides Why Do My Emails Land in Spam or Gmail Promotions?, Google Postmaster Tools and SMTP Error List can help widen the investigation.

FAQ

What is DMARCbis?

DMARCbis is the modernization of the DMARC specification. It keeps the DMARC mechanism, but defines it through clearer Standards Track RFCs.

Does DMARCbis replace DMARC?

No. DMARCbis does not replace the DMARC mechanism used by domains; it replaces the older RFC 7489 specification with RFC 9989, RFC 9990 and RFC 9991.

Do I need to change my DMARC record?

Not necessarily right away. Existing DMARC records generally remain usable, but they should be audited together with reports, subdomains and reporting tools.

What happens to RFC 7489?

RFC 7489, published in 2015 as an Informational RFC, is obsoleted by the new DMARCbis documents, including RFC 9989 for the core protocol.

What is RFC 9989 for?

RFC 9989 defines the core DMARC protocol, including policy discovery, SPF and DKIM alignment, policy records and receiver processing logic.

What is RFC 9990 for?

RFC 9990 defines DMARC aggregate reports, including the XML report structure, report discovery and delivery to rua destinations.

What is RFC 9991 for?

RFC 9991 defines DMARC failure reports, which relate to individual failed messages and require careful privacy handling.

Does DMARCbis automatically improve deliverability?

No. DMARCbis improves standardization and interoperability, but DMARC remains an authentication and anti-spoofing signal, not a guarantee of inbox placement.

Conclusion

DMARCbis is an important milestone in the maturity of email authentication. For organizations, the main task is not to rush into DNS changes, but to verify that DMARC policy records, sending flows and reporting are actually under control.

If you want to check SPF, DKIM and DMARC compliance, analyze DMARC reports or prepare your domain for the updated standard, Dharmail can provide a complete and actionable audit of your email infrastructure. Contact Dharmail to turn this standards update into a clear action plan.