Introduction
RFC 9990 is the DMARCbis document that defines aggregate reporting — the daily, machine-readable summaries receivers send back describing the mail they saw claiming to be from a domain. Published in May 2026 alongside RFC 9989 (the core protocol) and RFC 9991 (failure reporting), it takes what used to be a section of the old RFC 7489 and elevates it to its own Standards Track specification.
That promotion matters more than it sounds. Aggregate reports are the data an MSP actually operates on: they are the reason you can tell a client which senders authenticate, which do not, and whether it is safe to advance a policy. This article explains what RFC 9990 changes, why the changes help, and what a reporting pipeline has to do so that the numbers on a client dashboard are trustworthy. For the overview of all three RFCs, see the pillar: DMARC has changed.
What aggregate reports still are
The essentials are unchanged. Aggregate reports are XML documents, GZIP-compressed, sent on a roughly daily cadence to the address published in the rua= tag of a DMARC record. Each report is one receiver's statistical view over a time window: for every source IP that sent mail as the domain, how many messages there were, whether SPF and DKIM aligned, and what disposition the receiver applied. They contain no message bodies and no subject lines — they are metadata, which is exactly why they are safe to collect at scale and why they, rather than failure reports, form the operational backbone of DMARC. If you want the field-by-field primer, the existing DMARC aggregate reports explained still applies.
The headline change: DKIM detail is now required
The most consequential change in RFC 9990 is small in the schema and large in practice. In the old specification, the DKIM detail in the authentication results — which DKIM domain and selector were evaluated, and what the result was — was optional. Some receivers included it, some did not, and troubleshooting DKIM problems from reports was therefore hit or miss.
Under RFC 9990, that DKIM detail is required. When you receive a compliant aggregate report, you should now be able to see the DKIM identity behind a result rather than guessing at it. For MSPs this is a direct upgrade to two of the most common support tasks: diagnosing why a legitimate sender's DKIM is not aligning, and planning or verifying a DKIM key rotation. Instead of inferring which selector a provider used, you can read it. Across a fleet of clients with many third-party senders, that visibility removes a great deal of guesswork.
A concrete example makes the value obvious. Suppose a client is rotating a DKIM key from selector s1 to selector s2, and you want to confirm that live mail has actually moved to the new key before you retire the old one. Under the old optional-detail regime, a report might tell you DKIM passed without telling you which selector signed — leaving you unsure whether the rotation had taken effect for real traffic. Under RFC 9990 the selector detail is there to read, so you can watch traffic shift from s1 to s2 across successive reports and retire the old key with confidence rather than on a hopeful schedule.
A modernized, more uniform XML format
RFC 9990 also modernizes the report format and makes it more uniform. The old format accreted receiver-specific quirks over a decade; the refresh tightens the structure so that reports from different providers line up more predictably. Cleaner, more consistent input is easier to parse reliably and less likely to produce the subtle misreads that come from every receiver formatting things slightly differently.
Why reporting consistency is an MSP problem
Here is the part that separates a managed service from a raw feed. Even with a modernized standard, real-world reporting is messy. Receivers roll out changes at different speeds, some send imperfect or slightly non-compliant reports, volumes vary wildly between providers, and the same underlying event can look different depending on who reported it. If a dashboard takes all of that at face value, it will occasionally draw the wrong conclusion — flagging a healthy sender as failing, or worse, reassuring a client that everything is fine when a real gap exists.
A serious MSP reporting pipeline therefore does three jobs beyond simply displaying XML. It normalizes the differences between receivers, so that a "pass" from one provider is comparable to a "pass" from another. It filters noise, so that a one-off malformed report or a transient blip does not become a false alarm. And it turns the result into something actionable — a named sender, a specific fix, a clear go or no-go on advancing policy — rather than a wall of counts. The reasons reporting stays imperfect even under the new standard are worth understanding in their own right; see why DMARC reports are not always perfect.
Clients should not be reading raw XML
It follows that handing a client a folder of GZIP-compressed XML is not a deliverable. Even a technical client will struggle to derive the right conclusions from raw reports, and a non-technical one will simply ignore them. The value an MSP adds is interpretation: which senders matter, which failures are real, what to do next, and whether the domain is safe to move toward enforcement.
The DMARC AI approach is built around exactly that — ingesting the reports, normalizing receiver differences, filtering out the noise, and presenting a per-sender, per-domain picture that a technician can act on and a client can understand. If you want the practical philosophy of turning XML into decisions, the companion piece how to read DMARC XML reports without losing your mind makes the case. The goal is not to display data; it is to produce a decision.
Where individual message inspection fits
Aggregate reports tell you the shape of the traffic, but they never contain a specific message. When you need to look at one real message — to confirm which selector signed it, or why alignment failed for a particular send — you work from the message itself, not from the report. That is where an email header analyzer earns its place: paste the headers of a sample message and read the actual SPF, DKIM and alignment results for that send. Aggregate reporting shows you that a sender has a problem; header analysis on a sample message often shows you why. Pair the two, with a DKIM validator and SPF analyzer filling in the record-level detail, and most alignment mysteries resolve quickly.
What MSPs should check now
Confirm that your platform ingests the RFC 9990 format and surfaces the now-required DKIM detail — if it does, your rotation and alignment troubleshooting just got easier, and you should update runbooks to take advantage of it. Confirm that any in-house parsing handles the modernized schema without dropping fields. And make sure your client-facing reporting leads with interpretation rather than raw data, because the standard got cleaner but the job of turning reports into decisions did not go away.
Related articles
- DMARC has changed: RFC 9989, 9990 and 9991 for MSPs
- RFC 9991 explained: DMARC failure reporting for MSPs
- Why DMARC reports are not always perfect
- DMARC aggregate reports explained
- How to read DMARC XML reports without losing your mind
Tools mentioned
- Email header analyzer — read the real SPF, DKIM and alignment results of a specific sample message.
- DKIM validator — confirm a published DKIM key and selector, useful during rotations.
- SPF analyzer — check the SPF record behind a sender's alignment.
- DMARC checker — confirm the rua= address and record are set up to receive reports.
Author: DMARC AI editorial team Last updated: August 2026