What changed in DMARC with RFC 9989, 9990, and 9991? A practitioner's summary

RFC 7489 is gone. The IETF replaced it with three RFCs: RFC 9989 for the core DMARC protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Here is what changed in each one and what it means for your email authentication setup.

Why DMARC got reorganized into three RFCs

RFC 7489 was getting unwieldy. It tried to cover the core DMARC protocol, aggregate report formats, and failure reporting all in one document. When the IETF needed to update any one part, editing one massive RFC created review bottlenecks and delayed changes that practitioners needed sooner.

Splitting the spec lets each piece evolve on its own schedule. Aggregate report format updates no longer require touching the core protocol. Failure reporting changes do not require touching the policy publishing mechanics. This is a structural improvement that makes the standards process faster without changing how DMARC actually works day to day.

RFC 9989: The core DMARC protocol

RFC 9989 is the replacement for the core DMARC sections of RFC 7489. Most of the mechanics are unchanged. The p= tag still controls your policy. Alignment checking still requires either SPF or DKIM to pass and align with your sending domain. The basic flow is the same.

What changed is mostly editorial clarity. Ambiguous language in RFC 7489 got tightened. The document structure is cleaner. For practitioners, the practical effect is minimal unless you are writing a strict parser or validator.

One area worth noting: the specification now gives more precise guidance on how receivers should handle messages with multiple authentication results. If you are building a DMARC-aware gateway or filter, the updated language matters. For everyone else using a third-party DMARC service, RFC 9989 is an incremental improvement, not a ground-up rewrite.

RFC 9990: Aggregate reporting, now a proper standard

RFC 9990 is the big change in this set. Aggregate reports have existed since the beginning, but RFC 9990 is the first dedicated Standards Track RFC just for report structure and content. Previously, aggregate report formats lived in the same document as the core protocol, and the specification was less opinionated about what fields were required versus optional.

RFC 9990 is more explicit about which fields must be present, what values are valid, and how report senders should handle edge cases. It also formalizes the XML schema that most major report senders already follow, reducing variation in how reports are structured across providers.

This matters because DMARC aggregate reports are only useful when the data is complete. If a report sender omits required fields, sends malformed XML, or uses invalid values, the receiving side has to guess or discard the record. RFC 9990 gives both sides a clearer contract.

URIports, which processes millions of DMARC reports daily, tracks compliance against RFC 9990 and publishes a real-time list of organizations with the highest non-compliance rates. Their data shows that Google, Yahoo, and Comcast still send reports with validation errors under RFC 9990. If you are trying to parse your own reports and something looks wrong, the problem might be on the sending side, not your parser.

RFC 9991: Failure reporting

RFC 9991 covers failure reporting, sometimes called FRF or failure feedback. When a message fails DMARC authentication and the receiver supports failure reports, this format governs how those reports are sent back to the domain owner.

Failure reports are more detailed than aggregate reports. They include the full headers of the failing message, not just a count. This makes them useful for forensic analysis when you need to understand exactly what a receiver saw.

The tradeoff is that failure reports can be large and noisy. Most domain owners who receive them find them overwhelming without a tool to parse and filter the output. Aggregate reports are usually more actionable for routine monitoring.

RFC 9991 clarifies the format and adds guidance on when failure reports should be sent, which receivers are expected to support them, and how domain owners should handle the volume.

What practitioners need to do differently

If you are using a DMARC monitoring service that handles report collection and parsing for you, the changes are mostly invisible. Your service should already be updated to parse the RFC 9990 format correctly. If it is not, you may see gaps or parsing errors that were not there before.

If you are building your own report parser, RFC 9990 is worth reading carefully. The schema has been clarified and some previously optional fields are now explicitly required. A parser that assumed certain fields would always be present may need updating.

For everyone, the practical next steps are:

• Check whether your DMARC monitoring tool flags RFC 9990 compliance issues. DMARCFlow validates incoming aggregate reports against RFC 9990 and surfaces compliance gaps per report sender.
• If you receive failure reports, verify that your tool can parse the RFC 9991 format without breaking. The header structure in failure reports is more complex than aggregate reports.
• If you manage a DMARC report-generating system, validate your output against the RFC 9990 schema. URIports offers a free validation tool. Non-compliant reports do not break DMARC, but they reduce the value of the data you are sending to your customers.

FAQ: DMARC RFC changes

Does RFC 9989 change how I set up DMARC?

No. The p= tag, alignment rules, and policy publishing mechanics work exactly as before. If you have DMARC running today, your existing records are still valid under RFC 9989.

Do I need to update my DNS records?

No. Your DMARC TXT record in DNS does not change. The RFC update affects report formats and protocol details, not the record syntax.

Do I need to update my DMARC parser if I built it myself?

Possibly. If you are parsing aggregate reports, RFC 9990 clarifies required fields and valid values. If you were handling malformed data gracefully, you may need to update your schema validation.

Are Google, Yahoo, and Comcast sending compliant reports now?

Not fully, according to URIports compliance data. All three still generate validation errors in their aggregate reports under RFC 9990. This does not break DMARC enforcement for their users, but it means their reports contain incomplete or inconsistent data.

How does DMARCFlow handle RFC 9990 compliance?

DMARCFlow parses incoming aggregate reports, validates them against RFC 9990, and flags compliance issues per report sender. This lets you see which providers are sending clean data and which are not, without needing to run your own validation pipeline.

What is the difference between aggregate reports and failure reports?

Aggregate reports are a regular summary: counts of messages that passed or failed SPF, DKIM, and DMARC alignment, broken down by sending domain and result. Failure reports are a per-message forensic record sent when a specific message fails DMARC. Aggregate reports are better for monitoring trends. Failure reports are better for investigating a specific incident.