DMARC Aggregate Reports (RUA): How to Read Them and Act on Them Under DMARCbis

A DMARC record without an rua address protects a domain blind: it blocks or lets through mail without ever saying who sent it. DMARC aggregate reports (RUA) fill that gap by listing, every day, which IP addresses sent mail on the domain’s behalf and how their SPF and DKIM authentication turned out. Since May 2026, the technical framework behind them has changed: RFCs 9989, 9990 and 9991 replace the 2015-era RFC 7489 and move DMARC from Informational status to a Proposed Standard at the IETF.

#Why RUA reports still matter

A domain that moves to p=reject without first reading its aggregate reports risks blocking its own marketing campaigns, its support tools, or a forgotten vendor. RUA reports give the full list of sending sources observed by major receivers (Gmail, Outlook, Yahoo) over a given period, each with its message volume and SPF/DKIM alignment verdict. It is the only data source that does not depend on the domain’s own self-reporting.

The guide on SPF, DKIM and DMARC covers setting up all three mechanisms; this one focuses on the step that follows, and that gets skipped far too often: actually putting the reports to work once the rua address is in place.

#The structure of an aggregate report

An RUA report is an XML document sent once a day by every receiver that handled mail from the domain. RFC 9990 defines its structure: a report_metadata header identifying the sending organization and the period covered, a policy_published block recalling the DMARC policy read from DNS at evaluation time, then a series of record elements, one per source/result pair.

Here is a simplified extract of what a report contains, for a single sender:

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>mail-studio.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mail-studio.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>sendgrid.net</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

This record shows a common case: the message passes DKIM (the domain’s signature is valid) but fails SPF, because the envelope sender carries the sending vendor’s domain rather than the site’s own. Since DMARC only requires that at least one of the two mechanisms pass and align, this message still counts as compliant despite the SPF failure.

#What DMARCbis (RFCs 9989 to 9991) changes

The three documents published in May 2026 split the protocol into three separate texts: RFC 9989 for the core protocol (policy, alignment, record processing), RFC 9990 for aggregate reports, and RFC 9991 for failure reports. The most visible change for reading reports concerns the discovery_method field in the policy_published block: it now states whether the organizational domain was determined via the Public Suffix List (PSL) or via an upward DNS walk, the “Tree Walk,” which no longer depends on an externally maintained list.

The pct tag, flagged as inconsistently implemented across receivers, is dropped from RFC 9989 (see its appendix dedicated to that removal). Two tags take over more precise roles:

#Reading reports without paid tooling

Receivers send reports compressed (gzip or zip) to the address declared in rua. For a modest-sized domain, a script that decompresses, parses the XML and aggregates by source_ip is plenty: most languages ship a native XML parser, and the structure described above maps cleanly onto a table. The key is to group by sender rather than reading each report individually, since the daily volume can quickly reach dozens of files for an active domain.

RUA reports only cover what receivers choose to disclose: they say nothing about a message’s final placement (inbox, promotions tab, or spam folder). For that level of detail, cross-reference aggregate reports with a receiver-specific reputation tool, such as Google Postmaster Tools on the Gmail side, which exposes a domain and IP reputation indicator independent of DMARC report content. The two sources complement each other: DMARC says who is sending and with what authentication result, Postmaster Tools says how that authenticated mail is actually perceived.

#Common interpretation pitfalls

An SPF failure is not always a problem: as soon as a message passes through a third-party sending platform (a marketing tool, a support tool), the envelope carries the vendor’s domain and SPF fails mechanically, without DKIM being affected. The reverse trap exists too: a legitimate source failing both SPF and DKIM over an extended period almost always signals an incomplete configuration at the vendor’s end, to fix before considering a stricter policy. The guide on HTML email rendering covers other gaps between what a sender sends and what an email client displays, in a similar spirit of verifying before diagnosing.

Another trap is confusing message volume with severity. An unknown source sending only a handful of messages per day deserves to be identified, but it does not justify delaying a move to p=quarantine if the bulk of sources are clean. Conversely, a source that represents a large share of total volume and systematically fails alignment must be fixed before any policy change, or risk blocking a meaningful portion of the domain’s legitimate mail. Failure reports (RUF, now defined by RFC 9991) add message-level detail to this diagnosis, but not every receiver sends them, and their content can include parts of the original message: they call for the same privacy precautions as any other email header data.

#What to take away

DMARC aggregate reports remain the most reliable data source for mapping who sends mail on a domain’s behalf. DMARCbis does not overhaul how they are read, but it clarifies how the organizational domain is determined and drops an ambiguous tag in favor of more explicit settings. Before any move to a stricter policy, the only robust method is still watching the reports over several weeks, source by source.

Further reading: the full text of RFC 9990 details the complete XML schema for DMARC aggregate reports.