Load a week of reports at once
One aggregate report is one receiver’s account of one day, which is too small a slice to act on. Drop in everything sitting in the rua mailbox and the counts are merged across every reporter and every day into one set of sources.
Each file can be a bare .xml, a gzipped .xml.gz, or a .zip holding either. Files are recognised by their first bytes rather than the extension, because mail clients rename attachments on the way out.
Aligned pass, not raw pass
A report carries two sets of results per row and they answer different questions. policy_evaluated holds the aligned result the receiver acted on. auth_results holds the raw SPF and DKIM outcome before alignment was considered.
The gap between them is where most misconfiguration lives. A row can show a DKIM signature that verified perfectly and still count as a DMARC failure, because the signing domain was the provider’s and not yours. The source detail spells that out per row instead of leaving two fail values with no reason attached.
The source table
Every sending IP found in the reports gets a row: message count, DMARC pass rate, the share that aligned on DKIM, the share that aligned on SPF, and what receivers did with the mail. Open a row for the From domains, the DKIM d= values and selectors, the envelope domains, which receivers reported it, and the individual records behind the totals.
Sources are named where the reports allow it. An SPF envelope domain of bounces.sendgrid.net or a DKIM d= of mcsv.net identifies the service without any lookup, because the sending provider published those domains itself.
SPF only is a fragile pass
A source that passes DMARC on SPF alignment alone is flagged, even though every message in the window passed. SPF is checked against the envelope sender, and forwarding rewrites the envelope sender. The moment a recipient forwards that mail to another address, SPF fails at the second hop and there is no aligned DKIM signature left to carry it.
Aligned DKIM survives forwarding, so a source in this state is one mailing list away from failures. Turning on DKIM signing at the sending service is the fix.
Overrides explain a delivered failure
When a receiver ignores your policy it says why, in a reason element. forwarded and mailing_list mean the failure was expected and excused. sampled_out means pct was below 100 and the message fell outside the sample. local_policy means the receiver had its own rule.
Those messages count as failures in the totals while having been delivered anyway, so a pass rate that looks poor can be mostly forwarding.
Before moving to p=reject
The findings list states how many messages in the loaded window would have been refused at p=reject rather than delivered. That number is the whole decision: it is safe to tighten the policy when everything left in it is mail you do not recognise.
Work down the failing sources first. Each one is either a service nobody added to SPF and DKIM, a service authenticating against its own domain instead of yours, or someone spoofing the domain. Only the third kind should still be failing when the policy changes.
Reverse DNS is optional
Report XML contains no host names, only addresses. The resolve button sends each address to Cloudflare’s DNS-over-HTTPS resolver for a PTR record and fills the names in as the answers arrive. It runs on request rather than automatically, because it is the one part of the page that talks to the network.
What aggregate reports leave out
Aggregate reports carry counts, not messages. There are no subjects, no recipients, no message bodies, and no timestamps finer than the report’s own day range. A source sending 4,000 messages appears as one row with a count, which is why the format is safe to share and useless for tracing a single message.
Envelope recipients are technically allowed in the format and almost never populated. Treat a report as a census of senders, and use the SPF and DMARC record checker to see what the domain currently publishes at the other end.