DMARC Aggregate Reports (RUA) Explained

Publish a DMARC record with a rua address and something remarkable happens: Google, Microsoft, Yahoo and hundreds of other mail operators start emailing you daily summaries of every message that claimed to be your domain — from anywhere in the world. Those XML attachments are aggregate reports, and they're the raw material of every DMARC decision you'll make.

What "RUA" actually stands for

rua is the DMARC tag for Reporting URI for Aggregate data — the address in your DMARC record where those daily XML summaries are sent. When people say "DMARC RUA", "RUA report" or "DMARC aggregate report", they all mean the same artefact: the compressed XML file described on this page.

There is a sibling tag, ruf — Reporting URI for Forensic data — which asks for a copy of individual failing messages rather than a daily count. Two things to know about it: most large mailbox providers stopped sending forensic reports years ago over the privacy implications, and the ones that do send them are handing you message-level detail you may not want to store. Aggregate reports are the ones that matter, and a record with rua and no ruf is the normal, correct configuration.

The tag itself is one mailto: address, or several separated by commas:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

One wrinkle: pointing rua= at an address on a different domain requires that domain's permission, published as a TXT record at yourdomain.com._report._dmarc.theirdomain.com. Monitoring services set this up during onboarding — but it is why a rua= aimed at a colleague's address on another domain can silently receive nothing. The DMARC record guide covers the rest of the tags.

Who sends them, and when

If the reports themselves are what brought you here — the daily attachments from names you don't recognise — why am I getting DMARC report emails? answers that directly, with a page per major reporter.

Any mailbox provider that evaluates DMARC can report. In practice most domains hear overwhelmingly from Google, Microsoft, and Yahoo, plus a long tail of universities, hosting providers, and security appliances. Reports typically cover a UTC day and arrive within a day or so after it ends — so expect your first report roughly 24–48 hours after publishing your record, from whichever provider received your mail first.

Each report is a gzip- or zip-compressed XML file emailed to the rua=mailto: address in your record. The format has its own specification, RFC 9990 — as of May 2026 it's a document in its own right rather than an appendix to DMARC, which is now RFC 9989. The XML you receive is unchanged.

Want to see what’s inside one right now? Drop a report into the free DMARC report analyzer — it parses the XML in your browser, nothing is uploaded, and you get the per-sender table this article describes.

What's inside

Three sections, and a trimmed real example:

<feedback>
  <report_metadata>          <!-- who's reporting, and for which day -->
    <org_name>google.com</org_name>
    <date_range><begin>…</begin><end>…</end></date_range>
  </report_metadata>
  <policy_published>          <!-- the DMARC record they saw -->
    <domain>example.com</domain><p>none</p>
  </policy_published>
  <record>                    <!-- one per source IP -->
    <row>
      <source_ip>203.0.113.7</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>…</auth_results>
  </record>
</feedback>

How to read a record:

• source_ip + count — this server sent this many messages as your domain that day. Your job is deciding whether that server is yours (your ESP, your mail platform) or an impostor — the IP's geolocation, network owner and threat flags narrow that down fast.
• policy_evaluated — the aligned DMARC verdict: dkim and spf here mean "passed and aligned to your From domain", and disposition is what the receiver actually did (under p=none, always none).
• auth_results — the raw detail: which domain each DKIM signature carried and which domain SPF evaluated. This is where you diagnose why something failed — e.g. DKIM passing but for the service's domain instead of yours (an alignment problem, fixed in the service's settings).

From XML files to decisions

One domain at modest volume can receive several reports a day from different providers, each a compressed XML file with unnamed IPs. Reading them by hand works for about a week. The questions you actually need answered — which service is this IP? what share of my mail is aligned? what breaks if I move to quarantine? — require parsing every report, resolving sources to named senders, and tracking compliance over time. That's the job of a DMARC monitoring service: Canny Pigeons receives your reports directly (your rua points at us), parses everything, identifies senders, and shows the one number that gates your next policy step.