What arrives and how to open it
Reports go to the address in the rua tag of your DMARC record. Google recommends a dedicated group or mailbox rather than your personal inbox because volume can be high. [4]
Each report is an email with an XML attachment, which should be gzip-compressed, named receiver!policy-domain!begin-timestamp!end-timestamp.xml.gz, and covering one policy domain. [1] The reporting period normally covers a single UTC day. [1] To read one, decompress it and open the XML in a text editor or browser; Google suggests loading records into a database or converting the XML with an XSL style sheet. [3]
The fields that matter
RFC 9990 replaced the reporting part of RFC 7489 and keeps the same overall shape: report metadata, the policy the receiver saw, then one record per source IP and result combination. [1] [2]
| Element | What it tells you | What to look for |
|---|---|---|
| report_metadata: org_name, email, report_id | Who sent the report | Which mailbox provider saw the mail |
| date_range: begin, end | Period covered, in seconds since 1970 UTC [1] | Convert to a date before comparing with your send log |
| policy_published: p, sp, adkim, aspf | Your DMARC record as the receiver read it [1] | Confirms the record you think is live |
| row: source_ip, count | Server that sent the mail and how many messages | Unknown IPs with large counts |
| policy_evaluated: disposition | What the receiver did: none, pass, quarantine or reject [1] | Legitimate mail quarantined or rejected |
| policy_evaluated: dkim, spf | DMARC pass or fail for aligned DKIM and SPF [2] | Both fail means DMARC failed |
| identifiers: header_from, envelope_from | Visible From domain and bounce domain [1] | A vendor bounce domain explains SPF misalignment |
| auth_results: dkim domain, selector, result | Raw DKIM check per signature [1] | The d= domain often identifies the sending service |
| auth_results: spf domain, result | Raw SPF check [1] | permerror can signal too many SPF lookups |
An annotated example
This synthetic report for example.com has three records. IPs are from documentation ranges; the vendor domain is a placeholder.
Record 1: source_ip 192.0.2.10, count 1,840, disposition none, dkim pass, spf pass, header_from example.com, DKIM d=example.com. This is your newsletter platform after domain authentication. Nothing to do.
Record 2: source_ip 198.51.100.25, count 212, disposition none, dkim fail, spf pass, envelope_from bounces.example-invoices.net, DKIM d=example-invoices.net pass. Raw DKIM passed for the vendor's domain and SPF passed for its bounce domain, but neither aligns with example.com, so DMARC failed. With p=none nothing happened; at quarantine these invoices would go to spam. Fix: set up the invoicing tool's custom domain or DKIM for example.com.
Record 3: source_ip 203.0.113.77, count 9, disposition none, dkim fail, spf fail, no DKIM signature for your domain. You do not recognize the IP and the count is small. This is likely spoofing or a misconfigured device; it is what enforcement is designed to block.
Spot unknown senders: a free weekly method
A spreadsheet is enough for one domain. Extract each record into a row and work through it once a week while you are at p=none.
- Columns: report date, org_name, source_ip, count, disposition, dmarc dkim, dmarc spf, header_from, DKIM d= domain, SPF domain.
- Sort by count, largest first; your real senders will dominate.
- Label each source by its DKIM d= domain or envelope_from domain and match it to your sender inventory.
- For rows that fail DMARC but belong to a known service, fix that service's DKIM or custom bounce domain.
- For rows you cannot match, look up the IP's owner (reverse DNS or a WHOIS lookup) before deciding it is spoofing.
- Forwarded mail often shows SPF fail with DKIM pass; that is expected and DKIM alignment carries it.
- Move to quarantine only after every known sender passes for at least a week of reports.
Free tools or a paid parser?
Google recommends a third-party DMARC service to receive, store and analyze reports, especially at volume. [3] For a small business the trade-off is time against cost.
- Before giving reports to any service, check where it stores them; reports contain your sending IPs and volumes.
- If the service's rua address is on its own domain, that domain must publish the authorization TXT record, or receivers will ignore it. [3] [4]
- The new DMARC standard, RFC 9989, removes the pct tag, so plan your rollout with policy changes rather than percentages. [5]
| Situation | Free approach works? | Why |
|---|---|---|
| One domain, under 5 senders, a few reports a day | Yes | Weekly spreadsheet review takes minutes |
| Moving from p=none to quarantine | Yes, with daily checks for the first week | You need to see failures quickly |
| Several domains or brands | Probably not | Each report covers one policy domain [1] |
| Hundreds of reports a day | No | Google notes large organizations can get thousands daily [3] |
| Need alerts when a new sender appears | No | Manual review will miss it between sessions |
Questions before you decide
Why do I get several reports a day?
Every receiving server that gets mail from your domain can send one. Google says reports are usually sent once a day and large organizations can receive hundreds or thousands daily.
What is the difference between policy_evaluated and auth_results?
policy_evaluated shows the DMARC verdict (pass or fail for aligned DKIM and SPF) and what the receiver did. auth_results shows the raw SPF and DKIM results and the domains they ran against, without DMARC interpretation. A DKIM pass for a vendor domain can still be a DMARC fail if it does not align with your From domain.
Can I send reports to a third-party address?
Yes, but if the report address is on a different domain than your DMARC record, that domain must publish a TXT record authorizing it, or receivers ignore the address.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- RFC 9990: DMARC Aggregate Reporting Accessed 29 Oct 2026
- RFC 7489: DMARC (Appendix C schema) Accessed 29 Oct 2026
- Google Workspace Admin Help: About DMARC reports Accessed 29 Oct 2026
- Google Workspace Admin Help: Set up DMARC Accessed 29 Oct 2026
- RFC 9989: DMARC Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.