Understanding a DMARC aggregate report

You published a DMARC record with a rua= address, and compressed files have been arriving in your mailbox ever since. Here is how to read them — and why they do not say what many people assume.

What it is

An aggregate report is a compressed XML file (gzip or zip), sent once a day by every mailbox provider that received mail claiming to be from your domain. It does not come from you or your host: it comes from the recipients — Google, Microsoft, Yahoo and the rest — telling you what they saw.

One direct consequence: you only get reports from providers that send them, and only for mail that reached them. A report is never an exhaustive view of what you send.

The structure of the file

report_metadata — who is speaking, and about when

The name of the reporting organisation, a report ID, and above all the period covered. Usually the previous day: DMARC is not real time, expect 24 to 48 hours of lag.

policy_published — what the provider read in your DNS

Your policy as it was seen: p (none, quarantine or reject), sp for subdomains, pct the percentage of messages concerned, and the alignment modes adkim and aspf (r for relaxed, s for strict).

This section is valuable for an unexpected reason: it tells you what the outside world actually sees. If it does not match what you believe you published, your problem is in DNS, not in your sending.

record — one entry per source IP

The heart of the report. Each entry groups messages coming from the same IP address:

• source_ip and count: who sent, and how many messages.
• policy_evaluated: the decision — the disposition applied (none, quarantine, reject) and the DKIM and SPF results after alignment.
• identifiers: the domain shown in the From: header, the one a human sees.
• auth_results: the raw SPF and DKIM results, with the domains and DKIM selector used.

The trap: raw is not aligned

This is the distinction that catches everyone out. A message can perfectly well show SPF pass in auth_results and SPF fail in policy_evaluated.

That is not a contradiction. SPF validates the envelope domain (the Return-Path), which the recipient never sees. DMARC additionally requires that domain to match the one in the visible From:. An email platform sending with its own Return-Path gets an SPF pass and an alignment failure: technically authorised, but not on behalf of your domain.

A message is DMARC-compliant as soon as SPF or DKIM passes and aligns. One of the two is enough — which is why DKIM matters, since it survives forwarding where SPF breaks.

What an aggregate report does not contain

• No message content, no subject lines, no attachments.
• No recipient addresses: these are aggregated statistics, not a send log.
• No real time: you are always looking at yesterday.
• No verdict on spam: DMARC says whether authentication passes, not whether the spam filter liked your message. Those are two separate problems.

Where to start when you open one

• The highest-volume IPs you do not recognise. It is almost always a forgotten legitimate tool — and it is what would break when you move to reject.
• Entries where neither SPF nor DKIM aligns and the volume stays flat: the typical profile of a fraudulent bulk send.
• The compliance rate over time, which says far more than a single report.

All of that works by hand on one domain over a few days. By the second domain, or after three weeks, it stops: Clarsend aggregates these reports, identifies every source IP among 23 recognised sending providers, and alerts you when the failure rate moves.