DMARC Aggregate Report Viewer
Free DMARC aggregate report viewer. Open a DMARC RUA XML report and see a per-source-IP pass/fail summary, parsed entirely in your browser.
What an aggregate report actually is — and isn't
A DMARC aggregate (RUA) report is an XML document a receiving mail provider periodically sends to a domain that has DMARC configured, summarizing every source IP that sent mail claiming to be from that domain during the reporting window, along with whether each source passed SPF/DKIM alignment. It's not a per-message log or a list of individual emails — it's aggregated counts, grouped by source IP and disposition, which is both more privacy-preserving and far more practical to review than a raw stream of individual message events. This is exactly the data that makes running DMARC at `p=none` genuinely useful before enforcing anything: it's how a domain owner discovers every legitimate sending source (and every unauthorized one) without having to guess.
Why gzip decompression happens locally, not via upload
Most mail providers send aggregate reports as gzip-compressed XML by default to save bandwidth, which means a tool reading them either needs to decompress that gzip stream itself or require the user to manually extract the archive first. This tool uses the browser's native `DecompressionStream` API to decompress gzip data entirely client-side — the compressed bytes never leave your machine, uploaded to no server, which matters because a DMARC report can reveal real infrastructure details (every IP that sends mail for a domain) that a domain owner would reasonably not want passing through a third party just to read a report their own mail provider sent them.
Reading disposition and alignment together
The disposition field (`none`, `quarantine`, `reject`) reflects what the *receiving* server actually did with mail from that source based on the domain's published policy, while the DKIM/SPF alignment columns show whether that source actually passed authentication. A source failing alignment with disposition `none` is being let through anyway (because the domain's policy is still in monitoring mode) — exactly the visibility needed to catch a legitimate sending source that would break if the policy were tightened to `quarantine` or `reject`, before that tightening actually happens and starts silently dropping real mail.