Read DMARC aggregate observations
Read local RUA XML or gzip batches with exact weighted observations, complete declared policy/authentication records and explicit duplicate-report handling.
- 1Add input
- 2Review and run
- 3Get your result
Tool input and files are processed in this browser without being uploaded.
Before you start
Inspect received aggregate reports locally. Keep receiver-stated DKIM/SPF alignment separate from raw authentication results and disposition, then download every source mapping, policy, row, authentication result and preserved XML infoset.
How to use this tool
- Select received local RUA XML or XML.gz reports.
- Compare receiver-stated alignment, raw authentication and disposition; inspect source deduplication.
- Download complete JSON/CSV to read every row and the full preserved XML infoset.
Supported inputs and limits
Select 1–100 XML or XML.gz files, at most 2 MiB encoded each and 80 MiB encoded total. Expanded XML is limited to 8 MiB per file and 80 MiB per batch; 10,000 total source records before deduplication, 200,000 XML elements and 64 levels. Complete JSON and CSV together are limited to 32 MiB. These limits apply together; source filenames have a protective 512 UTF-16-unit limit.
First release supports namespace-free RFC 7489 legacy reports and RFC 9990 reports in urn:ietf:params:xml:ns:dmarc-2.0, with their separate required fields, ordering, multiplicities and enums. RFC 9990 pass disposition remains distinct from none. Other core fields, namespaces, versions, missing alignment flags or unknown alignment values reject the entire batch explicitly; no inferred pass.
Only UTF-8 XML 1.0 and plain XML or validated gzip are supported; no ZIP input. Every gzip member, including concatenated members, is checked for framing, optional header CRC, full CRC and decoded size. Malformed encoding, DTD, custom entities and processing instructions are rejected. Links and foreign extension content remain inert, without network or DNS requests.
Report identity is organization, contact email, report ID, policy domain and declared begin/end. Identical expanded XML bytes under the same identity collapse once while retaining all source mappings. Different XML bytes with the same identity reject the whole batch, including differences in formatting or comments. Counts retain their original lexical form and exact decimal strings.
The JSON includes all metadata, policy, multiple DKIM/SPF results, reasons, declared foreign extensions in supported slots, and an indexed XML infoset preserving names, attributes, ordered mixed content and comments. XML line endings/entities/attribute values are normalized by parsing, and document-level whitespace outside the root is omitted; source and expanded-XML SHA256 retain byte identity. First release requires foreign namespaces in designated extension slots.
The table previews 200 rows and 2,000 UTF-16 units per cell; downloads contain complete records. Counts are observations across receivers, not unique emails. This reader does not verify DNS, signatures, delivery, compromise, sender ownership or report authenticity, and does not fetch reports. Whole-batch errors or cancellation return no partial successful output.
Worked example
Example input
One legacy report, one RFC 9990 report and a gzip copy of that same modern XML; eight source rows before duplicate collapse.
Example options
{}Example output
Two unique reports, five rows and 19 message observations: 14 receiver-stated aligned pass and 5 aligned fail; disposition none has 9 observations and pass has 7. The duplicate source remains mapped.
When something does not work
Correct an incomplete report with its provider, remove a contradictory duplicate or reduce the batch/expanded structure/output size, then retry the same supported files. Unknown fields or failed gzip CRC are explicit whole-batch refusals.
Frequently asked questions
Does disposition none mean the row failed DMARC?
No. Disposition and receiver-stated aligned DKIM/SPF flags are separate fields. The reader counts aligned pass when either receiver alignment flag is pass; it does not infer alignment from raw authentication or disposition.
Are the totals unique delivered messages?
No. They are weighted row observations across exact unique reports and receivers. The same message can be observed by more than one receiver; duplicated identical report files are collapsed with every source mapped.
Why does a report with missing alignment fail?
The receiver did not provide the supported explicit pass/fail alignment facts. The batch is refused as incomplete or unsupported rather than presenting unknown alignment as a pass or guessing from raw authentication.
Documentation & further reading
Related tools
IPv4 subnet and netmask calculator
Calculate IPv4 subnet boundaries and usable endpoints, or convert a netmask and prefix.
IP range to CIDR
Turn an inclusive IPv4 address range into the smallest exact list of CIDR blocks.
Aggregate CIDR blocks
Reduce an IPv4 CIDR list without changing its address coverage.
IPv4 number converter
Convert one IPv4 address between dotted decimal, unsigned integer and 32-bit binary.