Learn · Email authentication
DMARC reports 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.
Who sends them, and when
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:dkimandspfhere mean "passed and aligned to your From domain", anddispositionis what the receiver actually did (underp=none, alwaysnone).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).
Privacy note: aggregate reports contain no message content, subjects, or recipient addresses — just counts, IPs, domains and authentication results. There's also a second, rarer type (RUF "forensic" reports with per-message detail); most large providers no longer send them precisely because of the privacy implications, so aggregate reports are the ones that matter.
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.