DMARC Aggregate Reports: What They Are and What They Tell You

DMARC aggregate reports overview:

RUA reports summarize authentication results across reported email traffic
Not all receiving providers send DMARC aggregate reports – coverage is broad but not universal
RUA data surfaces unauthorized senders, authentication gaps, and enforcement outcomes

Publishing a DMARC record is only the start. The record enables reporting, and without reading that data, your company has no visibility into who’s sending email on your behalf or whether authentication is working.

This post covers DMARC aggregate reports (RUA) specifically: What they contain, how they’re delivered, and what the data means in practice. DMARC aggregate reports are the primary data source for any business working toward enforcement. Without them, enforcement decisions are guesswork.

Sendmarc gives you a clear view of every sender, every result, and every gap – before you enforce.

Understanding DMARC Aggregate Reports

A DMARC aggregate report is a daily summary sent by a receiving server back to the domain owner. It reports on how emails claiming to be from your domain performed against SPF and DKIM authentication checks.

Reports are delivered as compressed XML files to the address specified in the rua= tag of your DMARC record. They provide a high-level overview of all email traffic claiming to originate from your domain during a given reporting period.

Aggregate reports are distinct from forensic reports (RUF). RUA reports contain no message content and no headers – they are authentication result summaries only. The two report types serve different purposes and have different levels of support across receiving providers.

One important caveat: Not all receiving providers send aggregate reports. Coverage is broad – major providers including Google, Microsoft, and Yahoo participate – but it isn’t universal.

What an Aggregate Report Contains

A standard RUA report includes the following data fields:

Reporting organization – The receiving provider that generated the report
Date range – The period the report covers
Domain – The domain the report applies to
Policy applied – The DMARC policy in effect during the reporting period (p=none, p=quarantine, or p=reject)
Source IP – The IP address that sent the messages
SPF result – Whether SPF passed or failed
DKIM result – Whether DKIM passed or failed
Disposition – The action taken by the receiving provider (none, quarantine, or reject)

How Aggregate Reports Are Delivered

Reports arrive at the rua= address as XML attachments, typically compressed as .gz or .zip files. The raw XML is technically readable, but not practical at scale.

Companies routing reports directly to a mailbox will receive individual XML files from each participating provider. A single domain can generate dozens of reports per day from different receivers. Across multiple domains, that volume compounds quickly – some environments receive hundreds or thousands of reports daily.

Most businesses use a reporting service or platform to parse, aggregate, and visualize the data. Without this, the volume and format of reports make consistent analysis difficult for any team, regardless of technical capability.

What Aggregate Reports Reveal in Practice

Aggregate report data answers questions that directly affect enforcement decisions and security posture.

Sending Sources

The source IP field identifies which IP addresses are sending messages claiming to be from your domain. Unknown IPs signal unauthorized senders, misconfigured systems, or potential spoofing activity. Gaining unified visibility into all email-sending tools – including third-party platforms – starts here.

Authentication Gaps

The SPF and DKIM result fields show which sources are failing authentication checks and which are passing. These gaps must be resolved before enforcement is applied. Moving to p=quarantine or p=reject while legitimate senders are failing authentication will filter or block valid emails.

Policy Enforcement Outcomes

At p=quarantine or p=reject, the disposition field confirms whether receiving providers are honoring the policy. This is the feedback loop that tells you whether enforcement is working.

Volume Anomalies

Sudden spikes in message volume from an IP address can indicate spoofing or abuse. Monitoring aggregate report data over time makes these anomalies detectable.

Why Aggregate Reports Matter

Organizations shouldn’t move to p=quarantine or p=reject without first reviewing aggregate report data. Enforcement applied before all legitimate senders are authenticated will disrupt valid email flows – including billing notifications, transactional messages, and marketing communications.

The monitoring phase (p=none with rua= configured) exists to collect this data. It is only useful if the reports are being read and acted on. Remaining at p=none indefinitely helps you collect data but provides no protection against spoofing or impersonation.

Aggregate reports are the signal that tells teams when enforcement is safe to apply. The time required in the monitoring phase varies by company – it depends on the complexity of the sending environment. Large or distributed environments with multiple business units, regions, and SaaS tools typically require more time to identify and authenticate all legitimate senders.

Reading Aggregate Reports at Scale

Reading aggregate reports manually – across dozens of domains and hundreds of IPs – isn’t scalable. The gap between deploying DMARC and enforcing it is a data problem.

Sendmarc processes RUA reports across your entire domain portfolio and surfaces what matters – so your team spends time on decisions, not XML files.

With Sendmarc’s DMARC Management Platform, teams can:

Spot unauthenticated senders before they affect deliverability or compliance
Track policy enforcement outcomes across receiving providers
Centralize visibility across departments, regions, and third-party senders
Support compliance reporting without increasing team workload

See who’s sending from your domains – and what isn’t authenticating.