What is inside an aggregate report
Every receiver that honours your rua tag sends one XML file per reporting period, usually a day, in the format described in RFC 7489 Appendix C. It carries report_metadata (the reporter's org_name, contact email, report_id and the begin and end timestamps), policy_published (the p, sp, pct, adkim and aspf values the receiver saw) and a list of record elements.
Each record is one source_ip with a count, a policy_evaluated block (disposition plus the aligned dkim and spf verdicts), identifiers (header_from and sometimes envelope_from) and auth_results listing each DKIM signature domain and selector with its result, and each SPF domain with its result. The analyzer reads exactly these fields and nothing else.
How files are read without leaving your browser
A dropped file is identified by its first bytes: a zip signature, a gzip signature, or plain XML. Gzip members and deflate-compressed zip entries are inflated with DecompressionStream, every .xml entry in a zip is parsed, and a zip with no .xml inside is reported as an error. The XML goes through the browser's DOMParser, and a file without a feedback element is rejected as not a DMARC report.
Reports with the same reporter and report_id are kept once, so dropping the same attachment twice does not double the counts. The date range at the top spans the earliest begin and the latest end across all files, and Download JSON exports the parsed reports for a spreadsheet or a script.
Reading the tiles and the sources table
Messages is the sum of every count, with the number of distinct source IPs beneath it. DMARC pass is the share of messages where an aligned check passed. It is green from 95 percent, amber from 80 and red below that. DKIM aligned and SPF aligned break the same figure down per mechanism, which shows at a glance whether forwarding (SPF fails, DKIM passes) or an unsigned service (both fail) is the problem.
The sources table is sorted by message count. The DMARC pill is green when every message from that IP passed, red when none did and amber for a mix. Hover the DKIM or SPF cell to see every signing or envelope domain the reporters recorded. The first one is printed under the percentage. Header From lists the From domains seen from that IP, which is how you catch a subdomain or a look-alike being used.
Turning rows into fixes
Filter to failing sources. For each IP, decide whether it is yours: open it in the IP Lookup to see the owning network, and match it against the services you pay for. A known service that fails SPF needs its include added with the SPF Generator. One that fails DKIM needs signing switched on in that service and the selector verified with the DKIM Checker.
Forwarders, mailing lists and some ticketing systems resend your mail from their own IPs, so SPF fails and only DKIM can carry the message through. That is why DKIM on every sender comes before p=reject. When the failing rows are all unknown IPs using your From domain, you are looking at forgery, and tightening the policy is the fix.
- Known IP, SPF fails: add the service's include to your SPF record.
- Known IP, DKIM fails: enable signing there and check the published key.
- Unknown IP, your From domain: forgery. Move toward quarantine or reject.
What the reports do not show
Aggregate reports contain no message content, subjects or recipient addresses, only counts per IP, so you cannot trace an individual complaint through them. They also arrive a day or more after the mail was sent, and the Published policy card reflects what the first loaded reporter saw, which can lag behind a DNS change you made yesterday.
Not every receiver sends reports, so the totals cover the providers that do, and a small sender may see nothing for days. The loaded data stays in the page until you press Clear or reload. It is never sent to DNSfinder.