Two kinds of reports
RFC 7489 defines aggregate reports (rua) and forensic reports (ruf). Aggregate reports are statistics: a receiver summarises all messages it saw with your domain in the From header during a period, grouped by source IP and result. They contain no message content and no addresses of individual recipients.
Forensic reports would be copies of individual failed messages. For privacy reasons almost all large receivers do not send ruf reports, because they could contain personal data and message content. You can add ruf=, but you should not plan around it. The work happens with rua.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"How often and in what form reports arrive
Every receiver that evaluates DMARC usually sends one report per day and domain; the interval is stated in the report itself. The report arrives as a gzip or zip attachment, and the file name follows the pattern receiver!yourdomain!start!end.xml. For a domain with little traffic that is one to five reports a day, for larger clients considerably more.
Reports only come from receivers that have implemented DMARC reporting. Google, Microsoft, Yahoo and the big regional providers do, many small mail servers do not. The reports therefore never cover one hundred percent of traffic, but enough to find every relevant sender.
The XML structure
An aggregate report consists of three parts. report_metadata contains the receiver's name, a report ID and the period. policy_published shows which DMARC record the receiver saw at evaluation time, useful when you want to check whether a change has propagated. The actual content sits in the record elements, one per combination of source IP and result.
<record>
<row>
<source_ip>203.0.113.10</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>
<dkim>
<domain>example.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>bounce.newsletter-service.example</domain>
<result>pass</result>
</spf>
</auth_results>
</record>This record says: 42 messages came from 203.0.113.10. SPF technically passed, but for the domain bounce.newsletter-service.example rather than example.com, which is why policy_evaluated shows spf=fail (no alignment). DKIM was signed with d=example.com and aligned. DMARC therefore passed, and the disposition none was applied because the policy was p=none.
Reading pass and fail correctly
The most important block is policy_evaluated. It holds the DMARC results, that is SPF and DKIM including alignment. The values under auth_results are the raw authentication results without alignment. An spf=pass in auth_results together with spf=fail in policy_evaluated is not a contradiction but the typical pattern of a provider sending with its own Return-Path.
DMARC passes if at least one of the two results under policy_evaluated is pass. If both are fail, the message is either forged or one of your own senders is not yet configured correctly. The disposition shows what the receiver actually did: none, quarantine or reject. It can differ from your policy, for example because of pct= or because the receiver evaluated ARC and accepted the message anyway.
- dkim=pass, spf=pass: everything fine
- dkim=pass, spf=fail: provider with its own Return-Path or forwarding, DMARC passed
- dkim=fail, spf=pass: sender without DKIM or broken signature, will fail when forwarded
- dkim=fail, spf=fail: spoofing or one of your own senders without any alignment
Telling your own senders from spoofing
For every source IP with fail, look at three things: the reverse DNS of the IP, the domain in the SPF result under auth_results, and the count. An IP that resolves to mail-relay.newsletter-service.example and sends a thousand messages a day is one of the client's services. Hundreds of individual IPs from hosting networks around the world with one to three messages each are spoofing or spam.
Forwarding produces its own pattern: SPF fail with a foreign domain in auth_results, DKIM pass, low counts, often from universities, associations or private mail servers. That is the original recipient forwarding the message. Such entries are harmless and cannot be switched off. Where receivers support ARC you sometimes see this as a disposition of none despite a quarantine policy.
Receiving reports for many client domains
As an agency you want to collect the reports of all client domains in one place, for example at dmarc@agency.example. For a receiver to send reports to an address in a different domain, the destination domain has to consent. It does so by publishing a TXT record at clientdomain._report._dmarc.agency.example with the content v=DMARC1. Without this record, receivers discard the report.
With many clients you simply create a wildcard record that applies to all domains. After that every client can put rua=mailto:dmarc@agency.example in their DMARC record without you changing anything per domain.
*._report._dmarc.agency.example. TXT "v=DMARC1"
In the client's DMARC record:
_dmarc.client.example. TXT "v=DMARC1; p=none; rua=mailto:dmarc@agency.example"Tooling for analysis
Reading reports by hand works for one domain and one week. For ten clients over months you need an analysis that unpacks the XML, maps IPs to services and shows trends. The options range from open source parsers you run yourself, through free basic offerings from DNS and security vendors, to specialised SaaS services priced per domain or mail volume.
What matters is that the analysis answers two questions: which sources send with fail, and has anything changed since last week. The DMARC checker helps with the first step by showing whether the record is correct at all and which addresses reports are sent to.
Frequently asked questions
- Why am I not receiving reports although rua is set?
- Most common reasons: the record is faulty and ignored, the rua address is in a foreign domain without the _report._dmarc authorisation, or the domain sends so little that receivers have nothing to report. Check the record first, then the authorisation.
- Are the source IPs in reports the senders or the receivers?
- The senders. source_ip is the IP from which the reporting receiver accepted the message. For forwarded mail that is the forwarding server, not the original sender.
- Can I have reports sent to several addresses?
- Yes, rua accepts multiple mailto URIs separated by commas. That way the client can keep a copy while the agency does the analysis. The authorisation requirement applies to every foreign destination domain.