Read an aggregate XML report’s date range, source counts, policy and alignment results.
Your entries stay in this tab. Not sent to or saved by Sky. Export or print before closing or reloading, or your entries will be lost. Do not include passwords, API keys, recipient lists or private logs.
A DMARC aggregate report summarizes messages a receiver observed using your domain. This analyzer reads one XML report in your browser; it does not authenticate the reporter, query DNS, or check delivery.
A successful parse shows DMARC aggregate report analyzed, Analysis status: Analyzed locally, and Processing: Browser only. This confirms the XML was read, not that your domain passed DMARC. Failed alignment can show Analyzed · review needed and DMARC alignment failures are reported. Bad input shows Input needs correction; a missing browser parser shows Unavailable.
Technical details show Reporting organization, Reporting email, Report ID, and Reporting period (UTC). The period comes from date_range. It describes the reporting window, not necessarily the first and last message observed. The analyzer does not verify who sent the file.
Published domain names the policy domain in the report. Published DMARC policy shows policy values supplied in the XML. Source rows counts summarized records; Reported message count totals their message counts. A row groups an observed source IP with identifiers and authentication results, rather than describing one individual email.
In Result detail, compare policy_evaluated DKIM and SPF values with the separate raw authentication results. A raw pass may still be unaligned with the From domain. The warning counts rows with a failed alignment result. Reported message dispositions are report values, not a live delivery check. The tool accepts core 0.1 and 2.0 XML, but rejects extensions and other variants. Use plain, uncompressed XML within the displayed 1 MB and 2,000-record limits.
Usual cause: SPF authenticated the envelope domain, but that domain did not align with the message’s From domain under the published mode.
Fix: Compare header_from with the SPF domain in the row. Align the SPF identifier or use a passing, aligned DKIM signature. Check relaxed or strict alignment before changing records.
Usual cause: Its envelope or DKIM signing domain may not align with From, or its authentication setup may be incomplete.
Fix: Match the source IP and count to your sending inventory. Compare raw authentication with policy_evaluated alignment, then correct the sender’s configuration and review a later report.
Usual cause: It could be a forgotten service, a delegated sender, or unauthorized use of your domain.
Fix: Compare the IP, identifiers, period, and count with authorized services and mail logs. Confirm with the system owner before changing policy; one report does not identify who controlled the sender.
Usual cause: It may be compressed, malformed, too large, or contain extensions or a schema variant the analyzer does not accept.
Fix: Open the plain XML attachment, not an archive. Check the displayed size and record limits. Do not remove fields by hand; ask the report sender for a supported export if needed.
Usual cause: The policy may lack a report destination, the address may be wrong, or the receiver may not send reports.
Fix: Check the published rua destination and mailbox. If it is in another domain, confirm DNS authorization with that domain’s administrator. Ask the receiver whether it supports reports.
192.0.2.11 — 2 messages; policy_evaluated: DKIM alignment=fail, SPF alignment=fail; header_from=example.com, envelope_from=example.net; SPF authentication: example.net (mfrom) pass.SPF passed for example.net, but the report says that domain did not align with example.com. Without a passing aligned DKIM identifier, DMARC can fail. Read policy_evaluated for alignment and auth_results for raw authentication; do not treat them as the same result.
Check the reporting period and published domain, then review each source row’s IP, count, identifiers, raw authentication, and policy_evaluated alignment. Compare recurring sources with your sending inventory. It is a receiver’s summary, not a message-by-message trace.
SPF pass verifies the domain used for SPF. DMARC also requires that domain to align with From, unless an aligned DKIM signature passes. A non-aligned SPF pass alone is not enough.
Mail-receiving organizations send aggregate reports to the destination requested in the domain’s DMARC policy. Sky’s analyzer only reads your file; it does not collect or send reports.
The standards describe daily or more frequent reports and recommend receivers send them at least every 24 hours. A receiver is not required to send reports, so timing and coverage vary. Check the UTC period in the file, not just its arrival date.