The moment your DMARC record carries a rua= address, the reports start arriving. Google, Microsoft, Yahoo, and dozens of smaller providers each send you a daily summary of every message that claimed to be from your domain. It is the single most useful thing DMARC produces — and it lands as gzipped XML with a filename like google.com!yourdomain.com!1719360000!1719446400.xml.gz, so it goes straight to a folder nobody opens.
That's a shame, because that XML is the only complete inventory of who sends mail as you.
What an aggregate report is — and isn't
An aggregate report is counts, not content. It never contains a subject line, a body, a recipient, or anything a person wrote. What it contains is, for each source that sent mail as your domain over a 24-hour window: the sending IP, how many messages it sent, what your policy told the receiver to do, and whether SPF and DKIM passed and aligned.
That distinction matters for privacy and it matters for trust: you can hand these reports to anyone, because they expose no correspondence. They only expose infrastructure.
Reading one record
Strip away the header and every report is a list of <record> blocks. One looks like this:
<record>
<row>
<source_ip>203.0.113.24</source_ip>
<count>1420</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers><header_from>yourdomain.com</header_from></identifiers>
</record>
Read it in plain language: one IP address sent 1,420 messages as yourdomain.com; DKIM aligned and passed, SPF did not; your policy was none, so nothing was done. Because DKIM passed and aligned, DMARC passed overall — one aligned check is enough. This source is fine.
The two things you're hunting for in that list are simple:
- A source you don't recognize. An IP sending thousands of messages as you that you can't account for is either a shadow sender — a tool someone signed up for and forgot to tell you about — or someone spoofing your domain. Both are exactly what DMARC exists to surface.
- A legitimate source that isn't aligned. A system you do recognize, showing
dkim: failorspf: failwith no aligned pass. Right now, atp=none, its mail still gets delivered. The day you move top=reject, it stops. This is the list of things you must fix before you enforce.
Why the reports are the whole migration
Moving DMARC from p=none to p=reject safely isn't a matter of nerve — it's a matter of reading these reports until the only sources failing alignment are ones you're happy to block. Every legitimate sender has to show an aligned pass first. The reports are how you know you've reached that point. Enforce before the list is clean and you drop your own invoices; wait for the reports to go quiet and enforcement is uneventful.
The catch is volume. A mid-sized domain can receive dozens of reports a day from dozens of providers, each a separate XML file, each a snapshot. Reading one is easy. Reading all of them, every day, and noticing the new source that appeared this week is the actual work — and it's why most domains publish rua=, collect months of reports, and never look at a single one.
Start by seeing your policy
Before the reports mean anything, your record has to be collecting them — a rua= address that actually receives mail, and a policy you're ready to move off none. You can see where you stand in a few seconds: check your domain. If it reports p=none with no rua=, the reports aren't even being sent yet — and that's the first thing to change, because you can't enforce what you've never watched.