DMARC Aggregate Report Reader

Paste the raw XML from a DMARC aggregate (RUA) report — as received in your inbox from Google, Microsoft, Yahoo, or any other receiver — and get a clear, readable breakdown. The tool extracts the reporting organisation, date range, published policy, and a per-source-IP table showing message counts, DKIM results, SPF results, and disposition. Rows where both DKIM and SPF fail are highlighted in red so problem sources jump out immediately.

How to use the DMARC Aggregate Report Reader

DMARC aggregate reports arrive as gzip or zip attachments to a designated rua= email address. Decompress the attachment to get a .xml file. Open it in a text editor, select all content, and paste it above.

Click Parse Report. The tool displays:

  1. Report metadata — who sent the report (the receiving mail system, e.g. Google LLC), the date range covered, the reporting email, and the policy that was evaluated.
  2. Policy published — the DMARC policy your domain published at the time the report was generated (domain, p=, pct=).
  3. Per-source table — one row per sending IP or IP range in the report. Columns show message count, disposition (none/quarantine/reject), DKIM result (pass/fail), SPF result (pass/fail), and the header From: domain. Rows where both DKIM and SPF fail are highlighted red — these are authentication failures you need to investigate.
  4. Summary totals — total messages, messages passing both checks, and messages where both fail.

Use the source IP column to look up which sending service owns that IP (reverse DNS or your ESP’s IP list). If a legitimate service is failing, add it to your SPF record, configure DKIM signing, or authorise the sending domain.

About DMARC aggregate reports

DMARC aggregate reports (RUA reports) are XML documents sent by mail receivers (Gmail, Outlook, Yahoo, corporate mail gateways) to the address in your DMARC record's rua= tag. Each report covers a period of time (usually 24 hours) and lists every IP address that sent mail claiming to be from your domain during that period, along with DKIM and SPF authentication results and the disposition applied (none, quarantine, or reject, based on your policy).

These reports are the single most important tool for safely rolling out DMARC. Starting at p=none with a rua= address gives you full visibility without any risk — you can see exactly which sources are passing authentication and which are failing before you start quarantining or rejecting. Common surprises include: the company's own CRM sending from the root domain without DKIM, a forgotten mail relay server not covered by SPF, or a third-party newsletter platform that was set up before DMARC was deployed. Each of these shows up as a failing source in the aggregate report so you can fix it before enforcement.

The XML schema is defined in RFC 7489 Appendix C. The structure is consistent across all senders: <feedback> wraps <report_metadata> (org name, dates, report ID), <policy_published> (your policy as the receiver saw it), and one <record> per source IP containing <row> (IP, count, disposition, policy evaluated) and <auth_results> (DKIM and SPF results). Parsing it manually is tedious; this tool does it in-browser without uploading your data anywhere.

Common use cases

  • Pre-enforcement audit — review 2–4 weeks of aggregate reports while at p=none to ensure every legitimate sending source passes before tightening the policy to quarantine or reject.
  • Diagnosing alignment failures — identify which ESP or internal mail server is sending without DKIM, or with an envelope domain that does not align with the From: header domain.
  • Detecting spoofing — IPs you do not recognise sending mail from your domain in the report are likely spoofing attempts; cross-reference with ASN or reverse-DNS lookups.
  • Verifying new sender configuration — after adding a new ESP, check the next day’s aggregate report to confirm that source is now showing pass results before it sends to large audiences.
  • One-off analysis without extra tooling — instead of signing up for a third-party DMARC report service, paste individual reports here for free, in-browser analysis without sharing data.

Frequently asked questions

How do I get the XML file from the report email?
DMARC report emails have a .xml.gz or .xml.zip attachment. Download it, then decompress it with any archive tool (macOS Finder, Windows Explorer, 7-Zip, or the gunzip command). The resulting .xml file is what you paste here.

Why do I see IPs I do not recognise?
Unrecognised IPs sending mail from your domain are usually spoofing attempts — legitimate email that uses your From: domain without authorisation. At p=none these are reported but not blocked; at p=reject they would be blocked. Cross-reference the IP with its reverse DNS or ASN to confirm.

What does "disposition: none" mean even though my policy is quarantine?
The report records the disposition actually applied to those messages. If your pct= is below 100, a proportion of failing messages are treated as p=none. It can also mean the receiver overrode your policy (some apply local overrides) or the messages passed DMARC (disposition=none is also the outcome for passing messages).

A source shows pass for SPF but fail for DKIM — is that OK?
DMARC passes if either SPF or DKIM passes with alignment. A source that passes SPF alignment but fails DKIM will show a pass disposition and will not affect your policy rollout. However, DKIM provides replay protection that SPF does not, so it is good practice to add DKIM signing to all sources even if they already pass via SPF.

How often are aggregate reports sent?
Most receivers send one report per domain per day. The ri= tag requests an interval (default 86400 seconds = 24 hours) but many receivers ignore it and send daily regardless. Large receivers like Google and Microsoft are reliable senders; smaller receivers may not send reports at all.