How to Read a DMARC Aggregate Report (RUA XML Explained)

A DMARC aggregate report is a machine-readable XML summary that mail receivers — Google, Microsoft, Yahoo and others — send once a day to the address in your domain's rua= tag. It lists every source that sent mail claiming to be from your domain, how much each sent, and whether that mail passed DMARC.

Knowing how to read a DMARC aggregate report means you can find failing senders yourself, from the raw XML, without paying a dashboard to interpret it for you. This guide walks the fields one at a time: source_ip, count, policy_evaluated and auth_results — and the single most useful pattern in the file, where authentication passes but alignment fails.

One note on the standard first: DMARC's specification became RFC 9989 in 2026, and the aggregate report format now has its own document, RFC 9990. Most tooling and vendor pages still describe the older RFC 7489 layout, but the field names below are stable across both.

What's inside a DMARC aggregate report#

Every aggregate report is one XML file, usually GZIP- or ZIP-compressed and delivered as an email attachment. One receiver sends one report per day, so a domain with real traffic collects dozens of separate files daily — one from each receiver that got mail using your domain.

Whatever the reporter, the structure is the same. The document opens with a <feedback> root and holds three kinds of block.

• <report_metadata> — who sent the report and the window it covers. Read <org_name> for the reporter (for example google.com) and <date_range>, whose <begin> and <end> are Unix timestamps marking the 24-hour period.
• <policy_published> — the DMARC policy the receiver found in your DNS at report time: <p> (none, quarantine or reject), <sp> for subdomains, and the alignment modes <adkim> and <aspf>.
• <record> — one block per sending source. This is where the diagnosis happens, and where nearly all the confusion lives.

How to open a DMARC report file#

The report lands in whatever mailbox your rua= tag points to. The attachment name usually ends in .xml.gz, .xml.zip or .zip. Turning it into something you can read takes three steps.

1. 1

   Save the attachment

   Download the file from the report email. The name encodes the reporter, your domain and the date range — for example google.com!yourdomain.com!1700000000!1700086400.xml.gz.

2. 2

   Decompress it

   Unzip the file to get the raw .xml. On macOS and Windows the built-in archive tools handle both .gz and .zip; on the command line, run gunzip file.xml.gz.

3. 3

   Open the XML

   Open the .xml in any text editor or browser. It is human-readable, but the tags are terse — the table below explains each one.

Every field, and what it's telling you#

Inside each <record> are three groups: <row> (the source and the DMARC verdict), <identifiers> (the domains involved), and <auth_results> (the raw SPF and DKIM checks). Here is what the load-bearing fields mean and what to do when one looks wrong.

One more field shows up when a receiver overrides its own policy: an optional <reason> block inside <policy_evaluated>, with a <type> and a <comment>. You'll see it on forwarded mail and mailing-list traffic, where the receiver chose not to apply your policy even though alignment failed — worth knowing before you treat every fail as a problem to fix.

Why SPF can pass while DMARC fails#

This is the single most useful pattern in the report, and the one that trips people up. A record can show SPF passing in <auth_results> and yet the same source fails DMARC. The reason is that DMARC does not care whether SPF passed on its own — it cares whether the domain SPF authenticated aligns with the domain in your From header.

So <policy_evaluated> and <auth_results> are answering two different questions. That is exactly what policy_evaluated means: the receiver's alignment verdict, not the raw check.

Why reading the report matters#

Reading these reports is how you reach an enforcing policy — p=quarantine or p=reject — without blocking your own mail. Every legitimate sender that fails alignment while you sit at p=none gets quarantined or rejected the moment you tighten the policy, and the report is your only list of who those senders are.

The deadline pressure is real. As of November 2025, Google escalated enforcement for bulk senders: non-compliant traffic to personal Gmail now draws temporary and permanent rejections, not just spam-foldering. Microsoft runs a separate Outlook.com regime, live since 5 May 2025, requiring SPF, DKIM and DMARC for senders above roughly 5,000 messages a day. Verify the current terms on each provider's own postmaster pages before you rely on a threshold.

Common misconceptions about aggregate reports#

• SPF pass means DMARC pass. It doesn't. Raw authentication and alignment are separate results, and DMARC only reads the alignment result in <policy_evaluated>.
• An unknown source_ip is always an attacker. Often it is a legitimate service you forgot authorises mail for you — a CRM, a help desk, an invoicing app. Identify the IP before you assume the worst.
• The report shows only my mail. It shows all mail claiming your domain, including messages you never sent. Surfacing spoofers is the whole point.
• The pct field is current. RFC 9989 removed the pct tag from DMARC in 2026, so it is being retired from <policy_published>; you'll still see it in older records and in docs that cite RFC 7489.
• Aggregate reports cover everything. Microsoft puts typical coverage at 70–90% of your mail volume — not every receiver sends reports, so read the totals as a strong sample, not a full census.

Where AI Emaily fits#

A word on where this fits, since we build AI Emaily and should say so plainly. AI Emaily is an email client, not a DMARC monitoring service — it does not parse these XML files into dashboards. If you want trend charts and per-source scoring, use a dedicated DMARC reporting service; Microsoft lists options in its MISA catalog.

What a mail client does own is the mailbox those reports land in. The address behind your rua= tag collects a daily stream of XML attachments from every receiver, and left alone it buries the mail you actually read. AI Emaily's rules and Context Brain can file every aggregate report into one place, keep it out of your main inbox, and hand the attachments to your parser — the same triage and phishing defence it runs on the rest of your mail. We build AI Emaily.