How to read DMARC aggregate (rua) reports

When you publish a DMARC record with a rua= address, receivers like Google, Yahoo and Microsoft start emailing you daily XML summaries of all the mail they saw claiming to be from your domain. These aggregate reports are the whole point of starting at p=none: they let you discover every system sending as you — legitimate ESPs, your own servers, and any spoofers — before you turn on enforcement and risk blocking something real.

What the XML contains

Each report has a header (who sent it, the date range, and the DMARC policy they saw published) followed by one or more <record> blocks. Every record represents mail from one source IP and tells you five things: the source IP, the message count, the disposition the receiver applied (none, quarantine or reject), and the SPF and DKIM results — both the raw pass/fail and, crucially, whether they aligned with your From: domain. Here’s a single record:

A single record from a DMARC aggregate (rua) report:

  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>bounces.example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

Read it as: 128 messages from IP 203.0.113.25 claiming to be
from example.com. SPF and DKIM both aligned and passed, so
DMARC passed and disposition was "none" (delivered normally).

Two distinctions make these reports readable. First, policy_evaluated shows the aligned result DMARC used to decide, while auth_results shows the raw SPF and DKIM outcomes and the domains they authenticated — comparing the two is how you spot an SPF that passed but didn’t align. Second, DMARC passes if either SPF or DKIM aligns, so a record with one aligned pass is fine even if the other mechanism is blank.

Identifying legitimate senders vs spoofers

Aggregating records by source IP gives you an inventory of everyone sending as your domain. Sort them into three buckets:

• Legitimate and aligned. IPs you recognise — your ESP, your mail server, your CRM — showing SPF or DKIM aligned and passing. These are healthy; leave them alone.
• Legitimate but not aligned. IPs you recognise, but DMARC is failing because neither mechanism aligns — a common case is an ESP whose SPF authenticates its own bounce domain and whose DKIM signs with its domain, not yours. These are the records you must fix before enforcing, usually by setting up domain authentication and a custom Return-Path so SPF aligns, or aligned DKIM. If SPF passes but DMARC still fails, see why SPF passes but DMARC fails.
• Unknown and failing. IPs you don’t recognise, sending mail that fails DMARC. Some are forwarders (legitimate mail relayed through another server, which breaks SPF), but others are genuine spoofers impersonating your domain. Enforcement is exactly what stops the latter.

Raw XML is tedious to read at volume, which is why a parser helps once you have more than a handful of senders. You can turn on DMARC monitoring to have reports ingested and grouped by sender automatically, and confirm your published policy any time with the DMARC Checker.

How to act on them — toward p=reject

The reports are the instrument that lets you tighten policy without collateral damage. The workflow is:

1. Start at p=none and collect reports for a few weeks until you’re confident you’ve seen all your legitimate senders — including low-frequency ones like billing or support systems.
2. Fix every legitimate source so it aligns on SPF or DKIM. When your recognised senders all show aligned passes in the reports, you’re safe to enforce.
3. Move to p=quarantine, optionally with a pct below 100 to ramp gradually, and keep watching the reports for anything legitimate you missed.
4. Move to p=reject once quarantine is clean. Now spoofed mail is refused outright and only your aligned, authorised senders get through.

The full staged rollout, with the exact policy changes at each step, is in how to move DMARC to reject safely. Reaching p=reject is also a prerequisite for BIMI and the Gmail verified checkmark, so the reports pay off twice.

A note on forwarders and edge cases

Not every failing record is an attack. Mailing lists and forwarding services relay your mail from their own IPs, which breaks SPF and sometimes DKIM — they’ll show up as failures from IPs you don’t control. This is why you rely on aligned DKIM (which usually survives forwarding) and why you review the reports rather than enforcing blindly. Legitimate forwarded mail is also increasingly protected by ARC, which lets a receiver honour a prior hop’s authentication. Don’t let a few forwarder failures scare you off enforcement — identify them, confirm they’re not spoofers, and proceed.

Sources

The DMARC aggregate report format — every XML element described above — is defined in the DMARC specification, RFC 7489 (see the aggregate reporting section and Appendix C for the schema). SPF is specified in RFC 7208 and DKIM in RFC 6376. To collect and parse reports without reading raw XML, use DMARC monitoring.