How to Read DMARC Aggregate Reports (With an Example)

DMARC reports arrive as dense XML. Learn what each field means, how to spot unauthorised senders and which failures to fix first, with a worked example.

3 min read

Once you publish a DMARC record with an rua= address, mailbox providers start sending you daily XML files. They look intimidating, but each one answers a simple question: who sent mail claiming to be from my domain, from which IP address, and did it pass?

This guide explains what is in a report and how to extract value without special tools. Context on the record itself is in what DMARC is.

What arrives and when

Aggregate reports (the "rua" ones) are usually zipped or gzipped XML attachments. They come once a day per reporting provider, covering the previous 24 hours. You will see senders such as Google, Microsoft, Yahoo and others, but only for the mail that reached their users.

There is also a "ruf" tag for forensic (per-message failure) reports. Very few providers send them, largely for privacy reasons, so do not plan around them.

Anatomy of a report

A report has three parts: who reported, what policy they saw, and the rows of data.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1761004800</begin><end>1761091199</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>yourdomain.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
      <spf><domain>yourdomain.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

The fields that matter most:

FieldWhat it tells you
source_ipThe server that connected to the receiver
countHow many messages that day
policy_evaluated dkim / spfPass with alignment. This is what DMARC uses
dispositionWhat the receiver did: none, quarantine or reject
auth_resultsRaw SPF and DKIM results, even when not aligned
header_fromThe visible From domain

An important detail: policy_evaluated includes alignment, while auth_results does not. A row can show SPF pass under auth_results but fail under policy_evaluated. That means SPF passed for some other domain, for example a vendor's bounce domain, and did not align with yours.

A five-step method for reading them

  1. Group by source IP. Ignore the date and provider at first. Build a list of IPs and total counts across a week.
  2. Identify each IP. Look up the owner with a reverse DNS or WHOIS lookup. Most will be obvious: your mail server, your app host, a newsletter tool.
  3. Mark the rows that fail DMARC. Both dkim and spf are fail in policy_evaluated.
  4. Decide: mine or not mine? If it is a system you use, fix its authentication (add to SPF, or enable DKIM with your domain). If you do not recognise it, it is probably spoofing and will be blocked once you enforce.
  5. Repeat weekly until the only failures are sources you do not own.

Patterns you will see

  • Small count from many unfamiliar IPs, all failing. Spoofing or phishing using your name. This is what enforcement is for.
  • One of your tools failing both checks. It sends as your domain but has no DKIM for it and is not in SPF. Fix it before enforcing.
  • SPF fails but DKIM passes for a forwarded message. Normal for forwarders. DMARC still passes because one aligned check is enough.
  • Mailing-list traffic failing. Lists modify messages, which can break DKIM, and rewrite the envelope sender, which breaks alignment. Small volumes are expected.

Do you need a tool?

For one small domain, a spreadsheet and patience will do. As soon as you have several domains or daily volumes in the hundreds of rows, a DMARC report viewer saves time by parsing the XML, resolving IPs to names and graphing pass rates. Many are free for small volumes. Whichever you choose, check how it handles your data, because reports show who sends mail for you.

Getting the reports somewhere sensible

Do not send reports to your personal inbox. Use a dedicated mailbox or alias such as [email protected] so they do not drown real mail, and so the address can be handed to a team. If a report goes to a domain other than your own, that destination must publish an authorisation record, or providers will not send it.

How Mailions fits in

With Mailions you can create a mailbox for reports on the same domain, open it in browser webmail or any IMAP client, and use filters to file the daily XML out of the way. Combine that with the DMARC record in the domain's DNS checklist and you have everything needed for the monitoring stage of a safe rollout.