What are DMARC aggregate reports?

When you publish a DMARC record for your domain, you can include a rua= tag that tells receiving mail servers to send you aggregate reports. These reports are XML files that summarize how email claiming to come from your domain performed against SPF and DKIM checks.

Every major email provider (Gmail, Outlook, Yahoo, and others) generates these reports. They arrive daily (sometimes more frequently) and contain data about every message that used your domain in the "From" header.

The formal name is "DMARC Aggregate Feedback Reports," defined in RFC 7489. Most people just call them RUA reports.

Why aggregate reports matter

Without aggregate reports, DMARC is a policy you set and hope works. With them, you get visibility into:

This data is essential before tightening your DMARC policy from p=none to p=quarantine or p=reject. Moving to a strict policy without reviewing aggregate reports risks blocking legitimate email from third-party services you forgot to authorize.

What is inside an aggregate report?

Each report is an XML file (often gzip-compressed) containing:

Report metadata

Record rows

Each row represents a group of messages from the same source IP with the same authentication results:

How to read an aggregate report

Raw XML is not practical to read. A typical report from Gmail for a moderately active domain can contain dozens of rows. Here is a simplified example of what one record looks like:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This tells you that 142 messages came from IP 209.85.220.41, both DKIM and SPF passed, and the receiver took no adverse action. You would then look up that IP to confirm it belongs to one of your authorized senders.

Setting up aggregate reports

Step 1: Add the rua tag to your DMARC record

Your DMARC DNS TXT record should include the rua tag:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

You can specify multiple recipients by separating them with commas.

Step 2: Create a mailbox or use a processing service

Aggregate reports arrive as email attachments. For low-volume domains, a dedicated mailbox works. For anything beyond a few reports per day, use a DMARC report processing tool that parses the XML and presents dashboards.

Step 3: Monitor for 2 to 4 weeks before changing policy

Start with p=none so no email is blocked. Review the reports to identify:

Step 4: Fix alignment issues

Common fixes:

Step 5: Tighten your policy

Once all legitimate sources pass both SPF and DKIM with proper alignment, move from p=none to p=quarantine, then to p=reject. Continue monitoring aggregate reports after each change to catch any regressions.

Common mistakes

Aggregate vs. forensic reports

DMARC defines two report types:

Forensic reports are more detailed but raise privacy concerns, and many large providers (including Gmail) do not send them. Aggregate reports are the foundation of DMARC monitoring: start with these.

Key takeaways

Check your DMARC configuration now