DMARC Aggregate Report Analyzer

Mail from one domain may come from a staff mailbox service, an invoicing platform and a newsletter provider. DMARC aggregate reports show which connecting IP addresses receiving mail systems observed, how the messages were evaluated and what DMARC handling was reported. They help domain administrators find unfamiliar senders and check whether legitimate services are configured consistently.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It connects email authentication to the domain in the visible From address, lets domain owners publish handling preferences and provides a way to request feedback. Understanding the authentication checks makes that feedback much more useful.

SPF

Sender Policy Framework checks whether the sending IP address is authorized for the envelope sender domain used during mail delivery. That domain can differ from the visible From domain.

DKIM

DomainKeys Identified Mail checks a cryptographic message signature associated with a signing domain. A valid signature establishes authentication for that signing domain.

Alignment

Alignment connects an authenticated SPF or DKIM domain to the visible From domain under DMARC's domain-matching rules.

A passing authentication check qualifies for DMARC only when its authenticated domain aligns. One aligned SPF or DKIM pass is sufficient. For example, a valid DKIM signature from a provider's unrelated domain cannot by itself establish a DMARC pass for your own From domain.

Aggregate reports group messages with shared source and authentication characteristics into records. One record can represent many messages, and one sending IP can appear in several records. Message counts therefore determine traffic proportions; counting records gives each group equal weight regardless of how much mail it represents.

Failures deserve investigation before attribution. A legitimate service may authenticate using its own unrelated domain, forwarding can disrupt SPF, and changes made by a mailing list can invalidate DKIM. Unauthorized mail can also fail. The reported source IP identifies the system connecting to the receiver, which may be a relay or forwarder.

The published policy expresses the domain owner's handling preference, such as no special DMARC action, quarantine or rejection. The disposition records the receiver's reported DMARC handling. Receiver policies and overrides can affect that handling, so authentication results and dispositions answer different questions.

Reporting coverage also changes the meaning of a percentage. A set of aggregate reports describes the observations supplied by particular receivers during particular periods. Missing receivers or gaps between periods limit how well those observations represent a domain's overall mail traffic.

How to Use This Tool:

Start with aggregate reports already saved on your device. A synthetic current-format report is staged initially. Load sample replaces the selection with current and legacy examples and analyzes them automatically.

1. Choose your .xml or .xml.gz files with Browse files, or drop them together into the report area. Choosing files replaces the previous selection and clears its results.
2. Select Analyze reports to read the staged files. The feedback identifies how many reports were accepted.
3. Review Coverage ledger for each file's decision and reason before relying on the totals.
   For rejected files, follow the stated reason: supply valid UTF-8 XML, correct missing report fields or reduce the selection to fit the limits. If gzip support is unavailable, decompress the report locally and select its XML file.
4. Resolve any conflicting report identity by choosing the version you can verify, or select Exclude this identity. The choice immediately recalculates which reports contribute.
5. Select the relevant Policy domain. Its summary and results use only accepted reports for that domain.
6. Enter an optional IP fragment in Advanced under Source IP contains to narrow Sending sources and Reported records. Domain totals, dispositions and the chart remain unfiltered. Clear the filter to restore all sources if nothing matches.

Interpreting Results:

Sending sources puts the largest failed-message contributors first, using total message count to break ties. Read the failed count alongside the source's pass rate. A percentage describes that source's mix of outcomes, while the count shows its contribution to the reported failures.

• For a source with failures, inspect its Reported records and compare the From domain, raw authentication domains and override reasons with your known sending services and representative message headers.
• Unclassified identifies incomplete or unknown reported alignment evidence. Check the affected records before treating those messages as either confirmed passes or confirmed failures.
• Read Dispositions as reported receiver handling. A value of none alone does not establish an alignment pass or failure.

Source alignment shows the first ten sources in the same failure-based ranking. Additional IPs are combined into Other sources, preserving their passed, failed and unclassified message counts.

An analysis can produce usable totals while some files remain invalid, excluded or unresolved. The accepted filenames in the summary and the decisions in Coverage ledger establish what the totals cover.

A high pass rate describes the accepted reported traffic. Inbox delivery, message safety and readiness to strengthen a DMARC policy require additional evidence. Review legitimate sending services and representative reporting periods before making policy changes.

Technical Details:

Reported DMARC alignment reflects the receiver's authentication and domain-matching decisions. Strict alignment requires the authenticated domain to equal the From domain. Relaxed alignment requires a shared organizational domain, the administrative boundary determined under DMARC's discovery rules. The analysis uses the reported outcomes without recalculating those domain relationships.

Reported alignment rules

The dkim and spf values inside policy_evaluated provide the aligned outcomes. Separate auth_results entries describe raw authentication. Classification uses the exact lowercase values pass and fail from the aligned outcomes.

