How to read DMARC reports

DMARC aggregate reports are the main way to see who is sending mail as your domain across the internet. They arrive as compressed XML attachments that are hard to read by eye. To turn one into a readable table, drop the file into our free DMARC Report Analyzer, which parses it in your browser. This guide explains every part of a report under RFC 9990, shows how to sort the rows into "fix", "ignore" and "block", and tells you when the data is good enough to move to enforcement.

What is a DMARC aggregate report?

When your DMARC record includes rua=mailto:..., receivers that support reporting send you a summary of the mail they saw using your domain. Since May 2026 the format is defined in RFC 9990, which replaced the schema in RFC 7489 Appendix C. RFC 9990 describes reports as "daily (or more frequent)" and says a period typically covers "a single UTC day, beginning at 0000UTC".

Each report is an email with the XML attached. RFC 9990 says the XML should be GZIP-compressed, and the file name follows this pattern:

receiver!your-domain!begin-timestamp!end-timestamp.xml.gz

Google notes that every server you send mail to may send its own daily report, and that large organizations can receive hundreds or thousands a day. Both Google and Microsoft suggest using a DMARC reporting service or your own tooling to parse them. Microsoft also advises sending reports to a dedicated mailbox or group, not a user's inbox.

If your reports go to a mailbox on a different domain, that domain must authorize it with a record at yourdomain._report._dmarc.otherdomain. RFC 9990 says that if the check fails, the receiver "MUST" ignore the address. Our DMARC record examples show the exact record.

What does a DMARC report look like?

Here's a shortened report for example.com, with two records:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>dmarc-noreply@receiver.example</email>
    <report_id>20261008.example.com.1</report_id>
    <date_range><begin>1791417600</begin><end>1791503999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.10</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>bounces.mailer.example</envelope_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounces.mailer.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>203.0.113.77</source_ip>
      <count>36</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

The first row is a legitimate mailing service: DKIM is signed with your domain, so DMARC passes even though SPF doesn't align. The second row is an unknown IP failing everything: likely spoofing.

The begin and end values here are 8 October 2026, 00:00:00 to 23:59:59 UTC. Reports from receivers still using the older RFC 7489 schema look slightly different: they lack the newer elements such as np and testing, and may include pct. Microsoft's own sample report, for example, still shows a pct element.

What does each field mean?

report_metadata and policy_published

Check policy_published first. If it doesn't match what you think you published, the receiver may have cached an old record, or found a different one.

record: one row per source

The most common confusion is between the two places that show SPF and DKIM. auth_results gives the raw result: did the signature verify, did SPF pass for that domain? policy_evaluated gives the result DMARC used: did it pass and align with your From domain? An SPF pass in auth_results with fail in policy_evaluated means the service is authorized for its own domain but not aligned with yours.

RFC 9990 defines disposition=pass as "No action, passing DMARC w/enforcing policy". none means no action was taken.

reason: policy overrides

Receivers can ignore your policy and say why. The allowed types are local_policy, mailing_list, trusted_forwarder, policy_test_mode and other. A mailing_list or trusted_forwarder reason usually means the receiver recognized a forwarding path and delivered mail that technically failed.

How do you tell legitimate senders from spoofing?

Group rows by source_ip and look up who owns each IP. A reverse DNS name often tells you; the PTR Lookup helps. Then sort each source into one of these patterns:

Forwarding is the main source of false alarms. RFC 9989 section 7.4 says forwarded mail "will most likely fail SPF checks" unless the forwarder rewrites the envelope sender, while "DKIM signatures will generally remain valid". That's why aligned DKIM matters more than SPF before you enforce.

Be careful with low counts. One or two messages from a home IP may be a staff member's phone app or a printer. Ask before you assume it's an attack.

What about failure (forensic) reports?

The ruf tag requests failure reports: one report per failing message, defined in RFC 9991. They use the Abuse Reporting Format and can include headers and parts of the message. RFC 9991 warns that they "may include PII and non-public information", recommends redaction, and notes that many large providers limit or disable them. Microsoft 365 doesn't send them at all, even if your record asks.

In contrast, RFC 9990 says aggregate reports contain no personal information such as individual mail addresses, and no message content. For most domains, aggregate reports are enough.

When are you ready to enforce?

RFC 9989 is clear that p=none comes first. Section 5.1.5 says the reason "is to ensure that nothing's been missed in the initial SPF and DKIM deployments". Section 5.1.7 warns it "may take many months of consuming DMARC aggregate reports" to get there.

Use this checklist before moving from p=none to quarantine:

1. Every source you recognize passes DMARC through aligned DKIM, aligned SPF, or both.
2. The remaining failures are forwarding, mailing lists, or sources you've confirmed are not yours.
3. You've had at least a few weeks of reports, covering month-end, payroll and newsletters.
4. Reports come from the large mailbox providers your recipients use.
5. Subdomains that send mail have their own SPF and DKIM.

Then follow a staged rollout. Moving DMARC from p=none to p=reject covers it step by step, and the DMARC Generator builds each stage's record. Keep reading reports after you enforce. A new tool someone signs up for will show up there first.

Next steps

1. Check your record with the DMARC Checker and confirm it has a working rua address.
2. Send reports to a dedicated mailbox, and use a parser or reporting service rather than reading raw XML. For a single file, the DMARC Report Analyzer groups the rows by sender and shows what fails.
3. For each failing service, confirm SPF with the SPF Checker and DKIM with the DKIM Checker.
4. Read SPF vs DKIM vs DMARC or what DMARC is if alignment still feels unclear.
5. If a source keeps failing and the table above doesn't explain it, work through why DMARC fails.

iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC records change. Its DMARC monitoring, included in Protect and Protect Plus, collects these aggregate reports for you once you add rua=mailto:dmarc@iblockspam.com to your record: it shows who sends as your domain, what passes, and when it's safe to tighten your policy. It reports on mail; it doesn't block anything by itself.

Browse our other SPF, DKIM and DMARC guides.