DMARC aggregate (rua) reports explained, with a worked example

A DMARC record with a rua tag asks mailbox providers to send a daily summary of every message they saw using the domain. These reports are the only reliable way to find every service sending email as a business, and the evidence you need before enforcing DMARC. They arrive as compressed XML, which puts most people off. Here is how to read one.

Turning reports on

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Reports start within a day or two. Use a dedicated mailbox or a report-processing service; a busy domain receives many reports a day from different providers.

Reporting to another domain (for example your MSP's domain or a service) needs permission from that domain, per RFC 7489 section 7.1. If the record says rua=mailto:reports@msp.example, then msp.example must publish:

example.com._report._dmarc.msp.example  TXT  "v=DMARC1"

What is inside a report

A report has three parts: who sent it, the policy they saw, and one record per sending IP and result.

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>1760832000</begin><end>1760918399</end></date_range>
</report_metadata>
<policy_published>
  <domain>example.com</domain><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><selector>selector1</selector><result>pass</result></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Reading a record

• source_ip and count: 412 messages came from this IP during the day.
• policy_evaluated: the DMARC result. dkim and spf here mean aligned pass or fail, not the raw result. disposition is what the receiver did (none, quarantine or reject).
• auth_results: the raw SPF and DKIM results, with the domains that were checked. This is where you see that a tool passed SPF for its own domain but not yours.
• header_from: the domain in the visible From address.

Sorting what you find

Group records by sender (look up who owns each IP, or use the DKIM domain) and put each into one of four buckets:

1. Legitimate and passing: the main mail platform with aligned DKIM. Nothing to do.
2. Legitimate but failing: a CRM, invoicing or newsletter tool that is not aligned. Set up DKIM on the client's domain in that tool, or a custom return-path.
3. Forwarding: failures from mailbox providers and mailing lists that relayed real mail. Usually fine to ignore once DKIM is in place, because DKIM often survives forwarding.
4. Unknown: IPs that are not any service the client uses, sending as their domain. That is the spoofing DMARC enforcement will block.

When you are ready to enforce

Once two to four weeks of reports show every legitimate source in bucket 1, move to p=quarantine, keep reading reports for a week or two, then p=reject. The trade-offs of each step are in DMARC p=none vs quarantine vs reject.

Practical tips

• Do not read XML by hand for long. Many services parse reports into dashboards, and some have free tiers. For a single small domain, opening a few reports by hand in the first week is still a good way to learn.
• Watch for subdomains. Reports cover subdomains under the sp= policy. See DMARC for subdomains.
• Keep reporting on after enforcement. New tools get added. Reports are how you notice before mail starts bouncing.
• Check the record itself. Paste it into the DMARC record explainer to confirm the policy and destinations are what you meant.