Free DMARC report analyzer

What this tool does

DMARC aggregate reports arrive as verbose XML (often gzipped) once a day from each mailbox provider. This analyzer parses one and shows, per sending source, how many messages were seen and whether SPF and DKIM passed and aligned — so you can spot the rows that need action. Learn the theory in how to read a DMARC aggregate report.

It reads aggregate (RUA) reports only. Forensic (RUF) reports use a different, per-message format and almost no provider still sends them, so there's nothing to gain from supporting it here.

Formats it accepts

Providers don't all deliver the XML the same way, so the tool handles the three shapes it actually shows up in:

• Plain .xml — paste it directly, or drop the file.
• .xml.gz — the most common form. The spec asks for it gzipped so a busy sending domain's daily report doesn't blow past a mailbox's attachment size limit; the tool decompresses it with the browser's native DecompressionStream, no library involved.
• .zip — a handful of providers wrap the XML in a zip instead of gzipping it. The tool reads the archive's central directory and inflates the one file inside.

Whichever format it arrives in, decompression and parsing both happen in this tab, and the file never leaves your browser. A report carries no message content, but it does list every sending IP that claimed your domain — infrastructure detail some teams would rather not hand to a third-party server just to read a table.

Reading the table

Each row is one sending source, grouped by IP address:

• Messages — how many the provider saw from that IP over the report's date range, not a running total.
• DKIM and SPF — the raw result for that mechanism, straight from the report's policy_evaluated block.
• Disposition — what the receiver actually did with the mail: none, quarantine, or reject, per your published policy.
• DMARC — pass if either DKIM or SPF passed and aligned; the report's raw fields don't state this outright, so the tool derives it.

A pass in one column and a fail in the other is normal, not a bug — see alignment for why a "passing" mechanism can still not count.

Which rows need attention

Most reports are mostly noise once you know what to skip:

• Both pass — legitimate, aligned mail. Nothing to do.
• One pass, one fail — DMARC still passes; worth fixing the failing mechanism before tightening policy, but not urgent.
• Both fail, source you recognise — a real sender you haven't authenticated yet. Add it to SPF or set up DKIM for it.
• Both fail, unfamiliar source — shadow IT, or someone spoofing the domain. This is the row DMARC exists to surface.

The full walkthrough, with the forwarding and mailing-list case that never quite clears up, is in how to read a DMARC aggregate report.

Analyzing one report vs. many

This is a handy one-off reader. Doing it across many domains, every day, from every provider doesn't scale by hand — that's what the self-hosted DMARC Analyzer automates, keeping the data on your own infrastructure. It's also free and open source.