An aggregate report is receiver telemetry, not a mailbox export
DMARC aggregate reports summarize how a receiver observed mail using a domain during a reporting period. They contain counts, source IP information, the published policy and SPF/DKIM evaluation data. They are designed to show patterns across mail streams rather than expose the message content of individual emails. RFC 9990, published alongside the updated DMARC specification in 2026, now defines the aggregate reporting format separately from the core DMARC protocol.
Start with volume before judging a source
A source IP that produced two failures should not automatically receive the same priority as a source responsible for hundreds of thousands of messages. Aggregate the report by source, header_from identity, disposition and failure reason. Then compare the failed volume with the total volume seen for that stream. High-volume legitimate infrastructure with partial failures often points to a configuration inconsistency, while a small unknown source may be spoofing or an overlooked service.
Separate authentication failure from alignment failure
A row can show that SPF or DKIM failed outright, but the DMARC decision also depends on whether a passing authenticated identifier aligns with the visible From domain. When the report indicates a DMARC failure, investigate the underlying authentication results and the domains they used. A third-party sender may be fully capable of SPF or DKIM authentication while still failing DMARC because its default identity does not align with the brand domain.
Dispositions tell you what happened to the policy evaluation
The policy-evaluated portion records the receiver’s DMARC disposition such as none, quarantine or reject, together with SPF and DKIM outcomes. Do not read a disposition in isolation. Policy overrides, forwarding and local receiver behavior can affect how a message is ultimately handled. Aggregate-report analysis should therefore summarize both requested policy and observed evaluation rather than turning every non-none disposition into a delivery guarantee.
Use reports to build a verified sender inventory before enforcement
The safest path from p=none toward enforcement is to classify legitimate sources, repair missing or unaligned authentication, and watch enough reporting periods to understand recurring and infrequent mail streams. Payroll, support systems, annual notifications and incident tooling can be easy to miss because they send irregularly. Aggregate reports are valuable precisely because they reveal sources that a DNS-only inventory or administrator memory may not capture.
Treat report data as sensitive infrastructure telemetry
Aggregate reports are less privacy-sensitive than message-level failure reports, but they still reveal sending sources and domain relationships. Store uploaded reports only as long as needed, avoid exposing source inventories publicly, and distinguish observed receiver data from inferred provider labels. Mailybox’s analyzer summarizes the XML locally through its report parser and presents the most important source, volume and authentication patterns without pretending that a single file proves long-term sender behavior.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.