Reading DMARC Aggregate Reports: A Practical Guide

A DMARC policy tells receiving servers what to do when a message claiming your domain fails authentication. The aggregate reports, sent to the address in the rua tag, tell you what happened. Each report summarizes the mail that receiving servers saw from your domain over a period, grouped by sending IP address and by authentication result. They do not include message contents, which is what makes them safe to collect.

Where reports come from and what they cover

Each receiving mail provider that supports DMARC can send a report for the domains it has seen. Reports are typically daily and cover a 24-hour period. Coverage is partial: a report only reflects mail sent to that provider's users. A quiet report from one provider does not mean nothing is wrong elsewhere. The file name follows a convention in RFC 7489 of the form receiver!domain!begin!end.xml.gz, and the attachment is usually gzip or zip compressed.

Anatomy of a report

The XML has four main parts. Here is a trimmed example using a documentation domain and a documentation IP address:

<feedback>
  <report_metadata>
    <org_name>mx.example.net</org_name>
    <email>postmaster@example.net</email>
    <report_id>1234567890</report_id>
    <date_range><begin>1719792000</begin><end>1719878399</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>203.0.113.25</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>itpro1</selector></dkim>
      <spf><domain>example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata identifies who sent the report and the time window.
• policy_published shows the DMARC policy the receiver read from your DNS, including the alignment modes (adkim and aspf), the policy (p), the subdomain policy (sp) and the percentage (pct).
• row groups messages by source IP. The count is how many messages matched that IP and result.
• auth_results shows the DKIM and SPF checks as they were performed, with the domains that were checked.

Alignment is the important part

A message passes DMARC if SPF or DKIM passes and the domain that passed matches the From domain under the alignment mode. Passing SPF for a bounce domain that is not your From domain does not help. The policy_evaluated block shows the outcome after alignment, and that is the number to read first.

Reading the combinations

Find the senders

Group the rows by source IP and sum the counts. Each source is either something you run, something you have configured through a third party, or something you have not heard of. Look up unfamiliar IPs with a reverse DNS lookup and an organization lookup. Many reports are dominated by a few large senders, so start with the highest counts. An unknown source with a large count that fails both checks is the clearest sign of spoofing. A small unknown source that passes can be a service you forgot you use.

Move toward enforcement

1. Start with p=none and collect reports for several weeks.
2. Authorize every legitimate sender, adding SPF includes and DKIM signing where needed.
3. Move to p=quarantine, optionally with pct below 100 to limit impact while you watch.
4. When aligned legitimate mail is consistently passing, move to p=reject.

Each step should be followed by a report review. Do not skip the monitoring stage, because the most common outage comes from a legitimate sender that was never added.

Tools and handling

Parsing the XML by hand is tedious, and reports are easier to read in a tool that summarizes them. Keep the raw files as well, since they are the source of truth. The reports include IP addresses of third parties, so handle them as operational data. The DMARC reports guide explains how to configure the reporting address on ITProMail. For the record syntax and what each tag means, see SPF, DKIM and DMARC explained.

Related reading

• SPF, DKIM and DMARC in plain language
• MTA-STS and TLS-RPT explained
• DANE for email: TLSA, DNSSEC and an honest assessment