Introduction
DMARC aggregate reports — usually called RUA reports after the rua= tag that requests them — are the daily XML files mailbox providers send to the address you publish in your DMARC record. They're the entire feedback loop of DMARC. Without them, your policy is fire-and-forget; with them, you have a per-sender, per-receiver view of who's mailing as your domain.
This article explains what's actually inside an aggregate report, what each field means, and how to derive the operational insights you need to safely move from monitoring to enforcement.
Why this topic matters
Aggregate reports are the only DMARC data source you'll have on an ongoing basis. Forensic reports are sparse and often disabled by providers; aggregate reports are reliable, daily, and complete. Every operational decision — fix this sender, ignore this IP, advance to quarantine, hold position — comes from interpreting them.
If you can't read aggregate reports, you can't operate DMARC. If you can, the rest of the rollout becomes mechanical.
What's in an aggregate report
Each XML file represents one provider's view of your domain's mail traffic over a reporting period (usually 24 hours). The structure is straightforward once you've seen one:
“xml <feedback> <report_metadata> <org_name>google.com</org_name> <date_range> <begin>1735689600</begin> <end>1735776000</end> </date_range> </report_metadata> <policy_published> <domain>yourdomain.com</domain> <p>quarantine</p> <pct>100</pct> </policy_published> <record> <row> <source_ip>198.51.100.42</source_ip> <count>247</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>yourdomain.com</header_from> </identifiers> <auth_results> <dkim> <domain>yourdomain.com</domain> <result>pass</result> </dkim> <spf> <domain>yourdomain.com</domain> <result>pass</result> </spf> </auth_results> </record> </feedback> “
The metadata identifies the reporter (Google, in this case) and the time window. The policy block confirms what your record looked like when they saw your mail. The record blocks — one per source IP — show what they actually did with that mail.
The fields that matter most
For day-to-day operations, six fields drive every decision:
source_ip— the IP that sent the mail. Tells you which sender it came from.count— message volume from that IP in this period. Combined with sender identity, this is your per-sender volume.disposition— what the receiver actually did (none,quarantine,reject). Compare against your policy.dkimresult in policy_evaluated — did DKIM align with the From domain?spfresult in policy_evaluated — did SPF align with the From domain?header_from— the visible From header domain. Should always be your domain (otherwise it's not a report about you).
The auth_results section adds raw DKIM and SPF results (independent of alignment), which is useful when debugging.
How to interpret the data
A handful of patterns explain most of what you'll see:
spf=pass,dkim=pass,disposition=none— legitimate sender, properly authenticated, no action needed. The bulk of your report should look like this.spf=pass,dkim=fail,disposition=none— passing via SPF but DKIM is missing or broken. Worth fixing because DKIM survives forwarding and SPF doesn't.spf=fail,dkim=pass,disposition=none— usually a sender behind a forwarder; DKIM saved you. Often safe to leave alone.spf=fail,dkim=fail,disposition=quarantine— either an attacker spoofing your domain or a legitimate sender misconfigured. The IP tells you which.
The job of the rollout is to get every source_ip representing a legitimate sender into the first pattern.
Best practices
- Use a DMARC platform for parsing. Raw XML is fine for spot checks but unsustainable past a few dozen senders. See how to read DMARC XML reports without losing your mind.
- Map every
source_ipto a sender name. Marketing tool, billing system, internal mail server, attacker. If you can't name it, that's the work. - Don't ignore low-volume rows. A row with
count=1from a new IP can be an attacker probe or a new tool. Investigate before dismissing. - Track pass rate per sender over time. A sender at 100% one week and 95% the next is drifting; investigate before it breaks at enforcement.
- Set up alerts on new senders. New rows in the report are how you find out marketing added a tool without telling IT.
Recommended next step
If you're getting aggregate reports but not parsing them, that's the next move — a platform that turns the XML into a sender dashboard. The DMARC AI ingestion pipeline takes raw rua= mail and produces a per-sender view with pass rate, volume trends, and remediation guidance.
If you're not getting reports at all, the rua= tag in your record is wrong or the mailbox is rejecting them. Validate with common DMARC errors.
FAQ
How often do receivers send aggregate reports?
Most major providers send daily. Smaller receivers send less frequently. The ri= tag in your record requests a specific interval (default 86400 seconds = daily) but receivers don't always honour it.
Why don't I see reports from some receivers?
Some receivers don't send DMARC reports at all (smaller ISPs, some corporate mail servers). The major providers — Google, Microsoft, Yahoo — all send reliably. If you're missing reports from a major provider, your rua= configuration is the likely cause.
Can I get reports from senders other than my own?
No. Aggregate reports are sent by receiving mail servers about your domain's traffic. They report what they saw arrive claiming to be from you, not what your senders sent.
What's the difference between aggregate and forensic reports?
Aggregate reports are statistical summaries (this many messages from this IP, with these results). Forensic reports are per-message detailed copies. Aggregate is reliable and daily; forensic is sparse and rarely used.
Do aggregate reports include message content?
No. Aggregate reports are metadata only — IPs, counts, authentication results. They never include the message body or subject. Forensic reports can include redacted samples, which is why some receivers don't send them.
Final thoughts
DMARC aggregate reports are the operational core of DMARC. Once you can read them — directly or via a platform — every rollout decision becomes data-driven instead of guess-driven. The phases of the rollout map to specific patterns in the reports, and the steady-state monitoring is essentially "did the patterns change since last week."
Start with one report, read it field by field, and the rest becomes intuitive. The investment in fluency pays back many times across the lifetime of the domain.