How to Read DMARC Reports: What the rua XML Tells You and What to Do (2026)
DMARC reports show every server that sends email with your domain. Here is how to read the XML, which fields matter, how to tell a forgotten tool from a spoofer, and what to fix next.
Kenneth Kather · Founder & CEO, KNK Outbound
Tools in this post
Key takeaways
- The rua address in your DMARC record receives daily aggregate reports from receivers such as Google, Microsoft and Yahoo: XML files listing which IP addresses sent mail as your domain and whether it passed.
- Per row, four fields matter: source IP, message count, the DKIM and SPF results, and whether the passing domain matches your From domain (alignment).
- Unknown sources that fail are either forgotten tools or spoofing; known sources that fail need DKIM signing with your domain or an SPF include before you tighten the policy.
- Aggregate reports contain no message content. Forensic reports (ruf) can contain personal data, are rarely sent by the big providers and are best left out in the EU.
The short answer
A DMARC report is a daily XML file that a receiving mail server, for example Gmail or Outlook, sends to the rua address in your DMARC record. It lists every IP address that sent email with your domain in the From line during that day, how many messages came from each, and whether they passed SPF, DKIM and DMARC. Reading it tells you two things: which legitimate services still fail, and whether someone is sending email in your name.
Few companies use this. In our DMARC study of 23,488 DACH company domains, only 45.7% have a report address at all, and 15.5% sit on p=none without one, which means they collect nothing to act on.
How to start receiving reports
Add a rua tag to your DMARC record. If you have none yet, start in monitoring mode:
v=DMARC1; p=none; rua=mailto:[email protected]
Use a dedicated mailbox, because a busy domain receives dozens of reports a day. If the address sits on another domain, for example a DMARC service, that domain has to authorise it with a TXT record named yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1. Most services set this up for you. The exact DMARC, SPF and DKIM records for the big providers are in our setup guide.
What is inside a report
Each report arrives as a zip or gzip attachment. Inside is one XML file with three parts.
| Part | Field | What it tells you |
|---|---|---|
| Metadata | org_name, date_range | Who sent the report and which day it covers |
| Published policy | p, sp, pct, adkim, aspf | The DMARC record the receiver saw for your domain |
| Records | source_ip, count | Which server sent how many messages |
| Records | disposition | What the receiver did: none, quarantine or reject |
| Records | dkim, spf (policy_evaluated) | Whether DKIM and SPF passed in alignment with your domain |
| Records | header_from | The domain in the visible From address |
| Records | auth_results | The raw results: which domain signed DKIM, which domain SPF checked |
- Field
- org_name, date_range
- What it tells you
- Who sent the report and which day it covers
- Field
- p, sp, pct, adkim, aspf
- What it tells you
- The DMARC record the receiver saw for your domain
- Field
- source_ip, count
- What it tells you
- Which server sent how many messages
- Field
- disposition
- What it tells you
- What the receiver did: none, quarantine or reject
- Field
- dkim, spf (policy_evaluated)
- What it tells you
- Whether DKIM and SPF passed in alignment with your domain
- Field
- header_from
- What it tells you
- The domain in the visible From address
- Field
- auth_results
- What it tells you
- The raw results: which domain signed DKIM, which domain SPF checked
A single record looks like this, shortened:
source_ip: 40.107.22.55
count: 412
disposition: none
dkim: pass spf: pass
header_from: yourdomain.com
auth_results: dkim yourdomain.com pass (selector1), spf yourdomain.com pass
That row is healthy: an IP address from Microsoft's range sent 412 messages, both checks passed in alignment, nothing was blocked.
How to read it in four steps
- Group by source IP. Look up who owns each address with a reverse DNS or IP lookup. Microsoft 365, Google, your CRM and your newsletter tool show up as their own providers.
- Sort by count. The big rows are your real mail flow. Fix those first.
- Check alignment, not just pass. A row can show spf pass in auth_results for the tool's own domain and still show spf fail under policy_evaluated, because the domain does not match yours. Only the policy_evaluated result counts for DMARC.
- Classify every failing row. Known service failing: fix it. Unknown source failing: spoofing or a forgotten system, find out which.
What the typical patterns mean
- Your platform passes, a tool fails DKIM. The tool signs with its own domain. Turn on custom domain authentication in the tool.
- SPF fails, DKIM passes, source is a mail provider you do not use. Usually forwarding or a mailing list. Harmless as long as DKIM passes.
- Small counts from residential or foreign IPs, both fail. Classic spoofing. This is exactly what p=quarantine and p=reject stop.
- Large counts from an unknown IP, both fail. Often a forgotten system: an old web server, a scanner, a shop plugin. Find the owner before tightening.
Once only known sources pass and the rest is noise, you are ready for the next step, explained in our guide to moving DMARC from p=none to p=reject.
Tools versus reading XML by hand
Reading XML works for a small domain and a few days. Beyond that, a DMARC report service collects the reports, groups them by sender and alerts you to new sources. Several have free tiers for low volumes. Whichever you pick, check where it stores the data. Aggregate reports contain IP addresses and domains but no message content. Forensic reports, requested with the ruf tag, can include headers and personal data, are rarely sent by the large providers, and in the EU are usually better left out.
Why we care as an outbound agency
Every sending domain we run for clients has DMARC with a report address from day one, and we read the reports, because a new failing source is often the first sign that something changed in a client's setup. If you want to check your own domain right now, our free email deliverability check shows whether DMARC is set, which policy it uses and whether a report address is in place.
Frequently asked questions
What is a DMARC aggregate report?
A daily XML summary that a receiving mail server sends to the rua address in your DMARC record. It lists every IP address that sent mail with your domain in the From line, the message count, and the SPF, DKIM and DMARC results, without any message content.
How often do DMARC reports arrive?
Most receivers send one aggregate report per day per domain. Google, Microsoft and Yahoo all send them, so a domain with normal traffic usually gets several reports every day.
Why does my report show SPF pass but DMARC fail?
Because SPF passed for a different domain than the one in your From address, usually the sending tool's own domain. DMARC needs alignment: SPF or DKIM must pass for your domain. Turn on DKIM signing with your own domain in that tool.
Do I need a tool to read DMARC reports?
Not for a few reports, the XML is readable in a browser or text editor. For ongoing monitoring a DMARC report service is easier, because it groups senders over time and flags new sources. Several offer free tiers for small volumes.
Should I use the ruf tag for forensic reports?
Usually not. Forensic reports can contain message headers and personal data, the large mailbox providers rarely send them, and in the EU they raise data protection questions. Aggregate reports via rua are enough to run DMARC well.