DMARC Aggregate Reports Explained: The Complete Guide to RUA Reports

DMARC aggregate reports (RUA) are XML files sent by receiving mail servers that show authentication results for every message claiming to come from your domain. They include the source IP, SPF and DKIM results, alignment status, and the policy applied. Without these reports, you have no visibility into who is sending email as your domain or whether your authentication is working correctly.

This guide covers everything about DMARC aggregate reports: what they contain, how to read the raw XML, what the common issues are, how to use them for enforcement decisions, and how DMARC Report turns raw data into an actionable dashboard. Whether you are reading your first report or managing reports across hundreds of domains, this is the reference you need.

The first thing people realize when they start getting aggregate reports is how many services are sending email as their domain, says Vasile Diaconu, Operations Lead at DuoCircle. Marketing tools, CRM platforms, ticketing systems, legacy applications — they all surface in the reports. The ones that fail authentication are the ones you need to fix before enforcing your DMARC policy.

What Are DMARC Aggregate Reports?

DMARC aggregate reports are defined in RFC 7489 Section 7.2. When you publish a DMARC record with a rua tag (e.g., rua=mailto:dmarc-reports@yourdomain.com), receiving mail servers collect authentication data for messages from your domain and send periodic XML reports to that address.

Each report covers a specific time period (typically 24 hours) and includes:

• Report metadata: The sending organization, report ID, date range
• Published policy: Your DMARC record as the receiver saw it
• Record rows: One row per unique combination of source IP, SPF result, DKIM result, and disposition

Reports arrive as gzip-compressed XML files, one from each receiving organization that processed messages from your domain. A moderately active domain might receive dozens to hundreds of reports per day.

For the foundational overview, see our guide on DMARC aggregate reports: what they are and how to use them.

RUA vs. RUF: Two Types of DMARC Reports

DMARC defines two report types:

Report Type	Tag	Content	Frequency
Aggregate (RUA)	rua	Summary statistics per source IP	Daily
Forensic (RUF)	ruf	Individual message details for failures	Per-message

Aggregate reports are the primary reporting mechanism. They provide volume and trend data but not individual message details. Forensic reports provide per-message data but are rarely sent by major receivers due to privacy concerns.

Our guide on DMARC RUA vs. RUF reports explains the differences in detail. For forensic reports specifically, see our complete guide to DMARC forensic reports and our guide on how to fix DMARC RUF report problems.

Anatomy of a DMARC Aggregate Report

A DMARC aggregate report is an XML document with the following structure:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1714003200</begin>
      <end>1714089599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1523</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>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Understanding Each Section

report_metadata: Identifies who sent the report (the receiving organization) and the time period covered. The date_range uses Unix timestamps.

policy_published: Shows your DMARC record as the receiver saw it during the reporting period. This confirms what policy was in effect and which alignment mode (relaxed or strict) was used.

record/row: Each row represents a unique combination of source IP and authentication results. The count shows how many messages matched that combination. The policy_evaluated section shows the DMARC verdict: pass or fail, and what action was taken (none, quarantine, or reject).

auth_results: The raw SPF and DKIM results for the source, including which domain was authenticated and which DKIM selector was used.

For a complete walkthrough with annotated examples, see our DMARC RUA report example guide.

How to Read DMARC Reports

Reading raw XML reports manually is possible but impractical at scale. Even a small organization generates hundreds of report files per month. There are two approaches:

Manual Reading

For occasional inspection or debugging, you can open the XML directly. Our guides walk through the manual process:

• How to read DMARC reports: essential guidelines
• How to read DMARC reports (2026 guide)
• How to manually decipher DMARC reports and why it is difficult
• Learn how to go through a DMARC report
• From XML to insights: read DMARC reports and detect unauthorized senders

Automated Parsing with DMARC Report

DMARC Report ingests your aggregate reports automatically and presents the data in dashboards that show:

• Source IP identification with reverse DNS and organization mapping
• Pass/fail rates across SPF, DKIM, and DMARC for each sender
• Alignment status showing whether authenticated domains match the From header
• Volume trends over time so you can spot anomalies
• Enforcement readiness indicating which senders need fixes before you can safely move to p=quarantine or p=reject

For tool comparisons, see our guide on what features to look for in a DMARC report analyzer and our roundup of the best DMARC reporting tools for 2026.

Interpreting Report Data

The value of aggregate reports is in the patterns they reveal. Here is how to interpret the key data points:

Identifying Legitimate vs. Unauthorized Senders

Every source IP in your reports is a server that sent email claiming to be from your domain. Categorize each one:

• Known and authenticated: Your mail server, authorized third-party services. These should show SPF pass, DKIM pass, and DMARC pass.
• Known but failing: Legitimate services you forgot to authenticate. These need SPF/DKIM configuration fixes.
• Unknown: Potentially spoofing attempts or services you forgot about. Investigate before classifying.

Our guide on how to interpret DMARC reports to find email authentication issues walks through this classification process.

Understanding Alignment Results

DMARC alignment is separate from raw SPF/DKIM pass/fail. A message can pass SPF but fail DMARC alignment if the SPF-authenticated domain does not match the From header domain. This is common with third-party senders that use their own envelope sender.

For details on interpreting alignment data, see our guide on how to interpret DMARC alignment results in aggregate and forensic reports.