Unclassified is a description of incomplete evidence in this analysis. A raw authentication pass, an unfamiliar value or a reported disposition does not replace a missing aligned result. A record can still pass when one aligned mechanism reports pass and the other is missing.

Formula Core

Each accepted record contributes its reported message count. For one policy domain, total messages equal the sum of those counts and the sum of the three classification totals.

Here, n is the number of accepted records, c_i is a record's message count, and T is total messages. P, F and U are the passed, failed and unclassified message counts.

The pass rate R is the percentage of all reported messages in that accepted scope classified as passing. Unclassified messages remain in the denominator.

Zero reported messages produce no rate. Counts remain whole integers, and percentages are calculated from unrounded totals before display rounding to at most two decimal places. A source's pass rate uses the same equation with that source's message counts.

Aligned DKIM and aligned SPF pass subtotals can include the same messages. Adding them can double-count messages that pass both mechanisms; the overall pass total counts each accepted record's message weight once.

Each reported policy domain has its own denominator. Policy-domain names are lowercased and one trailing dot is removed for grouping. A parent domain and its subdomain retain separate totals when their reported policy domains differ. Several From domains may contribute to one policy domain, with the individual From domain retained in each record.

Report identities and coverage

For this analysis, a report identity combines the reporter organization, reporter contact address, normalized policy domain, report ID and beginning and ending timestamps. Matching identities with matching XML content contribute once. When the same identity has different content, every variant is withheld until one is selected or the identity is excluded.

Content comparison ignores namespace-prefix spelling, namespace declarations, comments and surrounding formatting whitespace. Differences in text, attributes, child order or extensions can still create a conflict, even when the message totals match. Identical copies of the selected variant remain duplicates; alternative variants remain excluded.

Distinct report identities can cover overlapping periods and still contribute their full counts. An overlap is flagged within a policy domain when each period begins before the other ends, including reports from different receivers. Periods that only touch at an endpoint do not trigger this warning. The overlap does not prove that individual messages are duplicated, and no message-level deduplication is performed.

The overall coverage span runs from the earliest accepted beginning to the latest accepted ending. It can contain gaps. Comparing pass rates across different report sets therefore requires checking the contributing receivers, accepted files and reporting periods as well as the percentages.

Current and legacy dispositions

Current RFC 9990 reports use a feedback root in the namespace urn:ietf:params:xml:ns:dmarc-2.0. Supported legacy reports have no namespace or use dmarc.org's legacy dmarc-xml/0.1 namespace. They are labeled Legacy RFC 7489.

Disposition totals preserve both the reporting standard and the reported action. This matters because the current format has an explicit pass disposition that the legacy format lacks.

The published policy describes the receiver's reported policy information for that period. It does not override the recorded alignment results, and a reported legacy policy percentage does not rescale the message counts. Disposition labels are retained as reported without checking that they agree with the published policy or aligned outcomes.

Structural acceptance

Accepted reports require reporter identity and period information, a published policy domain and policy value, and at least one record containing a source IP, message count, policy evaluation, From domain and raw-authentication container. Required elements must appear at their expected locations in the matching namespace. Missing required fields, repeated single-value core fields and invalid counts, periods, source IPs or policy domains reject the file.

Missing aligned outcomes and an empty raw-authentication container can be retained as incomplete evidence. Unsupported fields and extensions are ignored with notes and cannot supply missing core values. Unrecognized policy values and report versions are also noted. Acceptance establishes only the supported structural checks; full XML Schema conformance and reporter authenticity remain unverified.

Limits and Privacy:

Input is limited to local UTF-8 XML and gzip-compressed XML with .xml or .xml.gz filenames. ZIP archives, saved email messages, failure reports and pasted XML are outside the supported input paths. These bounds apply before report acceptance.

One MiB is 1,048,576 bytes. Gzip decompression stops if a decoded size limit would be exceeded. Corrupt or truncated gzip, malformed XML, non-UTF-8 encodings, document type declarations and entity declarations are rejected. Policy domains must use valid ASCII DNS labels and fit within 253 characters. Source addresses must be valid IPv4 or IPv6; equivalent IPv6 spellings are grouped together.

Report contents are processed in the current browser tab without upload. The tool does not save report data in browser storage or place it in the page URL. Clear removes the selected files and results. Normal page and chart assets may still load over the network.

Copied or downloaded results can contain domains, IP addresses, reporter contacts and filenames. The JSON audit omits raw XML but includes the selected domain's totals and all supplied-file decisions. Its source and record lists follow the current IP filter, while its domain totals remain unfiltered. The analysis does not access a mailbox, query DNS, reauthenticate senders or change a DMARC policy.

Worked Examples:

References:

• RFC 9990: DMARC Aggregate Reporting, IETF, May 2026.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance, IETF, May 2026.
• RFC 7489, Appendix C: Legacy DMARC XML Schema, RFC Editor, March 2015.
• RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows, IETF, September 2016.