What's actually in a DMARC aggregate report

A DMARC aggregate report is a gzipped XML file that lists, for each source sending mail as your domain, the sending IP, how many messages it sent, and whether those messages passed SPF, DKIM, and DMARC alignment. Mail receivers like Google, Microsoft, and Yahoo generate one per day and send it to the address in your rua= tag, with filenames like google.com!yourdomain.com!1736380800!1736467200.xml.gz.

Most land in a folder, stay unread, and age out of the inbox. But buried in those files is the earliest warning sign that something has broken with your domain's alignment: a misconfigured ESP, a drifted SPF record, an unknown sender spoofing your domain. All of these show up within 24 hours, often before you notice any deliverability impact.

This post walks through what's actually inside one of those files, what the fields mean, and which numbers tell you something worth acting on.

The structure of an aggregate report

An aggregate report is an XML document with a root <feedback> element. It contains two top-level sections: a <report_metadata> block describing the report itself, and one or more <record> blocks describing what the receiver saw.

The metadata block tells you who sent the report (<org_name>), what time range it covers (<date_range>), and a unique report ID. The time range is always expressed in Unix epoch seconds; the filenames usually embed the same values.

Each <record> represents a group of messages that shared the same source IP and policy evaluation outcome. If Google saw 100 messages from 209.85.220.41 that all passed DKIM and failed SPF, that's one record with <count>100</count>. A single report might have dozens of records if you have multiple sending sources.

Reading the policy_evaluated block

Inside each record, the <policy_evaluated> element tells you what the receiver decided to do with those messages, and what the individual authentication checks returned.

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

The <disposition> field is the outcome: none means the message was delivered normally, quarantine means it went to spam, reject means it was refused. This reflects your published DMARC policy (p=) plus any override the receiver applied.

The <dkim> and <spf> fields here are the DMARC-level alignment results, not the raw authentication results. DKIM alignment means the d= domain in the DKIM signature matches your From domain (under relaxed mode, at the organizational domain level). SPF alignment means the envelope sender domain matches. A message passes DMARC if either one is aligned.

There's a separate <auth_results> block lower in the record that gives you the raw per-mechanism results, useful for debugging. The policy_evaluated block is what you actually need for monitoring.

What to look for first

When you're reviewing aggregate reports for the first time, start with three questions that directly impact your deliverability.

First: what's your alignment rate? Sum the counts of records where DKIM or SPF passed alignment, divide by total count. If you send 10,000 messages and 9,500 align, your rate is 95%. If this number is dropping over time, something broke: a sending service lost its DKIM key, SPF records drifted, or a new sending source isn't configured correctly. A drop in alignment shows up here before it affects your inbox placement.

Second: are there source IPs you don't recognize sending meaningful volume? An unknown IP sending a few hundred messages is worth investigation. An unknown IP sending ten thousand messages with zero alignment suggests someone is spoofing your domain, and your policy setting determines whether that mail reaches inboxes, spam folders, or nowhere.

Third: are there records with <disposition>quarantine</disposition> or <disposition>reject</disposition>? If you're at p=none, you'll see these values only if the receiving server applied a stricter policy override. If you're at p=quarantine or p=reject, this tells you whether legitimate email is being affected by your policy. This is what will cause your messages to land in spam or bounce entirely.

The raw XML makes these questions tedious to answer across multiple reports, multiple domains, multiple months. That's why tools like DMARCdrift exist: to surface the answers without requiring you to parse gzip files and do math by hand.