How to read DMARC aggregate reports

How you get them

Add a rua tag to your DMARC record with a mailto address. Receivers that support reporting then send one report per day for each reporting organisation, covering the mail they saw from your domain in that period. Reports usually start within a day or two of publishing the record.

If the report address is on a different domain from the one being reported on, that other domain must publish an authorization record, otherwise receivers will not send the reports.

What is inside a report

Each report has three parts. The metadata names the reporting organisation and the date range. The published policy section repeats the DMARC record the receiver saw. The records section is the useful part: one row per combination of sending IP address and authentication result.

1. source_ip: the address the mail came from.
2. count: how many messages that row represents.
3. policy_evaluated: the disposition applied (none, quarantine or reject) and whether DKIM and SPF passed with alignment.
4. header_from: the domain in the visible From address.
5. auth_results: the raw DKIM and SPF results, including which domain signed or was checked.

Reading a row

Read policy_evaluated first. A message passes DMARC if either DKIM or SPF passed and was aligned with the From domain. Both failing means the message failed DMARC.

Then use auth_results to see why. A common pattern is DKIM pass in auth_results but DKIM fail in policy_evaluated: the message was signed, but by the provider's domain rather than yours, so it was not aligned. That is a configuration task at the provider, usually enabling a custom signing domain.

Finding every sender

Group rows by source and look at the volume. Sources you recognise and that pass need nothing. Sources you recognise that fail are your work list: each is a legitimate system that would be blocked under an enforcing policy.

Sources you do not recognise are not automatically abuse. Forwarding breaks SPF and often shows up as failing mail from an unrelated mail server, and a forgotten internal system looks exactly like an unknown sender. Treat unknown as unknown until you have checked.

What the reports cannot tell you

Aggregate reports contain no message content, no subject lines and no recipient addresses. They cover only the receivers that send reports, so the totals are a sample, not all of your mail. They are also delayed by a day or more.

Failure reports, requested with the ruf tag, would contain individual messages, but most large receivers no longer send them for privacy reasons.

Using the reports to tighten policy

The decision to move from p=none to quarantine or reject should rest on the reports. When the failing rows that remain are only sources you have decided not to authorise, the policy can be tightened. CloudSpex ingests the reports, groups them by source, and can show how many of the measured messages a stricter policy would have affected, without claiming that the change is safe.