A DMARC aggregate report is what the receiver sends back to the address in your rua= tag once a day. It arrives as an XML file, usually gzipped or zipped, and it is the only unfiltered window you have into who is sending as your domain across the whole receiver. Nobody reads them because nothing about the format was designed to be read. Fifty lines per <record>, timestamps in epoch seconds, alignment verdicts one-word deep in a policy sub-element, and none of it grouped by sender.
This reader parses the XML in your browser and prints the useful bits: who reported, what your policy is, the volume rollup by disposition, the list of sending IPs with their alignment verdicts, and — the reason to open one of these in the first place — the list of sources that sent mail as your domain without aligning either SPF or DKIM. Those are your investigation targets.
Parsed with DOMParser in your browser. This plugin serves no
upload endpoint; there is no POST target and the report never crosses the
network. Reverse-DNS hints are matched from any rdns-style
string the report already contains — there is no live PTR lookup.
Browser-only
The plugin registers no upload endpoint. There is no POST target, no XHR to a server we control, no telemetry. The file is read into memory by the browser, DecompressionStream unpacks gzip and zip natively, DOMParser walks the XML tree, and the results render into the page. If you close the tab, the report is gone.
DMARC reports contain the IP addresses and volumes of every sender on your domain, including internal marketing tools and any legitimate service you would rather not name in a support ticket. Third-party dashboards have a place — long-term trend graphs, cross-reporter aggregation, TLS-RPT integration — but the ad-hoc read of one report does not need to leak that data to a vendor. This tool exists for that read.
What the summary tells you
Report header. Reporter (Google, Yahoo, Microsoft, Mailgun’s mailmonitor.io — whoever holds the receiving mailbox that got your rua= traffic), report ID, date range in your local timezone, the domain the policy is being applied to, and the published policy including p=, sp=, pct=, and the adkim/aspf alignment mode.
Volume by disposition. The <policy_evaluated><disposition> field on each record is the receiver’s decision — none, quarantine, or reject — bucketed and shown with counts and share. p=none reports show everything as none regardless of alignment; that’s expected and not a problem in itself.
Sending sources. One row per source IP, with the total messages that IP sent during the window, the DKIM-aligned share, the SPF-aligned share, and every disposition the IP got. Ranked by volume so the loudest senders are at the top.
Alignment failures. Any source IP whose messages aligned on neither SPF nor DKIM. If your domain has ever sent mail through a service you no longer use, these are where it shows up. If a spammer is spoofing you, this is also where they show up. The tool does not distinguish between the two — that’s your job, and the whole point of running p=none first is to build the list before tightening the policy.
Narrative. A short paragraph summarising the numbers and calling out any recognised sending providers in the misaligned list. Recognised providers link to the nanoPost review, which has the DKIM setup for that specific provider.
What the tool does not do
- No live reverse-DNS lookup. Some receivers include an
rdnselement or put a hint inenvelope_from; the tool matches on what the report already contains. It won’t query PTR records for you. - No cross-report aggregation. Each report is read in isolation. If you want trend lines across weeks of Google + Yahoo + Microsoft reports combined, use a paid dashboard.
- No TLS-RPT or SMTP-TLS report parsing. That’s a separate report type with a different XML shape.
Related tools
When you are ready to check what receivers actually resolve for your domain, the DNS Auth Checker reads your live SPF, DKIM, and DMARC records over DNS-over-HTTPS and scores them against the Gmail, Yahoo, and Microsoft 365 bulk-sender requirements. If this reader turned up a new legitimate sender you need to add to SPF, the SPF Record Merger will fold the provider’s include: into your existing record without blowing the RFC 7208 10-lookup ceiling. And if a specific bounce message is what surfaced the DMARC investigation in the first place, the SMTP Error Decoder maps common SMTP reply codes to the actual fix.