A DMARC aggregate report is an XML file, usually gzip compressed, sent to your rua address by mailbox providers. It lists, per source IP, how many messages claimed your domain and whether SPF and DKIM passed and aligned. Read it to find legitimate senders that fail and illegitimate ones you want to block.
Where reports come from
Reports arrive only if your DMARC record has a rua tag. Without it, receivers must not generate them. RFC 9990 says each report typically covers one UTC day starting at 0000 UTC, and the file should be gzip compressed to avoid exceeding the receiver's size limit. Expect one report per receiving provider per day.
If the report address is on a different domain than the one being reported, the receiving domain must authorize it. RFC 9990 describes a DNS check at a name of the form yourdomain._report._dmarc.reportdomain, which must return a DMARC1 TXT record. This stops attackers using your policy to flood a third party with reports. Most report tool vendors set this up for you.
The sections of the file
- report_metadata: who sent the report, a unique report ID and the date range (begin and end as seconds since the epoch).
- policy_published: your DMARC policy as the receiver saw it. Check this matches what you think you published.
- record entries, one per group of messages, each with:
- source_ip and count: where mail came from, and how many messages.
- policy_evaluated: the disposition applied, plus DKIM and SPF results after alignment.
- identifiers: the From domain, and sometimes the envelope domain.
- auth_results: the raw DKIM and SPF results with the domains involved.
How to triage
Sort rows by count and work down:
- Known sender, passing: nothing to do.
- Known sender, failing: usually SPF not including the service, or DKIM signed with the vendor's domain so it does not align. Fix the setup.
- Unknown IP, failing: possible spoofing or a forgotten system. Identify the owner of the IP before deciding.
- Unknown IP, passing: someone has legitimate access to send as you. Find out who.
The difference between auth_results and policy_evaluated helps debugging. A DKIM pass in auth_results with a fail in policy_evaluated means the signature was valid but the domain did not align.
Override reasons
If a receiver did not apply your policy, the report can say why. RFC 9990 defines these types: local_policy, mailing_list, policy_test_mode, trusted_forwarder and other. Many mailing_list or trusted_forwarder rows with failing SPF are normal indirect mail and not necessarily abuse.
Use a tool, but check it
Raw XML is hard to read across many receivers. A report processor that aggregates by source and sender is worth having. Whichever you choose, confirm where it sends data, since reports reveal your sending infrastructure and volumes.
Quick check
Why do I get no reports after publishing rua?
Not every receiver sends them, and reports arrive daily, so wait a day or two. Also check the record syntax, the mailto address, and external authorization if the address is on another domain.
Sources
Last reviewed: 19 October 2026.
