DMARC Aggregate Reports: How to Read the XML Rua Sends You

What Actually Lands in the rua Mailbox

Once a DMARC record includes a working rua address, participating receivers begin sending automated emails there, usually daily, each carrying a compressed XML attachment. The filename typically follows a pattern like receiver.example!yourdomain.com!1712000000!1712086400.xml.gz, encoding the reporting organization, your domain, and the Unix timestamp range the report covers. Decompressed, the file is structured XML following the schema RFC 7489 defines — not free-form text, which is exactly what makes it possible to parse programmatically rather than read one email at a time.

For a domain with any meaningful mail volume, dozens of these reports arrive daily from different receivers — Gmail, Microsoft, Yahoo, and any other mail system that observed traffic claiming to be from your domain, each reporting independently on what it saw during its window. This is why almost nobody at scale reads raw XML by hand day to day; the practical workflow is to feed these reports into a parser or dashboard and review the aggregated output. Understanding the raw structure, though, is what lets you sanity-check that tooling and troubleshoot when something looks wrong.

The Core Structure of the XML

Every aggregate report XML file follows the same top-level shape: a report_metadata block identifying the reporting organization and the date range covered, a policy_published block echoing back exactly what DMARC policy the receiver saw published for your domain at the time, and one or more record blocks — the actual data, one per unique combination of source IP and authentication outcome observed during that window.

<record>
  <row>
    <source_ip>203.0.113.44</source_ip>
    <count>187</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>bounce.thirdparty.com</domain>
      <result>pass</result>
    </spf>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
    </dkim>
  </auth_results>
</record>

Reading this record: 187 messages came from IP 203.0.113.44, claiming the From: header example.com. The raw SPF check technically passed — but for bounce.thirdparty.com, a different domain than the From: header, so it doesn't align, hence spf: fail in the alignment-aware policy_evaluated block even though the underlying SPF lookup succeeded. DKIM passed and aligned cleanly for example.com itself, which is why the overall disposition is still fine — remember, DMARC only needs one aligned pass, and DKIM provided it here.

Key Fields to Focus On

Triage: Legitimate Sender vs Real Threat

Use Cases for Reviewing Aggregate Reports

From Raw XML to a Weekly Review Habit

Reading a single aggregate report XML file by hand is a reasonable one-time learning exercise; doing it every day is not a sustainable process for anyone. The practical middle ground most domain owners land on is a lightweight recurring habit: once a week, open whatever tool or dashboard aggregates the accumulated reports, scan specifically for new source IPs that weren't present the prior week, and check that every previously known source is still showing a clean aligned pass. This ten-minute weekly check catches drift far earlier than an occasional, irregular deep-dive, and it's a far smaller time investment than the habit suggests — most weeks, there's simply nothing new to investigate, which is itself useful confirmation that the domain's sending landscape is stable.

What a Dashboard Actually Adds Over Raw XML

For anyone wondering whether investing in a dedicated DMARC reporting tool is worth it over just opening XML files manually, the honest answer scales with mail volume and sender complexity. A domain with one sending platform and low volume can reasonably track things in a spreadsheet updated from occasional manual XML review. A domain with a dozen sending sources across marketing, transactional, and support platforms benefits substantially from a dashboard that aggregates multiple days of reports into trend lines, flags new sources automatically, and makes historical comparison trivial — the kind of pattern recognition that's genuinely tedious to do by hand across dozens of separate report files.

Aggregating Across Multiple Reports Manually

For a domain not yet using dedicated tooling, a simple manual aggregation approach still works reasonably well at low volume: extract the source_ip, count, and policy_evaluated values from each incoming report into a single running spreadsheet, tagging each row with the receiving organization and date range. Over a few weeks, patterns become visible just from sorting and filtering that spreadsheet — a source appearing consistently with clean passes needs no further attention, while a source appearing intermittently or with inconsistent results stands out clearly once enough data accumulates in one place rather than scattered across dozens of individual email attachments.

What Happens to Reports for a Domain That Doesn't Send Mail

An underappreciated use case: even a domain that's never used to send legitimate mail — a parked domain, a brand-protection registration, an old domain kept only to prevent squatting — benefits from DMARC aggregate reports, arguably more than an active sending domain does. Any traffic showing up in reports for such a domain is, by definition, not legitimate, since there's no real sending activity to account for it. This makes the aggregate reports for a non-sending domain unusually clean signal for detecting spoofing attempts specifically, uncomplicated by the need to distinguish real senders from unauthorized ones.

Report Volume as Its Own Signal

Beyond pass/fail results, the sheer volume reported for a given source is itself informative. A sudden, unexplained spike in message count from an otherwise low-volume source — even one that's passing authentication cleanly — can indicate a compromised account being used to send spam or phishing through otherwise legitimate, properly authenticated infrastructure. DMARC alignment alone wouldn't catch this, since the mail genuinely does authenticate correctly; it's the anomalous volume pattern, visible in the same aggregate report data, that provides the additional signal worth watching for.

Correlating Aggregate Data With Business Calendar Events

Report patterns often correlate with predictable business events in ways worth anticipating rather than treating as anomalies each time — a spike in a specific marketing platform's volume during a product launch week, a burst of transactional mail during a billing cycle, seasonal patterns around holidays for retail-adjacent domains. Keeping a rough business calendar alongside report review helps distinguish "this is the expected quarterly newsletter spike" from "this is an unexplained new volume pattern worth investigating," reducing false alarms during routine review.

Historical Report Retention Considerations

Individual daily reports are useful in the moment, but retaining a reasonable history — several months at minimum — enables trend analysis that a single day's snapshot can't provide: whether a source's alignment has been improving or degrading over time, whether volume from a given platform is growing or shrinking, whether a previously resolved issue has quietly resurfaced. Most dedicated DMARC dashboard tools handle this retention automatically; domains relying on manual review benefit from at least archiving report summaries somewhere searchable rather than discarding them after each review cycle.

Reports From Regional and Less Common Receivers

Alongside the well-known major mailbox providers, aggregate reports frequently arrive from smaller regional email providers, corporate mail gateways, and specialized industry mail systems that a domain owner may not immediately recognize by name. These are legitimate and worth including in analysis rather than dismissed as noise — they represent real recipients of your domain's mail, and their data contributes to the same overall picture of authentication health as reports from larger, more familiar providers.

Related Reading in This Series

For how policy and pct determine what disposition a failing message receives, see DMARC Policies. For the full tag reference including rua syntax, read DMARC Record Explained. For the conceptual foundation, start with What Is DMARC?. To check your own domain's current record, open DMARC Lookup.