What RFC 9990 Changed About DMARC Aggregate Reports: A Plain-English Guide

If you run DMARC, you rely on aggregate reports to understand who is sending mail on your behalf and whether their authentication is passing. Those reports are governed by an RFC. That RFC changed.

RFC 9990 (May 2026) is the new standards-track document covering DMARC aggregate reporting. It obsoletes RFC 7489, which had been the governing RFC since 2015. If you have not looked at it, you may be missing report fields your parser was not expecting, or you may be overlooking changes that affect how you interpret your data.

This post breaks down what actually changed and what it means for your DMARC monitoring setup in plain terms.

What Aggregate Reports Are For

Before getting into the changes, a quick recap. DMARC aggregate reports are XML files sent by receiving mail servers to the address you specify in your DMARC DNS record (via the rua tag). They arrive on a schedule set by the receiver, typically once per day.

Each report contains a snapshot of authentication results for your domain across all mail the receiver processed during that period. You see SPF, DKIM, and DMARC results for each sending IP, plus counts of messages that passed or failed. If something is sending mail pretending to be you, aggregate reports are usually where you find out.

That feedback loop is the whole point of DMARC. If your reports are wrong, incomplete, or hard to parse, your visibility suffers.

What RFC 9990 Actually Changes

Most of the changes in RFC 9990 affect how receivers generate and format reports. Domain owners see the effects downstream, especially if they parse reports themselves. Here is what matters.

Error Element (Section 3.1.5) - New

RFC 9990 adds a dedicated error element to aggregate reports. Previously, if a receiver encountered an error processing a message's authentication, it might encode that information in a generic way or omit it. The new error element provides a specific field for reporting processing failures that occurred during DMARC evaluation.

For practitioners, this means future reports may include structured error data that was previously invisible or buried in other fields. If you parse reports manually and your tool does not handle this element, you may see parsing errors or dropped data.

This is where a managed DMARC monitoring tool earns its keep. DMARCFlow tracks the incoming XML structure of your aggregate reports and flags any changes to the report schema, including new elements like the RFC 9990 error field. Rather than updating a custom parser every time the RFC changes, you get spec-compliant parsing automatically.

Unique Identifiers and Report-ID (Section 3.1.4) - Clarified

Section 3.1.4 clarifies how unique identifiers work in aggregate reporting. The Report-ID field now has a more precise definition. Receivers must generate report IDs in a way that supports deduplication and cross-referencing. This matters most when correlating incidents across multiple reports or when your monitoring needs to track a specific message stream over time.

If you have ever tried to match an aggregate report entry to a specific message and found the identifiers ambiguous, RFC 9990's clearer definition should make that easier.

DKIM Signatures in Reports (Section 3.1.3) - More Explicit

The handling of multiple DKIM signatures per message is now more explicitly specified. RFC 7489 was vague on how receivers should report messages with multiple DKIM signatures. RFC 9990 spells out how those should appear in the report.

If your domain or any subdomain sends with multiple DKIM keys (which is not uncommon with some ESPs), this section affects how those results are represented.

Policy Override Reason (Section 3.1.6) - Clarified

When a message fails DMARC but the receiver delivers it anyway, they are expected to report the override reason. RFC 9990 clarifies the override reason codes and when each applies. This matters for incident response: if you see a message that failed DMARC but was delivered, the override reason tells you why.

The clearer specification means future reports should give you more consistent and actionable override data.

Duplicate Handling (Section 3.5.4) - Now Formalized

How receivers should deduplicate messages across multiple authentication checks is now formally specified. RFC 7489 did not address this explicitly. RFC 9990 does.

For high-volume senders, this change may affect message counts in aggregate reports. If you were seeing inflated counts due to inconsistent deduplication across receivers, RFC 9990's formal specification should make reporting more consistent.

Extensible Reporting (Section 5) - Clarified

The extensibility model for aggregate reports is now documented more clearly. This means the report format can be extended in the future without breaking existing parsers. RFC 9990 gives the format a more robust extension path.

Report Delivery and MIME Structure

The RFC clarifies the MIME structure of email-based report delivery. The format remains the same (DMARC reports are XML files delivered as email attachments), but the structure is now spelled out more precisely.

Do You Need to Change Your DMARC Setup

No. RFC 9990 is backward-compatible with your existing DMARC DNS records. Your p=none, p=quarantine, or p=reject policy does not need to change. Your mail flow does not need to change.

What may need to change is your report parser. If you use a professional DMARC monitoring service, the vendor handles parser updates and you see the benefit automatically. If you parse reports manually or rely on custom scripts, you should verify your parser handles the new error element and identifier fields.

You can test this by opening a recent aggregate report in a text editor. If the report contains a <error> element or if your parser throws warnings about unknown fields, your parser needs updating.

How to Verify Your DMARC Reporting Is Working After RFC 9990

Use this checklist to confirm nothing broke on your end.

1. Log into your DMARC reporting tool and confirm reports are still arriving from your known receivers.
2. Check that your tool or parser does not throw errors on new XML fields, particularly the <error> element in section 3.1.5.
3. Verify Report-ID uniqueness is being tracked and you can cross-reference entries if needed.
4. Confirm you are still seeing DKIM and SPF results for all expected subdomains and sending IPs.

If any of these checks fail, the issue is likely your parser, not your DMARC policy.

The Practical Takeaway

RFC 9990 is a standards update that most DMARC practitioners will not notice immediately. Your reports will keep arriving. Your authentication data will not disappear. The changes are primarily structural and affect how receivers generate and format data.

The practical risk is for organizations with custom XML parsers. If that describes you, update your parser to handle the new error element and identifier fields. If that does not describe you, your DMARC monitoring vendor handles it.

If you are still parsing DMARC reports manually, RFC 9990 is a reminder that aggregate reporting is a standards-governed format that evolves. Staying current requires ongoing maintenance. Services like DMARCFlow handle parser updates as part of their spec compliance, so you do not need to track RFC changes yourself. You just get reports that work.

FAQ

Do I need to change my DMARC policy because of RFC 9990?

No. RFC 9990 does not change how DMARC policies work. Your DNS records and p= setting stay the same.

What is the error element in DMARC aggregate reports?

The <error> element (section 3.1.5 of RFC 9990) is a new structured field that reports processing errors encountered during DMARC evaluation. It replaces informal encoding of errors that may have varied across receivers.

What does Report-ID mean in a DMARC aggregate report?

Report-ID (section 3.1.4) is a unique identifier assigned by the receiver to each report. RFC 9990 clarifies how it should be generated and used for deduplication and cross-referencing.

Will RFC 9990 change my message counts?

Possibly, if your receivers were not deduplicating consistently before. RFC 9990 formalizes duplicate handling, which should make counts more accurate over time.

Do all receivers support RFC 9990 already?

RFC 9990 was published in May 2026. Full receiver adoption will take time. During the transition period, you may receive reports formatted under both RFC 7489 and RFC 9990. A DMARC monitoring tool that handles both formats is the safest approach.