How do I read a DMARC aggregate (RUA) XML report?

A DMARC aggregate report (often called a RUA report) is an XML document that a receiving mail provider — Google, Microsoft, Yahoo, and many others — sends you once per day, one per receiver. You start getting them the moment you publish a DMARC record with a rua= tag, for example v=DMARC1; p=none; rua=mailto:[email protected]. Each report summarises every message that claimed to come from your domain during a 24-hour window: the sending IP, the message count, the SPF and DKIM outcomes, whether those outcomes aligned with your From domain, and the disposition the receiver applied. Crucially it contains no message content — only authentication metadata — so it is safe to analyse and is the feedback loop you use to move a policy from monitoring to enforcement without breaking real mail.

The reports arrive compressed

They land as .gz or .zip attachments, and the raw XML is hard to read by eye. Paste the XML or drop the compressed file into the DMARC report analyzer; it decompresses and parses the file entirely in your browser (using the native DecompressionStream and DOMParser APIs) and renders a dashboard — nothing is uploaded to a server, and no reverse-DNS lookup is performed on any IP.

Alignment is the one concept that matters

DMARC does not care merely that SPF or DKIM passed — it cares that the domain which passed aligns with the visible From address. A message passes DMARC if at least one of aligned SPF or aligned DKIM passes. That is why:

• A source can show raw SPF=pass yet DMARC SPF=fail — the SPF domain did not align with the From header.
• A forwarded message can show SPF=fail but aligned DKIM=pass and still be perfectly fine — forwarders rewrite the envelope and break SPF, but a DKIM signature survives forwarding and keeps the message aligned.

The rows that actually matter for a p=quarantine or p=reject policy are the ones where both aligned methods fail. The analyzer highlights those in red.

How to read the dashboard

The report header shows who sent the report (report_metadata), the domain it covers, the date range, and your published policy (p, sp, adkim, aspf, pct). The summary gives a total message count and a DMARC pass/fail percentage. The sortable Sources table is the heart of it: one row per sending IP, with its message count, the aligned DKIM and SPF results that DMARC evaluated, the disposition the receiver applied (none, quarantine, or reject), the header-From it used, and the raw per-signature auth details.

Turn the report into action

Use the dashboard to inventory your legitimate senders. For each failing source, decide whether it is yours (an ESP, CRM, ticketing system, or newsletter tool that needs SPF or DKIM configured) or spoofing you can safely reject. Once every legitimate source aligns, you can confidently raise your policy. When you are ready, build or adjust the record with the DMARC generator, validate the live record with the DMARC checker, and read about moving from p=none to quarantine to reject. To debug a single message rather than a day's aggregate, paste its headers into the email header analyzer.