How to read DMARC reports

The short version

• Reports arrive by email, usually once a day from each provider that received your mail, as zipped XML attachments.
• Each row is one sending IP address: how many messages, and whether DKIM and SPF passed and lined up with your From domain.
• A source you recognize that fails: fix its DKIM or SPF.
• A source you don’t recognize that fails: check it before you call it spoofing. It may be forwarding or a tool someone forgot to mention.
• A reporting service turns the XML into a readable dashboard. Google and Microsoft both suggest one.

What’s in a report?

Reports are sent to the address in your DMARC record’s rua= tag. Google’s report page describes three parts:

1. Report metadata: who sent the report (for example google.com or a Microsoft address), a report ID and the date range it covers.
2. Published policy: your DMARC record as the reporter saw it, such as p=none, sp, alignment settings.
3. Records: one entry per sending source, with the source IP address, the message count, what the receiver did, and the SPF and DKIM results.

Microsoft’s DMARC page adds that the XML is likely GZIP-compressed and that the subject line names the reporter and your domain.

How do I read one, step by step?

1. Open the attachment. Unzip it. It’s a text file in XML. A browser will display it, though a reporting service is much easier.
2. Find each <record>. Inside it, read four things:
   • <source_ip>: the server that sent the mail.
   • <count>: how many messages came from it.
   • <policy_evaluated> then <dkim> and <spf>: whether each one passed and matched your From domain. This is what DMARC uses.
   • <auth_results>: the raw SPF and DKIM results and which domain each checked.
3. Identify the source. Look up the IP address. Most reporting services name the company that owns it, such as Microsoft, Google or your newsletter tool.
4. Sort each source into one of the groups below.

What do the patterns mean?

Microsoft’s page calls out the most important pattern: SPF or DKIM shows “pass” in the raw results but “fail” under policy evaluated. That means the service is authorized, but not for your domain. It’s the classic setup gap with newsletter, CRM and invoicing tools. The fix is almost always that tool’s own “authenticate your domain” steps; see adding tools without breaking SPF.

Why do reports matter?

They’re the best list you’ll get of who sends as your domain, though not a complete one. Not every receiver sends reports, and mail rejected early for failing SPF never appears in them, as the DMARC standard (RFC 9989, section 7.1) notes. Everyone forgets something: the scanner, the old booking tool, the accounting software that emails invoices. Before you move DMARC to quarantine or reject, use the reports together with your own list of senders, including ones that send only a few times a year, such as renewal notices or annual statements. Our guide to moving DMARC from none to reject depends on reading them.

They also show abuse. A surge of failing messages from IP addresses you’ve never heard of usually means someone is sending as you. With an enforced policy, receivers are asked to quarantine or reject those messages. Each receiver makes the final call, so check what each record says the receiver actually did.

What are the common mistakes?

• Sending reports to a personal inbox. They pile up and get ignored. Microsoft recommends a dedicated mailbox or group, read by named people.
• Reading only the raw results. SPF “pass” means nothing for DMARC unless it lines up with your From domain.
• Expecting reports from everyone. Not every receiver sends them. The large providers do.
• Asking for failure reports. The ruf= tag requests per-message failure reports. Gmail doesn’t support them, and Microsoft 365 doesn’t send them, so most small businesses can leave it out.
• Using an outside reporting address without authorization. If reports go to another domain, that domain must publish a record allowing it, or receivers won’t send them.
• Panicking at failures. Some failures are expected. What matters is that every source you actually use passes.

What if no reports arrive?

• Check the record. The rua= value needs mailto: in front of the address, and the record must sit at _dmarc on your domain.
• Check the mailbox exists and isn’t filtering the reports as spam.
• Check cross-domain authorization if reports go to a service’s domain.
• Give it a few days. Reports cover the previous day and arrive only from providers that received your mail.

How much time does it take?

A small business with a handful of senders gets a few short reports a day, so a weekly look is quick once you know what you’re scanning for. Microsoft suggests weekly reviews while you’re deploying and monthly once stable. The reports themselves are free. Reporting services, which collect and chart them, charge their own fees, and many have small free tiers.

Did the report format change in 2026?

The aggregate report format now has its own standard, RFC 9990, published in May 2026 alongside the new DMARC standard. For a reader, the fields above work the same way. Reporting services handle any differences in the files.

How does E-3 handle this?

When a client’s mail is failing, we compare what the domain publishes with the services that actually send for them. DMARC reports help find the forgotten ones, and the fix is usually that tool’s own domain authentication. If you’d like a first look at your records, try the email deliverability checker.

Related questions

• How do I move DMARC from none to reject safely?
• How do I turn on DKIM in Microsoft 365 or Google Workspace?
• Someone is sending fake emails as me. What do I do?
• How do I check blocklists and my sending reputation?
• Back to the complete guide to business email that lands

Sources

1. About DMARC reports (Google Workspace Admin Help)
2. Set up DMARC to validate email in Microsoft 365: report interpretation (Microsoft Learn)
3. RFC 9989: DMARC, sections 5.3.8, 5.4 and 7.1 (IETF, May 2026)
4. RFC 9990: DMARC Aggregate Reporting (IETF, May 2026)