Free DMARC Report Analyzer

What a DMARC aggregate report actually contains

Every receiver that supports DMARC — Google, Yahoo, Microsoft, AOL, Mail.ru, Yandex, and dozens of smaller ones — sends a daily XML report to the address in your `rua=mailto:` tag. The format is defined in RFC 7489 Appendix C. It's not designed to be read by humans. Each report covers one day of mail observed from your domain at that single receiver, and looks roughly like this:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1704067200</begin><end>1704153600</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>
      <count>42</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
    ...
  </record>
</feedback>

The interesting part is the `<record>` blocks. Each one represents N messages from one source IP to that receiver, with the authentication result. Roll those across multiple reports and multiple receivers and you get a real picture of who's sending mail using your domain — including senders you don't recognize.

Why most reports come as .xml.gz

Reporters gzip the XML before sending to keep the email payload small. A typical Google daily report is 20–50 KB compressed and 200–500 KB uncompressed. You'll see filenames like `google.com!example.com!1704067200!1704153600.xml.gz`.

This tool unzips `.gz` natively in your browser — no need to decompress first. Drop the file in straight from your email attachment download. (Microsoft sometimes sends `.zip` archives containing the XML — unzip those once and upload the XML inside.)

The four buckets we sort each sending source into

Looking at a per-IP table of pass/fail rates isn't actionable. We classify each source IP into one of these buckets so you know what to do with it:

The classifier looks at DKIM signing domains, SPF return-path domains, and a list of around 25 known ESPs (SendGrid, Mailchimp, SES, Mailgun, Postmark, etc.) to decide which bucket fits. It's a heuristic — we show the raw numbers next to every verdict so you can second-guess us.

How to read the failure summary

When a record shows DKIM `fail` or SPF `fail`, the cause is almost always one of these:

• SPF not authorized — the sending IP isn't covered by your SPF record's mechanisms. Use the SPF Syntax Validator to walk through every `include:` chain and find what's missing.
• SPF aligned but soft-failing — your record uses `~all` or `?all`. Receivers report 'softfail' which DMARC treats as a fail for alignment purposes.
• DKIM signature missing — the sender isn't signing at all, or is signing with the provider's domain instead of yours. Re-enable DKIM signing in your ESP and point it at your domain.
• DKIM signature broken — the signature was applied but failed validation. Usually a footer-injection rewrite (some mailing platforms add unsubscribe text after signing) or a body-canonicalization mismatch.
• DKIM key not found — selector is signing but the public key isn't published at `<selector>._domainkey.<your-domain>`. Re-publish the TXT record your ESP gave you.
• Subdomain alignment mismatch — your `From:` is `marketing.example.com` but you're signing with `example.com`. Use `adkim=r` (relaxed) instead of `adkim=s` (strict) in your DMARC record.

When to move from p=none → p=quarantine → p=reject

A DMARC rollout is a careful ratchet. Push to enforcement too soon and you bounce legitimate mail. Stay at observation too long and you stay vulnerable to spoofing. The right cadence:

If you don't have a DMARC record published yet, build one first with our DMARC Record Generator. If you have one but you're not sure what it says, the DMARC Record Checker parses it in plain English.

What this analyzer doesn't do (and what to use instead)

Three deliberate omissions worth knowing about:

• No RUF (forensic) report parsing yet. RUF reports are per-message failure samples with redacted headers. Most receivers stopped sending them years ago for privacy reasons. If you need them, paid services like Dmarcian and EasyDMARC still aggregate the trickle that remains.
• No reverse-DNS for source IPs. A PTR lookup would tell you that `198.51.100.10` is `mail.acme.io` — useful context. We skip it because doing it client-side without a CORS proxy is impossible, and the obvious next step (a server function) drags this tool out of the 'no backend' category. Look up unfamiliar IPs in our IP Lookup tool separately.
• No historical persistence. Each upload analyzes the files in front of it. There's no 'last 30 days' dashboard because we don't store anything — everything runs in your browser tab. Save the JSON export if you want a record.

Privacy: nothing leaves your browser

DMARC reports contain real source IPs and per-message counts. Uploading them to a third-party service means handing over a list of every IP that ever sent mail using your domain — that's a meaningful security disclosure. This tool runs entirely in your browser tab. XML parsing uses native DOMParser. Gzip decoding uses native DecompressionStream. There is no network request to our servers when you analyze a report.

When you click Export → CSV or Export → JSON, the file is generated in your browser and downloaded to your machine via a blob URL. We never see the contents.