DMARC Aggregate Report, or RUA, is a summary report sent by mailbox providers about mail that claims to be from your domain. It shows authentication and alignment outcomes in bulk, not message content. Security teams use it to find unauthorised senders, misconfigured services and rollout gaps before enforcing stricter DMARC policies.
How RUA reports are generated and what mailbox providers send
RUA is an aggregate reporting channel, so the provider batches results about messages that presented as coming from your domain and returns counts rather than individual emails. That makes it useful for seeing the shape of authentication results across all sending sources, especially when you want to compare expected mail flows with what the ecosystem is actually seeing. For rollout work, the key value is coverage, not message detail.
Because the report is produced by mailbox providers, the data reflects what they observed at their edge, including authentication and alignment outcomes, policy disposition and volume patterns. It does not tell you the content of the message, but it can show whether a service is sending mail that fails SPF or DKIM alignment, whether a source is emitting mail unexpectedly, or whether legitimate platforms still need configuration changes before stricter policy enforcement.
Used well, RUA becomes an operational feedback loop for domain-based authentication. NHIMG’s DMARC, SPF and DKIM Guide covers the wider rollout path, including alignment, aggregate report and staged policy changes. It is the right companion when you need to move from raw reporting into a controlled enforcement journey.
What RUA helps you confirm in practice
RUA is most useful when you are trying to answer three practical questions: which sources are sending for your domain, which of those sources authenticate cleanly, and which ones are failing alignment often enough to matter. That is why it is usually reviewed alongside sending inventory, vendor onboarding and policy staging. A single clean report is rarely enough; trends across multiple reporting windows are what expose misconfigured systems and shadow senders.
It also helps separate genuine mail infrastructure from impersonation attempts. A sudden rise in unauthorised sending or repeated failures from an unfamiliar source can reveal a third-party platform, forwarding path or forgotten application that is still using your domain. In that sense, RUA is not just a compliance artifact, it is a discovery mechanism for mail that should not exist or should not be trusted.
For teams that are still staging DMARC, RUA is the evidence base for deciding whether to stay at monitoring mode or tighten policy. NHIMG’s Email Identity and BEC Guide is useful here because it connects the reporting data to practical enforcement decisions, including impersonation, bulk sender behaviour and the business impact of weak email identity controls.
How to read RUA without over-trusting the numbers
The biggest mistake is treating aggregate data as if it were a precise incident log. RUA is excellent for volume, source discovery and authentication outcomes, but it is still summarised telemetry. You need to interpret it in context, because a failure can be caused by a legitimate platform change, a forwarding path, a new vendor, or a bad actor trying to send on your behalf. The report tells you where to look next, not the full story by itself.
Another common error is focusing only on pass and fail totals while ignoring alignment and source grouping. A service can authenticate technically but still fail DMARC alignment, which means it may not count as trusted mail for policy purposes. Likewise, a small number of failed messages can matter more than a large volume of routine traffic if they come from a high-value domain, a finance workflow or a partner integration that should never drift.
Practically, the report is most valuable when you compare it to your approved sender list and your expected mail paths. That comparison tells you whether the report is confirming a known architecture or surfacing a gap that should be fixed before moving from p=none to quarantine or reject.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Asset Inventory | RUA exposes sending sources that should be inventoried and governed. |
| Recommendation — Maintain an accurate sender inventory and compare RUA findings against it. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | RUA is operational telemetry that must be reviewed for anomalous sending and failures. |
| Recommendation — Review aggregate mail telemetry for unauthorised senders and repeated authentication failures. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | RUA can surface misused mail services tied to exposed or misconfigured sending credentials. |
| Recommendation — Investigate failing senders for exposed or misused secrets and rotate them when needed. | ||
Practitioner Guidance
What to verify: Treat each new or failing source in RUA as an inventory question first. Confirm whether the sender is approved, whether it should be using SPF, DKIM or both, and whether the alignment failure is due to a legitimate configuration issue or an unauthorised sender.
Decision rule: If a source is expected but failing alignment, fix the sending path before tightening policy. If the source is unexpected, investigate it as a shadow sender or impersonation path before assuming it is harmless.
What practitioners underestimate: Aggregate reports often reveal rollout gaps that were invisible in testing, especially with SaaS platforms, forwarding, shared services and forgotten automation. The report is most useful when it drives sender inventory cleanup, not when it is read as a passive compliance summary.
Practitioner takeaway: RUA is a control-validation tool, not just a report, and the real value comes from using it to identify every system that can send for your domain before you enforce stricter DMARC policy.