How to read DMARC aggregate (RUA) reports

The first time you open a DMARC aggregate report, it looks like noise: a wall of XML full of IP addresses and pass/fail flags. But these reports are the single most useful thing DMARC gives you. They are the map that takes a domain from monitoring to enforcement — the only reliable way to discover everyone sending mail in your name before you tighten the policy. This guide explains what's inside, how to read it, and how to act on it.

What aggregate reports are

When you publish a DMARC record with a rua= address (see what is DMARC for the basics), receiving providers — Google, Microsoft, Yahoo and hundreds of others — start sending you a daily summary. Each report covers a 24-hour window and answers one question: of all the mail that claimed to be from your domain, where did it come from, and did it authenticate?

These are aggregate (RUA) reports — counts grouped by sending source, not copies of individual emails. (A separate, rarer kind called forensic or failure reports, RUF, can include redacted samples, but aggregate reports are what you live in day to day.) They arrive as XML, usually gzipped or zipped, attached to an email.

Anatomy of the XML

Every report has the same shape. Three parts matter:

1. Report metadata — who sent the report and the time window:

<report_metadata>
  <org_name>google.com</org_name>
  <report_id>14217...</report_id>
  <date_range><begin>1718...</begin><end>1718...</end></date_range>
</report_metadata>

2. Published policy — the DMARC record the receiver saw for you that day. Useful for confirming your record propagated as expected:

<policy_published>
  <domain>your-domain.com</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

3. Records — the heart of the report. One block per sending source, with a volume count and the authentication results:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>your-domain.com</header_from></identifiers>
</record>

Read that block as a sentence: "From IP 203.0.113.10, 42 messages claimed to be from your-domain.com; DKIM aligned and passed, SPF did not." Because DMARC needs only one aligned pass, those 42 messages passed DMARC on the strength of DKIM.

The fields that decide everything

For each source, focus on three things:

• source_ip and count — who sent, and how much. High-volume sources are your most important ones to get right.
• dkim and spf results inside policy_evaluated — these reflect alignment, not just whether the mechanism passed in isolation. This is the number that matters: a source can pass raw SPF yet show spf: fail here because the domain didn't align with your From:.
• disposition — what the receiver actually did (none, quarantine, reject), based on your current policy.

A source where either dkim or spf shows pass is authenticated and safe to enforce against. A source where both fail is the problem set — it's either a legitimate sender you haven't aligned yet, or a spoofer.

Turning reports into action

The workflow is always the same, and it's the whole game:

1. Aggregate across reports. A single day from a single provider is a sliver. Combine many reports over a few weeks to see the full picture of who sends for you.
2. Identify every legitimate source. That high-volume IP passing DKIM is probably your mail platform. The one failing both might be your CRM, your billing system, or a tool a team set up without telling IT. Name each one.
3. Fix alignment for the legitimate ones. Add the missing include: to SPF, set up DKIM signing with an aligned d=, until each real sender shows a pass.
4. Watch the failures shrink. When the only fail sources left are ones you don't recognize — spoofers — you're ready to tighten.
5. Ramp the policy. Move to quarantine, then reject, watching the reports stay clean. The full sequence is in how to get to p=reject.

Why people give up — and how not to

Reading raw XML by hand does not scale. A mid-size company can receive dozens of reports a day from many providers, each listing many IPs. Mapping a stream of IP addresses back to "oh, that's our Zendesk" is tedious and error-prone, which is exactly why so many domains collect reports for a while and then quietly stop at p=none. The reports were never the problem; making sense of them was.

The fix is to let software do the aggregation and translation. That's what Marc, the DMARC copilot, is built for: he ingests your aggregate reports, turns raw IPs and PTR records into recognizable service names ("your Mailchimp", "an unconfigured SendGrid subaccount"), scores your readiness over a rolling window, and tells you exactly which sources to fix before each step toward p=reject.

What aggregate reports won't tell you

Aggregate reports are powerful, but knowing their limits keeps you from drawing wrong conclusions:

• No message content. Aggregate reports contain counts and authentication results, never subjects, bodies or recipient addresses. They tell you that a source sent mail as you and how it authenticated — not what the mail said. (A separate, rarer report type — forensic or failure reports, RUF — can include redacted samples, but many providers don't send them at all for privacy reasons.)
• A delay of roughly a day. Reports cover a 24-hour window and arrive afterward, so you're always looking at yesterday, not this minute. Don't expect real-time feedback when you change a record; give it a day or two to show up.
• Per-source, not per-message. A row aggregates many messages from one IP with the same result. You can't trace an individual email through aggregate data alone.
• Only participating receivers. Most large mailbox providers send reports, but not every receiver does. Your reports represent the large majority of your mail, not literally all of it.
• Raw IPs, not names. The report says 198.51.100.7, not "your Zendesk". Mapping addresses back to services is on you — and it's the single most time-consuming part of the job.

None of this diminishes their value; it just means aggregate reports are a map, not a live camera. Read them as trends over weeks, not as moment-to-moment telemetry, and pair them with tooling that turns IPs into recognizable senders.

Get the reports flowing

You need two things to start: a DMARC record with a rua= address, and somewhere to send the reports. The fastest way is a free DMARC monitoring mailbox that ingests and parses the XML for you automatically — one DNS line, then your daily reports turn into a readable dashboard instead of a folder of attachments.

Start by checking your current setup with our free analyzer — it shows whether you even have a rua= address and how your sources are aligning today. Then create an account to collect and read your reports continuously, with Marc translating every source and pointing the way to enforcement.

New to the fundamentals? Begin with what is DMARC and how SPF, DKIM and DMARC work together.