DMARC aggregate report reader
Upload DMARC XML and inspect sending sources and authentication results.
Your inputs
Your results
Ready when you areYour results will appear here.
How it works
Turn DMARC aggregate XML into a message-weighted sender summary and export every record. Grouping uses source IP and Header From domain; it does not identify an IP owner. DMARC succeeds when either the reported aligned DKIM result or the reported aligned SPF result passes. The reader accepts the RFC 9990 pass disposition and legacy none, alongside quarantine and reject. Disposition is kept separate from alignment. Reporting reference: https://www.rfc-editor.org/rfc/rfc9990.html.
A few things to know
Reads aggregate XML only, not forensic email, compressed archives, DNS or mailbox data. This is a structural reader, not full XSD validation. It supports unnamespaced reports and consistently namespaced feedback elements. Duplicate report identities within one submission are rejected; overlapping reporting periods across different report IDs can still double count traffic. Counts reflect the selected receivers and intervals, not all email sent or delivered. No provider attribution, threat classification or delivery guarantee. Files should be UTF-8 text. Reports are limited to 5 MB and 20,000 records; DOCTYPE/entity declarations are rejected.
When to use this tool
DMARC aggregate reports describe how a receiving service evaluated messages using your domain. Their XML can be difficult to scan directly. This reader groups reported traffic by source IP and Header From domain, weights results by message count and exports both a sender summary and individual records. It helps you investigate alignment problems without uploading the report, but it does not identify IP owners or classify traffic as legitimate or malicious.
- Identify reported sender combinations with alignment failures.
- Review the effect of a sending-provider configuration change across report files.
- Export aggregate records for a spreadsheet investigation before changing policy.
How to use dmarc aggregate report reader
Prepare plain XML reports
Extract ZIP or GZIP attachments yourself, then select the UTF-8 XML files. You may instead paste one complete feedback document. Selected files replace the pasted input; up to 20 files and 5 MB total are supported.
Read message-weighted results
Run the reader and inspect total messages, aligned pass percentage, failures and sender/From combinations. The summary uses policy_evaluated alignment results, not simply whether a raw authentication mechanism reported pass.
Investigate and export
Download the sender and record CSVs to compare known sending services with the observed IP/From combinations. Check reporting intervals before combining totals. Investigate legitimate failures before relying on an enforcement policy.
Understand the fictional aggregate report
Inputs
Load the built-in report: 120 messages pass aligned DKIM and SPF, 30 pass aligned DKIM only, and 10 fail both. The records cover two source IP/From combinations.
Result
The reader reports 160 messages, 150 aligned passes, 10 failures and a 93.75% pass rate. The two rows sharing the first IP and From domain combine into a 150-message sender summary.
What it means
The 30 DKIM-only messages still pass DMARC. Counting records instead of messages would distort the percentage, because the three records represent different traffic volumes.
Common mistakes to avoid
Confusing authentication with alignment
A raw SPF or DKIM pass can refer to a different domain from the visible From domain. The reader deliberately uses the report’s evaluated alignment fields.
Counting reports twice
Exact duplicate report identities in one submission are rejected. Distinct report IDs with overlapping periods can still double count traffic, so review dates and receiver coverage.
Naming a sender from its IP alone
The summary does not resolve IP ownership or prove authorization. Compare the reported combination with your sending inventory and provider evidence before drawing conclusions.
Frequently asked questions
Definitions, edge cases, and practical next steps for this tool. Search all tool FAQs ↗
What is a DMARC aggregate report?
It is a receiver-generated XML summary of observed messages and authentication evaluation. It groups multiple messages into records with counts, source IPs, domains and dispositions. This reader accepts aggregate XML, not forensic messages, inbox contents or a live DNS report.
How is the pass percentage calculated?
The tool sums message counts where either evaluated aligned DKIM or aligned SPF is pass, then divides by all reported messages. A record with 500 messages carries more weight than one with five. It does not average percentages across records.
Must both DKIM and SPF pass for DMARC?
For this report summary, either reported aligned mechanism passing is sufficient. The example’s 30 messages with DKIM pass and SPF fail therefore count as DMARC passes. Read the evaluated alignment fields rather than substituting raw authentication results from another report section.
Why do quarantine totals differ from failure totals?
Disposition is the receiving service’s reported handling decision, while failure describes alignment evaluation. Policy and receiver overrides can make those counts differ. Do not infer that every failure was rejected or that a nonrejected message passed alignment.
Can I upload compressed report attachments?
No. Extract ZIP or GZIP files first and select their plain XML contents. The browser reader accepts up to 20 files, five megabytes total and 20,000 records across the submission. It does not decompress archives or fetch reports from a mailbox.
Does the total represent all email I sent?
No. It represents the selected reports’ receivers and reporting intervals. Other receivers may not report, and the selected files may omit time periods. It is also not a delivered-message or inbox-placement count. Label any exported totals with their actual coverage.
What happens when reports have many senders?
The visible table shows up to 500 IP/From combinations, ordered by reported message volume. The sender CSV and record CSV retain the full supported submission. Download the files when investigating lower-volume combinations that do not appear in the preview.
What should I do with an unfamiliar failing source?
Check its From domain, report period and counts, then compare with your known services and recent changes. An unfamiliar source is an investigation lead, not an automatic threat label. This reader provides no provider attribution, signature verification or independent classification.
Explore the topic in the blog
Sources and method
Use the references below to check definitions and platform guidance. The model’s scope and limits are explained above. Read our editorial standards.