Introduction
RFC 9990 is a genuine improvement to DMARC aggregate reporting. It elevates reporting to a Standards Track specification, modernizes the XML into something more uniform, and — most usefully — makes the DKIM authentication detail required rather than optional. It would be reasonable to hope that a cleaner standard means cleaner data, and to some extent it does. But anyone who has run DMARC reporting across a real book of business knows that the standard is only half the story. The other half is the messy, decade-old ecosystem of receivers, forwarders, gateways and mailing lists that actually produce and mangle these reports, and that ecosystem does not change the day an RFC is published.
This article is the practical follow-up to the RFC 9990 explainer. It explains why DMARC reports remain imperfect even under a better specification, catalogues the specific ways report quality breaks down, and makes the case that turning that raw feed into trustworthy conclusions is a job in itself. For MSPs, that gap between raw data and reliable interpretation is not a nuisance to apologise for — it is the reason a managed reporting service exists at all.
What RFC 9990 fixed, and what it left alone
It is worth being precise about what the new standard actually changed, because the improvements are real and the limits are equally real. RFC 9990 requires that aggregate reports include the DKIM domain and selector detail behind each result, which removes a long-standing blind spot in diagnosing why a sender's DKIM does or does not align. It tightens the XML format so that reports from different providers line up more predictably, and it confirms the essentials — XML, GZIP compression, a roughly daily cadence to the rua= address — as the stable backbone of DMARC operations.
What it does not do is reach into every receiver on the internet and make them compliant at once. Adoption happens on each provider's own timetable, so for months there will be a mix of modern reports and older-style ones in the same inbox. It does not retroactively fix the historical data you have already collected, which was written under the old optional-detail rules. And it does not change the fundamental nature of a report, which is that it describes what one receiver saw and chose to tell you — a partial, provider-specific view, not an authoritative ledger of everything that happened to a domain's mail.
Where report quality actually breaks down
The specific ways reports go wrong are worth naming, because each one produces a characteristic kind of wrong conclusion if a dashboard takes the data at face value.
- Missing or historical DKIM detail. RFC 9990 now requires the DKIM identity in reports, but legacy data collected under the old rules lacks it, and non-compliant or slow-to-update receivers will keep omitting it for a while yet. Any analysis that spans the transition has to cope with records that simply do not carry the detail the new standard promises.
- Inconsistent source naming. The same sending infrastructure can appear under different names, hostnames or IP ranges across reports from different receivers, and the reverse-DNS or organizational labels attached to a source are not standardized. Counting naively, one real sender can look like three, or three can collapse into one.
- Forwarded-mail noise. When a message is forwarded, the forwarding server becomes the source the receiver sees, and SPF usually breaks along the way even for perfectly legitimate mail. Forwarding shows up in reports as authentication failures from IPs the domain never authorised, which is alarming until you recognise the pattern.
- Secure gateways and relays. A message that passes through a filtering gateway or a third-party relay can have its authentication path altered, so the receiver's report reflects the gateway's handling rather than the original sender's. Without context, that reads as a failure of a sender that is in fact fine.
- Mailing lists. Discussion lists routinely modify subject lines and message bodies and re-send under their own infrastructure, breaking DKIM signatures and SPF alignment in the process. The resulting failures are expected and benign, but in raw form they clutter the picture and can mask the failures that actually matter.
None of these are defects in DMARC or in RFC 9990. They are properties of how email is delivered in the real world, and they were present long before DMARCbis and remain present after it.
Reports vary in fields, quality and interpretation
Layered on top of those specific problems is a more general one: reports simply vary. Different receivers populate different optional fields, apply their own thresholds before reporting, batch over different time windows, and occasionally emit reports that are slightly malformed or non-compliant. Volume varies enormously too — a single large provider can dwarf everyone else in your data, which skews any naive average toward that one receiver's behaviour.
The consequence is that the same underlying event can be described differently depending on who is reporting it, and two reports that look contradictory may both be accurate from their own vantage point. A pipeline that does not account for this will occasionally draw the wrong conclusion in either direction: flagging a healthy sender as failing because of forwarding noise, or reassuring a client that all is well when a genuine gap is hidden inside the variance. Both errors are expensive — the first wastes an engineer's afternoon, the second can leave a domain exposed.
Why raw reports are not enough for MSPs
This is the crux, and it is worth stating plainly: raw DMARC reports are not enough for MSPs. Handing a client a folder of GZIP-compressed XML, or even a dashboard that renders that XML faithfully, is not a deliverable — it is a pile of raw material that still needs to be interpreted before it means anything. A single domain generates dozens of reports a day; a portfolio of clients generates thousands, each carrying the naming inconsistencies, forwarding artefacts and gateway effects described above. At that scale, the difference between a report feed and a managed service is entirely in the interpretation layer.
A serious reporting pipeline therefore has to do three things that a raw feed does not. It has to normalize the differences between receivers, so a pass from one provider is comparable to a pass from another and the same sender is recognised consistently across sources. It has to filter the predictable noise — forwarding, mailing lists, one-off malformed reports — so that transient artefacts do not become false alarms. And it has to turn the result into something actionable: a named sender, a specific fix, a clear go or no-go on advancing a policy, rather than a wall of counts. The existing primer on reading DMARC aggregate reports walks through what those fields mean; the point here is that reading them correctly at portfolio scale is not something to do by eye.
Why AI filtering and context-aware interpretation matter
Normalising sources, recognising forwarding and gateway patterns, distinguishing a benign mailing-list failure from a real spoofing attempt, and doing it across thousands of daily reports is precisely the kind of work that rewards context-aware interpretation rather than rigid rules. The patterns are fuzzy — the same IP might be a legitimate relay for one client and an unknown source for another — and they shift as clients add senders and receivers update their behaviour. A system that can weigh context, learn the shape of a given domain's normal traffic, and surface the handful of findings that actually need a human decision is what keeps a growing MSP practice from drowning in its own report volume.
This is the argument for AI-assisted filtering in DMARC reporting, and it is not a marketing flourish. The cleaner standard reduces some of the raw inconsistency, but it does not eliminate the interpretive burden, because the messiness that remains lives in the delivery ecosystem rather than in the report schema. The DMARC AI approach is built around exactly this: ingest the reports, normalize the receiver differences, filter the forwarding and gateway noise, and present a per-sender, per-domain picture a technician can act on and a client can understand.
Where individual message inspection fits
Aggregate reports tell you the shape of a domain's traffic, but they never contain a specific message, so when a single send needs explaining you work from the message itself. That is where an email header analyzer earns its place: paste the headers of a real sample and read the actual SPF, DKIM and alignment results for that one message. Reports show you that a sender has a problem; header analysis on a sample often shows you why. Together they resolve most alignment mysteries a raw report alone would leave ambiguous.
What this means in practice
The takeaway is not that DMARC reporting is unreliable — it is that reporting is an input to be interpreted, not an answer to be displayed. RFC 9990 made the input better, but the job of turning reports into decisions did not go away, and for anyone managing DMARC across many clients, that interpretation layer is the service. Lead client reporting with conclusions rather than counts, be honest that reports reflect what receivers choose to send, and lean on tooling that normalizes the mess so engineers spend their time on the findings that matter.
Related articles
- RFC 9990 explained: DMARC aggregate reporting for MSPs
- Reading DMARC aggregate reports
- DMARC for MSPs — complete guide
Tools mentioned
- Email header analyzer — read the real SPF, DKIM and alignment results of a specific sample message.
Authoritative references
- RFC 9990 — DMARC aggregate reporting
- RFC 9989 — core DMARC protocol
- RFC 7489 — the obsoleted 2015 specification
Author: DMARC AI editorial team Last updated: August 2026