Dr.Who
← blog

How to read a DMARC aggregate (rua) report

· dmarc · rua · email · deliverability · reporting

dmarcruaemaildeliverabilityreporting

A DMARC aggregate report (the one you get from a rua= address) is an XML file that summarizes, for one reporting period, every IP that sent mail claiming to be your domain — with counts and pass/fail results for SPF, DKIM, and DMARC. You read it to find legitimate senders that fail authentication (so you can fix them) and impersonators (so you can tighten your policy). It contains counts only — no message bodies, no subjects, no recipients.

The XML structure

Every report has three parts. First, report_metadata: the org_name of the receiver that generated it (google.com, Outlook.com, Yahoo), a report_id, and a date_range with Unix begin/end timestamps — usually a 24-hour window.

Second, policy_published: an echo of the DMARC record they read for your domain. Confirm it matches what you set:

<policy_published>
  <domain>example.com</domain>
  <p>quarantine</p>
  <sp>quarantine</sp>
  <adkim>r</adkim>
  <aspf>r</aspf>
</policy_published>

Third, one or more record blocks — one per sending source.

Reading a record block

Each record has three children. The row carries source_ip, count (messages from that IP this period), and policy_evaluated with the disposition actually applied (none/quarantine/reject) plus the dkim and spf DMARC results. The identifiers block gives the header_from domain the user saw. The auth_results block shows the raw checks: spf with its domain and result, and dkim with domain, selector, and result.

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
    <spf><domain>bounce.mailer.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Note the gap: SPF result is pass in auth_results but policy_evaluated/spf is fail. That is an alignment failure — SPF authenticated bounce.mailer.net, not your header_from. DKIM saves this record.

What to actually look for

Two things matter. First, sources where DMARC failed but the mail is yours — a known IP, your ESP, your CRM. Fix it: add the source to SPF, enable DKIM signing for it, or correct alignment (use a custom return-path or d= on your own domain). Second, spikes of count from random IPs you do not recognize, failing everything. That is impersonation, and it is exactly why you turned on reporting.

Raw XML is fine for one report. At volume it is unreadable, so feed it to a parser or dashboard that aggregates by source over weeks.

Run the check on your domain →

Why no reports are arriving

If your rua inbox is empty, the usual causes, in order:

  • Syntax error in the record. A stray space or missing semicolon and receivers ignore the whole thing.
  • Missing mailto: prefix. [email protected] is invalid; it must be rua=mailto:[email protected].
  • External-domain authorization missing. If you send reports to a different domain (rua=mailto:[email protected]), that vendor must publish example.com._report._dmarc.vendor.com with v=DMARC1 to opt in. Without it, receivers silently drop the reports.
  • DNS not propagated yet. Give it up to 24–48 hours after publishing.
  • Low mail volume. Some receivers will not bother generating a report for a handful of messages.

Further reading