You’ve set up DMARC with a rua= address, and now your inbox is filling with emails from Google, Microsoft, Yahoo and others, each with a zipped file attached. Inside is a wall of XML. This guide explains what those reports are, how to read one, and, most importantly, what to do with what you find.
What a DMARC aggregate report is
When you publish a DMARC record with a rua=mailto: address, mailbox providers send you a summary of all the email they received claiming to be from your domain. Each report usually covers one day from one provider and tells you:
- which servers (IP addresses) sent email as your domain
- how many messages each one sent
- whether those messages passed SPF and DKIM, and whether they aligned with your domain
- what the provider did with them under your policy
Reports contain no message content and no recipient addresses, just counts and authentication results. They usually arrive as .xml.gz or .zip attachments with names like google.com!yourdomain.co.uk!1759276800!1759363199.xml.gz: the reporter, your domain, then the start and end of the reporting period as Unix timestamps.
The anatomy of a report
Here’s a trimmed-down example of what you’ll see once you unzip one:
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<report_id>1234567890</report_id>
<date_range><begin>1759276800</begin><end>1759363199</end></date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.co.uk</domain>
<adkim>r</adkim><aspf>r</aspf>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers><header_from>yourdomain.co.uk</header_from></identifiers>
<auth_results>
<dkim><domain>yourdomain.co.uk</domain><selector>s1</selector><result>pass</result></dkim>
<spf><domain>bounces.platform-example.com</domain><result>pass</result></spf>
</auth_results>
</record>
</feedback>It looks intimidating, but there are only four parts that matter.
1. report_metadata: who sent the report
The provider’s name (org_name), a report ID and the time period covered. Useful for knowing which mailbox provider’s view you’re looking at, and nothing more.
2. policy_published: what your DMARC record said
This shows the policy the provider found in your DNS: your domain, your policy (p) and the alignment modes (adkim and aspf, where r means relaxed and s strict). If this doesn’t match what you think you published, check your DNS.
3. row: the headline result for each sender
Each record represents one sending IP (and one combination of results). The row gives you:
source_ip: the server that sent the emailcount: how many messages it sent in the periodpolicy_evaluated: the DMARC verdict for DKIM and SPF, which means “passed and aligned with your From domain”, plus thedisposition(what the provider did: none, quarantine or reject)
4. auth_results: the raw SPF and DKIM results
This is the part people misread. auth_results shows whether SPF and DKIM passed for whichever domain they checked. It doesn’t care whether that domain matches yours. That’s why you can see SPF “pass” here but “fail” in policy_evaluated.
In the example above, SPF passed, but for bounces.platform-example.com, the platform’s own bounce domain. It doesn’t align with yourdomain.co.uk, so DMARC counts SPF as a fail. DKIM, though, was signed by yourdomain.co.uk and passed, so the email passes DMARC overall. That’s a perfectly healthy result.
The four patterns you’ll see most often
Both pass: all good
DKIM and SPF both pass in policy_evaluated. These are typically your main mailbox provider (Microsoft 365 or Google Workspace) and properly configured platforms. Nothing to do.
DKIM passes, SPF fails: usually fine
Common for marketing platforms that use their own bounce domain, and for forwarded email (forwarding breaks SPF but not DKIM). DMARC still passes, as in the example above.
A sender you recognise fails both: fix this before enforcing
Your CRM, helpdesk, invoicing tool or website form is sending as your domain but isn’t authenticated. Set up DKIM for your domain in that platform, and add it to SPF if it uses your bounce domain. These are exactly the senders that would be blocked if you moved to p=quarantine or p=reject too early.
An IP you don’t recognise fails both: likely spoofing
Look up the IP’s owner (any IP “whois” tool will tell you the network). If it’s not a service you use, someone is sending email pretending to be you. That’s the threat DMARC enforcement stops, and a good reason not to sit on p=none for ever.
A note on the 2026 DMARC update
In May 2026 the IETF published updated DMARC standards (RFC 9989, 9990 and 9991), replacing the original 2015 specification. The aggregate report format changes slightly. For example, the DKIM selector becomes required and the pct field is dropped. Most providers still send the older format for now, so you may see both. What the reports tell you, and how you act on them, stays the same.
Why reading XML by hand doesn’t scale
One report is manageable. But a busy domain receives reports from dozens of providers every day, each listing many IP addresses, and the picture only becomes clear when you combine them over weeks. That’s why most businesses use a DMARC reporting tool that collects the files, groups IPs by sending service and flags new failures automatically.
Turn your DMARC reports into action
Our DMARC monitoring service collects your reports, identifies every service sending as your domain, flags spoofing and new failures, and guides you safely to p=reject. Not set up yet? Start by checking your records free.