Decoding Complex Reports

Multi-domain organizations and those with complex sending infrastructure produce reports that are harder to interpret. Our guide on decoding complex DMARC reports covers advanced scenarios including forwarded mail, mailing lists, and multi-domain alignment.

Common Aggregate Report Issues

Not Receiving Reports

If you published a DMARC record with a rua tag but are not receiving reports, common causes include:

• DNS propagation delay. Reports start within 24-48 hours of record publication.
• Incorrect rua syntax. The mailto: prefix is required.
• External domain verification. If the RUA address is at a different domain than the DMARC record, you need to publish a verification record. See the concept of external domain verification in DMARC reporting.
• Reports landing in spam. Some mail servers classify the compressed XML attachments as suspicious.
• No sending volume. If nobody is sending mail as your domain, there are no reports to generate.

Our guide on reasons why you are not receiving DMARC XML reports covers all scenarios.

Report Size Limitations

DMARC aggregate reports can grow large for high-volume domains. There is a practical size consideration. See our guide on why DMARC reports have a 32KB limit for details on how receivers handle large reports and how to manage report volume.

Prioritizing Issues in Reports

When your reports show many failures, it is important to prioritize. Not all failures are equally urgent. Our guide on common DMARC aggregate report issues and how to prioritize them provides a triage framework.

Common Mistakes When Reading Reports

Even experienced administrators make errors when interpreting DMARC data. Our guide on reading DMARC reports: common mistakes to avoid covers the most frequent misinterpretations.

Using Reports to Guide Enforcement

Aggregate reports are not just diagnostic tools. They are the foundation for your enforcement decisions. The progression from p=none to p=reject should be data-driven:

Before Moving to p=quarantine

Your reports should show:

• All known legitimate senders passing DMARC (both SPF/DKIM and alignment)
• No unexpected senders appearing with passing results
• A clear separation between authorized and unauthorized traffic
• At least 90 days of consistent data

Before Moving to p=reject

Your reports should show:

• Quarantine disposition applied to 100% of failing messages for at least 90 days
• No legitimate email being quarantined
• Stable pass rates with no new failing senders

For the complete enforcement roadmap, see our DMARC policy guide: from none to reject and our enforcement timeline roadmap.

When to Review Reports After Policy Changes

Timing matters when you change your DMARC policy. Reports for the new policy start arriving 24-48 hours after the DNS change. Our guide on when to review DMARC aggregate reports after policy implementation covers the review cadence.

Advanced Report Topics

GDPR and CCPA Compliance

DMARC aggregate reports contain IP addresses, which may be considered personal data under GDPR and CCPA. Organizations subject to these regulations need to understand the compliance implications. Our guide on DMARC aggregate reports and GDPR/CCPA compliance provides a compliance checklist.

Privacy Concerns

Beyond regulatory compliance, DMARC reports raise broader privacy questions about what data is collected and who has access. See our guide on privacy concerns in DMARC reports and how to address them.

Why Receiving Reports Is Optional

The rua and ruf tags are optional in DMARC records. However, operating without reports is like driving without a dashboard. Our guide on why receiving DMARC aggregate and forensic reports is optional but recommended explains when you might choose not to receive reports and the risks of that decision.

Why RUA Matters for Monitoring

The rua tag is specifically important for ongoing email authentication monitoring. Our guide on why RUA is important for monitoring email authentication issues makes the case for aggregate reporting as a continuous monitoring practice.

Disabling Reports

In rare cases, organizations may want to stop receiving DMARC reports. Our guide on disabling DMARC reports covers how to do this and the implications.

XML Analyzers and Parsing Tools

If you want to parse DMARC XML outside of a managed platform, several approaches exist:

• DMARC XML analyzer: analyze your email security reports covers dedicated XML parsing tools
• DMARC XML analyzer: the best tool for email security reports compares analyzer options
• Free DMARC report analyzer and XML parser (2026) covers free and open-source options
• DMARC report analyzer: open source tools for email security focuses on self-hosted solutions

For a broader look at report analysis tools and approaches, see our guides on mastering DMARC reports and reading DMARC reports the right way.

Platform-Specific Report Guides

Google Workspace

Google is one of the most prolific aggregate report senders. Their reports cover all Gmail and Google Workspace traffic. See our guide on generating and interpreting DMARC aggregate reports for Google Workspace emails for Google-specific report interpretation.

Using Reports to Detect Threats

Aggregate reports can reveal spoofing and phishing attempts against your domain. While they do not contain message content, the source IP and volume data can identify suspicious activity. See our guide on whether DMARC reports can help detect spoofing and phishing attempts and our analysis of how DMARC report analysis helps stop phishing and spoofing.

Getting Started with DMARC Reporting

If you have not yet set up DMARC reporting, the path is straightforward:

1. Publish a DMARC record with a rua tag pointing to your reporting address. See our DMARC setup complete guide for the full process.
2. Wait 24-48 hours for reports to start arriving.
3. Use DMARC Report to parse and visualize the data automatically.
4. Review your dashboard to identify legitimate senders that fail, unknown senders, and spoofing attempts.
5. Fix authentication failures for all legitimate senders.
6. Progress to enforcement when your reports show consistent passing results.

For a quick-start approach, see our guide on how to get started reading DMARC reports to understand delivery problems and our DMARC reporting three-step checklist.