Once you publish a DMARC record with an rua= address, mailbox providers start sending you daily XML files. They look intimidating, but each one answers a simple question: who sent mail claiming to be from my domain, from which IP address, and did it pass?
This guide explains what is in a report and how to extract value without special tools. Context on the record itself is in what DMARC is.
What arrives and when
Aggregate reports (the "rua" ones) are usually zipped or gzipped XML attachments. They come once a day per reporting provider, covering the previous 24 hours. You will see senders such as Google, Microsoft, Yahoo and others, but only for the mail that reached their users.
There is also a "ruf" tag for forensic (per-message failure) reports. Very few providers send them, largely for privacy reasons, so do not plan around them.
Anatomy of a report
A report has three parts: who reported, what policy they saw, and the rows of data.
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1761004800</begin><end>1761091199</end></date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>yourdomain.com</header_from></identifiers>
<auth_results>
<dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
<spf><domain>yourdomain.com</domain><result>pass</result></spf>
</auth_results>
</record>
</feedback>
The fields that matter most:
| Field | What it tells you |
|---|---|
source_ip | The server that connected to the receiver |
count | How many messages that day |
policy_evaluated dkim / spf | Pass with alignment. This is what DMARC uses |
disposition | What the receiver did: none, quarantine or reject |
auth_results | Raw SPF and DKIM results, even when not aligned |
header_from | The visible From domain |
An important detail: policy_evaluated includes alignment, while auth_results does not. A row can show SPF pass under auth_results but fail under policy_evaluated. That means SPF passed for some other domain, for example a vendor's bounce domain, and did not align with yours.
A five-step method for reading them
- Group by source IP. Ignore the date and provider at first. Build a list of IPs and total counts across a week.
- Identify each IP. Look up the owner with a reverse DNS or WHOIS lookup. Most will be obvious: your mail server, your app host, a newsletter tool.
- Mark the rows that fail DMARC. Both
dkimandspfarefailinpolicy_evaluated. - Decide: mine or not mine? If it is a system you use, fix its authentication (add to SPF, or enable DKIM with your domain). If you do not recognise it, it is probably spoofing and will be blocked once you enforce.
- Repeat weekly until the only failures are sources you do not own.
Patterns you will see
- Small count from many unfamiliar IPs, all failing. Spoofing or phishing using your name. This is what enforcement is for.
- One of your tools failing both checks. It sends as your domain but has no DKIM for it and is not in SPF. Fix it before enforcing.
- SPF fails but DKIM passes for a forwarded message. Normal for forwarders. DMARC still passes because one aligned check is enough.
- Mailing-list traffic failing. Lists modify messages, which can break DKIM, and rewrite the envelope sender, which breaks alignment. Small volumes are expected.
Do you need a tool?
For one small domain, a spreadsheet and patience will do. As soon as you have several domains or daily volumes in the hundreds of rows, a DMARC report viewer saves time by parsing the XML, resolving IPs to names and graphing pass rates. Many are free for small volumes. Whichever you choose, check how it handles your data, because reports show who sends mail for you.
Getting the reports somewhere sensible
Do not send reports to your personal inbox. Use a dedicated mailbox or alias such as [email protected] so they do not drown real mail, and so the address can be handed to a team. If a report goes to a domain other than your own, that destination must publish an authorisation record, or providers will not send it.
How Mailions fits in
With Mailions you can create a mailbox for reports on the same domain, open it in browser webmail or any IMAP client, and use filters to file the daily XML out of the way. Combine that with the DMARC record in the domain's DNS checklist and you have everything needed for the monitoring stage of a safe rollout.