How to read a DMARC aggregate report
Once a domain has a rua= address in its DMARC record, mailbox providers start sending it aggregate reports — usually daily, one per sending domain per receiver (Google, Microsoft, Yahoo, and so on). They arrive as gzipped XML attachments, which is the first problem: nothing about that format is meant to be read by a person.
The shape of a report
Each report covers one time window and lists every source IP that sent mail claiming to be from your domain during that window. For each source, three things matter most:
source_ip— who actually sent the message. This is often a mail provider’s server, not a person.count— how many messages came from that IP with that exact result.policy_evaluated— what DMARC decided to do:none,quarantine, orreject.
Underneath that, each record also carries the raw SPF and DKIM results, and — this is the part people miss — whether each one was aligned.
Pass isn’t just pass/fail
SPF and DKIM can each technically succeed while DMARC still fails, because DMARC also checks alignment: does the domain that passed SPF or DKIM actually match the domain in the visible From: header? A message can have valid SPF for mail.thirdpartyvendor.com and still fail DMARC if your From: header says yourdomain.com and there’s no relationship configured between the two.
So when you’re scanning a report, the question isn’t “did SPF pass.” It’s “did SPF or DKIM pass and align with the From domain.” That combination is what determines the DMARC result for that row.
What you’re actually looking for
The first few reports after turning on monitoring are usually a surprise — marketing tools, a helpdesk platform, an old cron job on a forgotten server, all sending as your domain, some passing, some not. The job at this stage isn’t to fix anything. It’s to build a list: every legitimate source, and whether it’s currently authenticating correctly. That list is what makes it safe to move the policy forward — see the guide for how that rollout actually proceeds.