DMARC Aggregate Reports Explained

What Are DMARC Aggregate Reports?

DMARC aggregate reports (also called RUA reports, from the rua= tag) are XML files sent by receiving mail servers to the address you specify in your DMARC record. They summarize all email traffic they received claiming to be from your domain during a given time period — typically 24 hours.

Every major email provider — Gmail, Microsoft 365, Yahoo, Apple Mail — sends these reports automatically when they receive email from a domain with a DMARC record containing an rua= tag. You don't need to do anything beyond publishing the record.

Why Are Aggregate Reports Important?

Aggregate reports answer the questions that matter most when deploying or maintaining DMARC:

Which IP addresses are sending email claiming to be from my domain?
Are my legitimate senders (Google Workspace, MXPaw, etc.) passing SPF and DKIM?
Is anyone sending unauthorized email from my domain?
Is my email volume consistent with expectations, or are there anomalies?

Without aggregate reports, you are flying blind. A p=none policy with active monitoring is the correct first step — you observe your traffic before enforcing a policy that could block legitimate email.

How Often Are Reports Sent?

Most providers send one report per day covering the previous 24 hours. The reporting interval is technically configurable with the ri= tag in your DMARC record (default is 86400 seconds = 24 hours), but providers are not required to honor custom intervals and most stick to daily.

Reports arrive as email attachments — a ZIP or GZIP file containing an XML file. The sending address is typically something like noreply-dmarc-support@google.com or a similar no-reply address from the reporting organization.

The XML Report Structure

A DMARC aggregate report XML file contains several key sections:

Report Metadata

Identifies who sent the report and what time period it covers:

<report_metadata>
  <org_name>Google Inc.</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>12345678901234567890</report_id>
  <date_range>
    <begin>1708819200</begin>
    <end>1708905599</end>
  </date_range>
</report_metadata>

The begin and end values are Unix timestamps. The org_name tells you which mail provider sent this report.

Policy Published

Records the DMARC policy the receiver observed for your domain at the time of the report:

<policy_published>
  <domain>yourdomain.com</domain>
  <p>reject</p>
  <sp>reject</sp>
  <pct>100</pct>
  <adkim>r</adkim>
  <aspf>r</aspf>
</policy_published>

adkim and aspf are the DKIM and SPF alignment modes: r for relaxed, s for strict.

Records

The bulk of the report. Each <record> element represents a group of messages sharing the same source IP, disposition, and authentication results:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>847</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>
      <selector>google</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

How to Interpret Records

When reading aggregate report records, pay attention to:

source_ip — The IP address of the server that sent the messages. Look up unfamiliar IPs to identify the sending organization. Authorized senders like Google and Outlook have well-known IP ranges.
count — How many messages from this source IP during the reporting period. High counts from unknown IPs are a red flag.
disposition — What actually happened to the messages: none (delivered normally), quarantine (spam folder), or reject (blocked). Note this reflects what the receiver did based on your policy at the time.
dkim/spf under policy_evaluated — Whether DMARC alignment passed, not just the raw SPF/DKIM results.
auth_results — The raw SPF and DKIM outcomes before DMARC alignment is applied. A message can pass SPF but still fail DMARC alignment if the SPF domain doesn't match the From: header.

Making Reports Human-Readable

Raw DMARC XML is difficult to work with at scale. A single busy domain can receive dozens of reports per day containing hundreds of records each. Tools like DDMARC automatically collect, parse, and visualize this data so you can:

See a timeline of authentication pass/fail rates across all providers
Identify unknown sending sources with IP geolocation and ASN lookup
Track progress as you move from p=none toward p=reject
Receive alerts when new, unrecognized senders appear

Frequently Asked Questions

How do I receive DMARC aggregate reports?

Add the rua= tag to your DMARC record with a mailto: URI pointing to an address you control. For example: rua=mailto:dmarc-reports@yourdomain.com. You can also use a third-party service like DDMARC, which provides a dedicated email address and processes reports automatically.

Why am I getting reports from providers I don't recognize?

Any mail server that receives email claiming to be from your domain will send reports if you have an rua= address configured. You may receive reports from small regional ISPs, corporate mail gateways, and international providers that your recipients use — even if you've never heard of them. This is expected and informative.

What should I do when I see failing records?

First identify the source IP. If it belongs to a legitimate service you use (e.g., your CRM or support platform), configure that service to authenticate properly — add it to your SPF record and enable DKIM signing. If the source is unknown and sending email from your domain, it may indicate spoofing — the exact threat DMARC is designed to stop.