How to read a DMARC aggregate report

DMARC aggregate reports are XML, gzipped, sent daily, and designed to be parsed rather than read. They are also the only view you get of who is sending as your domain, so it is worth understanding the shape even if a tool does the reading.

The structure

Each report has metadata — who generated it, the date range, a report ID — then a policy block showing the policy they found published, then a series of records.

A record is a group of messages that shared a source IP and an authentication outcome, with a count. It is not one message. A record with count of 4,000 is four thousand messages that behaved identically.

The fields that matter

source_ip — who sent it. This is how you identify a source you did not know about.

count — how many. A failing source with a count of 3 is noise; the same source with a count of 30,000 is a system you forgot to authenticate.

policy_evaluated — what the receiver did: none, quarantine or reject, plus the dkim and spf alignment results. These two are alignment, not the raw mechanism results.

auth_results — the raw results, with the domain each was evaluated against. This is where you see that SPF passed for provider.net while your From domain was something else.

The gap between auth_results showing pass and policy_evaluated showing fail is the whole of the alignment problem in two fields.

Telling the three failure types apart

A legitimate source that is not aligned. Consistent source IPs, steady counts, SPF or DKIM passing against someone else's domain. This is a system you need to fix. It is the most common thing in the reports and the most useful.

Forwarding. SPF fails, DKIM passes and aligns, counts are low and the source IPs are varied — university mail systems, small hosts, personal domains. This is not a problem and there is nothing to fix. It is also the reason DKIM alignment matters more than SPF alignment.

Actual spoofing. Both fail, source IPs are scattered across consumer ISPs and hosting providers worldwide, counts are irregular. Nothing to fix on your side except enforcing a policy so it stops being delivered.

What the reports do not contain

No subjects, no recipients, no message content. Aggregate reports are counts and outcomes by design.

The forensic stream, ruf, does include message detail — but far fewer providers send it, and what arrives contains real recipient data, so treat the mailbox accordingly. Most operators do not enable it.

A practical routine

You do not need to read these daily. Once a week, look at:

• Any source IP you do not recognise with a count above a few hundred
• The ratio of aligned to unaligned volume, and whether it is moving
• Any source that was aligned last week and is not this week — usually a provider changing infrastructure or a DKIM key that expired

That last one is the case for reading them at all once you are enforcing. The initial audit is finite work; the monitoring is not.