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 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

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 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, 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). 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 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 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 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 covers each step, and how to read DMARC reports explains every field. Check the live record with the 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
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7489: DMARC, Appendix C (original aggregate report schema)
• RFC 9991: DMARC Failure Reporting