DMARC Aggregate Reports: How to Read and Act on Them

The short answer: A DMARC aggregate report is a daily XML file sent by receiving mail providers — Gmail, Outlook, Yahoo, and others — that shows which servers sent email from your domain and whether each one passed SPF and DKIM authentication. To receive them, add a rua=mailto:you@yourdomain.com tag to your DMARC record. Without aggregate reports, you cannot safely progress from p=none to p=reject — you'd be enforcing blind.

When you add a rua= tag to your DMARC record, major mail providers start sending you aggregate reports every 24 hours. These reports are the core feedback mechanism of DMARC — they show you who is sending email from your domain, what authentication results those emails produce, and what receiving servers are doing with them.

Without aggregate reports, you're managing email authentication blind. You don't know which senders are passing, which are failing, or whether your domain is being spoofed. Reports are what make the phased move from p=none to p=reject possible to do safely.

This guide covers what's in aggregate reports, how to read them, and what actions to take based on what you find.

How to Turn On Aggregate Reports

Add a rua tag to your DMARC record:

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

The email address you specify will receive reports from every major mail provider that processes email claiming to come from your domain. Google, Microsoft, Yahoo, Apple Mail — they all send reports if your DMARC record requests them.

A few things to note:

• Reports arrive daily, usually in the first hours of the day UTC
• Each report covers a 24-hour window (the reporting interval can be changed with ri=, but 86400 seconds — one day — is the standard)
• The report is attached to the email as a .xml.gz compressed file
• You may receive reports from many providers once your domain has significant email volume

Don't have a DMARC record yet? Generate one free — DMARC Record Generator at EmailAudit.io

What's in an Aggregate Report

The raw report is an XML file. Here's a simplified version of what it contains:

<feedback>
  <report_metadata>
    <org_name>Google LLC</org_name>
    <date_range>
      <begin>1746403200</begin>
      <end>1746489599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <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>
    <row>
      <source_ip>198.37.153.200</source_ip>
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

The key fields in each row:

Reading a Report: What to Look For

1. Sources where both SPF and DKIM pass

These are legitimate senders correctly configured. In the example above, 209.85.220.41 (a Google IP) sent 142 emails that all passed both SPF and DKIM. This is what you want to see for every sender.

2. Sources where both SPF and DKIM fail

This is the critical signal. An IP sending email from your domain where both checks fail is either:

• A legitimate sender that isn't configured correctly (missing from your SPF record, DKIM not set up)
• A spoofing or phishing attempt using your domain

Look up the IP to identify which it is. Tools like whois or an IP lookup service will tell you which organisation owns it.

3. Sources where only one of SPF or DKIM passes

DMARC requires at least one of SPF or DKIM to pass and be aligned with the From domain. A source where only one passes isn't necessarily failing DMARC — it depends on alignment. But it's worth investigating why both aren't passing.

4. Unexpected sources

Any IP you don't recognise as one of your legitimate sending services is a red flag. It could be:

• A service your team started using without updating the SPF record
• A shadow IT tool someone connected without IT's knowledge
• An active spoofing attempt

Track down every unknown IP before moving your DMARC policy toward enforcement.

The Reports Are XML — Do I Have to Read Them Manually?

The raw XML is readable but tedious at scale. Several free and low-cost tools parse DMARC reports and present them in a visual dashboard:

• DMARC Analyzer (free tier available)
• Postmark's DMARC reporting (free)
• Google Postmaster Tools (free, Google-sourced data)
• Dmarcian (paid, detailed)
• Valimail (paid, enterprise)

For most small to mid-sized businesses, a free tier is sufficient. You're primarily looking for pass/fail patterns and unexpected sending sources — you don't need enterprise analytics. For a detailed breakdown of each option and which stage they're suited to, see the best DMARC monitoring tools comparison.

Alternatively, if your domain has low email volume, reading the raw XML periodically is manageable. The structure is consistent once you know what to look for.

How Reports Guide Your DMARC Policy Progression

This is the core purpose of aggregate reports: they tell you when it's safe to move to the next DMARC enforcement level.

Moving from p=none to p=quarantine

You're ready when:

• All known legitimate senders appear in reports with consistent pass results for both SPF and DKIM
• No unexpected sending IPs appear in reports
• You've investigated and resolved any failing sources

Give it 2–4 weeks of clean reports before moving.

Moving from p=quarantine to p=reject

You're ready when:

• No legitimate email is appearing in spam folders (which is where quarantine sends failing mail)
• DMARC reports show 100% pass rates for all legitimate sources over at least 2 consecutive weeks
• You've confirmed no edge cases — automated systems, legacy mail servers, or third-party tools — are sending email in a way that would fail under p=reject

Common things to fix before enforcing

What Happens If You Never Configure rua?

Without a rua address, you publish a DMARC record that applies a policy but gives you no visibility into what's happening. You're enforcing blind.

This means:

• You can't identify which senders are failing before you enforce
• You can't catch misconfigured legitimate senders before they get blocked
• You have no evidence of spoofing attempts
• You can't safely progress from p=none to p=reject

The rua tag is not optional if you want to use DMARC effectively. Add it from day one.

Related Guides

• DMARC Policy: None vs Quarantine vs Reject — When to Use Each
• How to Set Up DMARC for Google Workspace
• Email Authentication for Microsoft 365
• SPF, DKIM, and DMARC: What They Are and Why Every Business Needs All Three

Check your current DMARC record and reporting configuration — free DMARC Scorer at EmailAudit.io. Or get a free Full Audit PDF showing your complete authentication status and recommended next steps. No account required.