How to Read DMARC Aggregate Reports

Once you publish a DMARC record with a rua address, mailbox providers start sending you daily emails with zipped XML attachments. Most people open one, see a wall of tags, and never look again. That is a shame, because DMARC reports are the only place you can see every server in the world that is sending mail using your domain, legitimate or not. Reading them is what lets you move to a strict DMARC policy without blocking your own invoices.

What an aggregate report is

An aggregate report (often called a RUA report, after the tag that requests it) is a summary from one receiving organisation, such as Google, Microsoft or Yahoo, covering one period, usually 24 hours. It contains no message content and no recipient addresses. It simply says: "we received this many messages claiming to be from your domain, from these IP addresses, and here is how they did on SPF, DKIM and DMARC."

Reports arrive as attachments compressed with gzip (.xml.gz) or zip (.zip). Extract the file and open it in a text editor or browser.

The structure of a DMARC aggregate report

Here is a trimmed example with one record:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1790985600</begin>
      <end>1791071999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>318</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>crm-vendor.net</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounces.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Reading it section by section

report_metadata

Who sent the report and which period it covers. The begin and end values are Unix timestamps (seconds since 1 January 1970, UTC); any timestamp converter will turn them into dates.

policy_published

Your DMARC record as the receiver saw it. If this does not match what you think you published, check for a typo or for a second DMARC record.

record

One block per combination of sending IP and results. The fields that matter:

The difference between policy_evaluated and auth_results is the key to reading reports. In the example, auth_results shows DKIM passed, but for crm-vendor.net. Because that domain does not align with example.com, policy_evaluated shows DKIM as fail. The message still passed DMARC overall, because SPF passed for bounces.example.com, which aligns under relaxed mode.

If policy_evaluated shows a pass for either SPF or DKIM, the row passed DMARC.

Sorting sources into three groups

Across a week or two of reports, put every source_ip into one of three groups.

1. Legitimate and passing. Your mailbox provider and properly configured tools. Nothing to do.
2. Legitimate but failing. A real service you use that is not set up correctly. These are what you must fix before moving to quarantine or reject.
3. Not yours. Spoofing or abuse. These are exactly what enforcement will block.

To identify an unknown IP, start with a reverse lookup (dig -x 198.51.100.42 +short). The host name often names the provider outright. A WHOIS lookup on the IP or the host name's domain shows which organisation owns the network. Large providers' ranges are also usually listed in their SPF records, which you can view with the DNS lookup tool.

Common patterns and what they mean

• DKIM passes for a vendor's domain, SPF passes for the vendor's bounce domain, DMARC fails. The service is sending as you but authenticating as itself. Set up custom DKIM (and, if offered, a custom return-path) with your domain.
• SPF fails, DKIM passes and aligns. Often forwarding: a recipient's server forwarded the message, so the IP is not yours, but your DKIM signature survived. DMARC still passes. This is normal.
• Both fail from a provider IP you recognise. A tool someone in your company signed up for and never configured.
• Both fail from scattered, unfamiliar IPs, in small counts. Typically spoofing or spam. Enforcement will deal with it.
• A large known mailing-list or security-gateway host. Lists and gateways that modify messages can break DKIM. Some add ARC headers so receivers can still trust the original result.

Making reports manageable

Reading XML by hand works for a small domain with a handful of sources. Beyond that, use a tool. Open-source parsers can import reports from a mailbox into a database and dashboard, and many commercial DMARC services do the same with source identification built in. Whatever you choose, use a dedicated mailbox for rua rather than a person's inbox; reports from many receivers add up quickly. If you have a developer, a short script that extracts the attachments and summarises source_ip, count and the two policy_evaluated results into a spreadsheet goes a long way.

What about failure (RUF) reports?

The ruf tag requests per-message failure reports. Few large receivers send them, largely for privacy reasons, and those that do may redact content. Do not plan your DMARC rollout around them; aggregate reports are the dependable source.

Key takeaways

• Aggregate reports summarise, per sending IP, how mail claiming to be from your domain performed on SPF, DKIM and DMARC.
• auth_results shows raw results; policy_evaluated shows whether they passed with alignment.
• Sort sources into legitimate-passing, legitimate-failing and not-yours, and fix the middle group before enforcing.
• Use a dedicated mailbox and a parsing tool once volume grows.