# DMARC Report Analyzer

URL: https://iblockspam.com/tools/dmarc-report-analyzer
Last updated: 2026-10-09

> Drop in the DMARC aggregate reports you receive and see who sends mail as your domain, which sources pass, and what to fix before you move to p=reject.

Free tool: Read DMARC aggregate reports (XML, gzip or zip): see who sends as your domain and what fails — runs in your browser. Use it at https://iblockspam.com/tools/dmarc-report-analyzer

## What the DMARC Report Analyzer does

When your DMARC record has a `rua` address, receiving mail systems send you aggregate reports: XML files that list each IP address that sent mail using your domain in the From address, how many messages it sent, and whether SPF, DKIM and DMARC passed. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) describes them as "daily (or more frequent)" reports and says a period typically covers a single UTC day. Each receiver sends its own file, so a busy domain collects many of them.

The files are hard to read by hand. The analyzer opens them and shows:

- **Report details:** the reporting organization, the date range, and the policy the receiver found in your DNS (`p`, `sp`, `np`, `adkim`, `aspf` and, in older reports, `pct`).
- **Totals:** messages, the share passing DMARC, aligned DKIM and SPF pass rates, and what receivers did with the mail (none, quarantine, reject).
- **Every sending source:** IP address, message count, the receiver's action, DKIM and SPF results with the domains they were checked against, and the header From and envelope From domains.
- **A summary in three groups:** passing and aligned, failing but likely legitimate (to fix), and failing with no authentication at all (likely spoofing).
- **Next steps toward p=reject,** based on your current policy and what the reports show.

You can filter the table and download it as a CSV file.

**It runs in your browser. Nothing is uploaded.** Files are decompressed with your browser's built-in decompression and parsed with its XML parser. Report content is shown as plain text and never interpreted as HTML, because anyone can email a "report" to a published `rua` address.

## Which files it accepts

| File | Notes |
|---|---|
| `.xml` | A plain aggregate report. |
| `.xml.gz` or `.gz` | Gzip-compressed XML. RFC 9990 says the XML "SHOULD be subjected to GZIP compression", so this is the standard form. |
| `.zip` | Zip archives with stored or deflate-compressed entries, as several large mailbox providers send. Every report inside is read. |

RFC 9990 names report files `receiver!policy-domain!begin-timestamp!end-timestamp.xml.gz`, so the file name alone tells you who sent it and for which period.

Both report formats work: the original schema in [RFC 7489 Appendix C](https://www.rfc-editor.org/rfc/rfc7489.html#appendix-C) and the RFC 9990 schema, which adds a namespace (`urn:ietf:params:xml:ns:dmarc-2.0`) and fields such as `np`, `testing` and `discovery_method`. Only aggregate (rua) reports are supported. Failure (ruf) reports are individual messages described in [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html), not XML summaries.

## How to read the results

DMARC passes when SPF or DKIM passes **and** the passing domain aligns with the domain in the From header ([RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)). In each row, "aligned pass" or "not aligned" is the receiver's verdict; the lines underneath show the raw results and the domains they were checked for.

### Passing, aligned

DKIM or SPF passed for your domain. Nothing to do for these sources.

### Failing, likely legitimate

The analyzer puts a failing source in this group when:

- **It authenticated as another domain.** SPF or DKIM passed, but for the sending service's own domain, not yours. This is the classic marketing, CRM or helpdesk tool. Set up DKIM with your domain in that service, or a custom return-path, so it aligns.
- **The receiver noted forwarding or a mailing list.** The `reason` field says `forwarded`, `mailing_list` or `trusted_forwarder`.
- **Your own DKIM signature failed.** The message carried a signature for your domain that no longer verified, usually because a forwarder, list or gateway changed it. Our guide on [why forwarding breaks SPF and DMARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) explains why.
- **The same IP also sent passing mail.** It's probably one of your servers with a partial setup.

### Failing, likely spoofing

Nothing authenticated for any domain, and the IP never passed in the reports you loaded. These are usually forged messages, the mail DMARC enforcement exists to stop. A source you recognize can also land here if it has no SPF or DKIM at all, so check the IP and envelope domain before you dismiss a row.

These groups are estimates from the report data, not proof. Look up any source you don't recognize: the [PTR Lookup](https://iblockspam.com/tools/ptr-lookup) shows a server's reverse DNS name.

## From reports to p=reject

1. Publish DMARC with `p=none` and a `rua` address, then collect reports for a few weeks. The [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator) builds the record.
2. List every legitimate source in the reports and fix each one until it passes with alignment.
3. Move to `p=quarantine` and keep reading reports.
4. When no legitimate source fails, move to `p=reject`.

Our guide on [moving from p=none to p=reject](https://iblockspam.com/blog/dmarc-none-to-reject-small-business) covers each step, and [how to read DMARC reports](https://iblockspam.com/blog/how-to-read-dmarc-reports) explains every field. Check the live record with the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker).

## Limitations

- It shows what receivers reported. Not every receiver sends reports, so some mail never appears.
- Report data can be forged. Anyone can email an XML file to your `rua` address, so treat an odd report with care.
- The "likely legitimate" and "likely spoofing" groups are heuristics. Alignment is approximated by comparing domains and subdomains, without a full public suffix check.
- Up to 50 MB of files at a time, and up to 100 MB per report once decompressed. Split larger sets into batches.
- Results disappear when you leave the page. For continuous reporting, iBlockSpam customers can turn on hosted DMARC monitoring, included with every plan.

## Sources

- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html)
- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 7489: DMARC, Appendix C (original aggregate report schema)](https://www.rfc-editor.org/rfc/rfc7489.html#appendix-C)
- [RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html)

## Frequently asked questions

### Are my DMARC reports uploaded anywhere?

No. The analyzer runs entirely in your browser. Files are read, decompressed and parsed on your device with JavaScript, and nothing is sent to our servers. You can close the page and the data is gone.

### Which report files can I open?

Aggregate (rua) reports as plain .xml, gzip-compressed .xml.gz or .gz, and .zip files with deflate or stored entries, which covers the attachments most large receivers send. Both the older RFC 7489 format and the RFC 9990 format work. Encrypted and ZIP64 archives aren't supported.

### Why does a legitimate service fail DMARC when SPF or DKIM passes?

DMARC needs alignment: the domain that passed SPF or DKIM must match the domain in the visible From address. Many services sign with their own domain or use their own bounce address. Set up custom DKIM for your domain in that service so its mail aligns.

### Can I open several days of reports at once?

Yes. Choose or drop many files together, up to 50 MB at a time. The analyzer merges them into one view, adds up messages per sending source, and skips duplicate copies of the same report so nothing is counted twice.

### How do I know when it's safe to move to p=reject?

When reports from all your receivers show that every legitimate source passes with alignment, over several weeks that include your less frequent senders, such as invoicing or monthly newsletters. Go through p=quarantine first and keep reading reports after each change.

---

Source: iBlockSpam, https://iblockspam.com/tools/dmarc-report-analyzer (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt