Module 5 of 6
Reading a DMARC Aggregate Report
The rua= tag in a DMARC record tells receiving mail providers where to send aggregate reports – and once DMARC is published, they start arriving daily, one XML file per sending provider, whether you ever look at them or not.
What's actually in one
Stripped down, each report is a list of rows like this:
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>1,204</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
</record>
Read as: "1,204 messages claiming to be from example.com arrived from 198.51.100.42. DKIM passed, SPF failed, and your current policy took no action on them."
Reading it for real decisions
Every row is really answering one question: is this a legitimate sender you haven't fully authenticated yet, or something spoofing you?
- A source IP you recognize (your CRM, your helpdesk, your marketing platform) failing SPF but passing DKIM is usually a configuration gap to fix – add the sender's IPs to your SPF record, or better, get them properly DKIM-aligned.
- A source IP you don't recognize, sending a meaningful volume, failing both SPF and DKIM, is the pattern worth investigating as actual abuse.
This is exactly the distinction a rollout plan has to make correctly before tightening p= from none toward reject – tightening too early, before every legitimate sender is accounted for, breaks real mail. ActiScan's own dashboard parses this same aggregate-report data per domain so you're not reading raw XML by hand to make that call.