How to Read a DMARC Report

A DMARC aggregate report is an XML file that tells you who sent mail under your domain, how much, and whether it passed authentication. The format looks unfriendly at first, but there are only a handful of fields that matter, and once you can read them the reports become the most useful thing DMARC gives you.

What kind of reports does DMARC send?

Two kinds. Aggregate reports (the rua address in your record) are daily XML summaries from each mailbox provider, covering all the mail they saw claiming to be from your domain. Forensic reports (the ruf address) are individual copies of messages that failed, and many providers don't send them at all. The aggregate stream is the one you'll live in, so that's what we'll decode here. If you need a refresher on where those addresses are configured, see what is a DMARC record.

What's inside an aggregate report?

Each report has a header describing who sent it and the date range, followed by one or more <record> blocks. Each record is one sending source. A trimmed example:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
  <domain>example.com</domain>
  <p>none</p>
</policy_published>
<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

That one record says: Google saw 42 messages from IP 203.0.113.10 using example.com in the From address, both DKIM and SPF passed and aligned, and no enforcement was applied. That's a healthy line.

Which fields actually matter?

A few do most of the work:

Field	What it tells you
`source_ip`	The server that sent the mail. Recognize it or investigate it.
`count`	How many messages this row represents.
`header_from`	The domain in the visible From address (the one DMARC protects).
`disposition`	What the receiver did: `none`, `quarantine`, or `reject`.
`dkim` / `spf` in `policy_evaluated`	Whether each passed and aligned for DMARC.
`auth_results`	The raw SPF and DKIM results, useful for spotting alignment gaps.

The distinction worth internalizing: auth_results can show SPF pass while the policy_evaluated SPF shows fail. That gap means SPF passed for some other domain but didn't align with your From domain. Alignment is the thing DMARC adds on top of SPF and DKIM, and how DMARC works explains the mechanic.

How do I make the XML readable?

You don't have to read raw XML for long. Three options, roughly in order of effort:

Open a single file in a browser or text editor. Fine for the occasional spot check.
Use a free DMARC report viewer that accepts an uploaded file and renders it as a table.
Point your rua address at a DMARC monitoring service that ingests reports automatically and charts them over time. This is what most teams settle on once volume grows, because a busy domain generates dozens of reports a day.

What should I look for?

Start by sorting sources into three buckets. Your known senders (your email platform, your CRM, your help desk) should be passing and aligned, every time. Unknown sources that are passing usually mean a legitimate tool someone set up and forgot to mention, so track them down and authenticate them properly. Unknown sources that are failing are the interesting ones: that's either a misconfigured sender or someone spoofing your domain.

The goal is a clean picture where every legitimate source passes and aligns. Once you have that, you can tighten your DMARC policy with confidence. If a legitimate sender is failing, how to fix DMARC failures covers the common causes.

What about forensic reports?

Forensic (ruf) reports give you per-message detail on failures, including headers and sometimes the body. When you get them they're handy for troubleshooting a specific spoofing run, but expect most providers to redact heavily or skip them entirely. Don't build your process around forensic reports; build it around the aggregate data.

Reading reports is a habit more than a skill. Check them weekly during a rollout, confirm the sources you expect, and the moment something unfamiliar shows up you'll know to look. For Bird senders, the deliverability tooling and the authentication guide help you keep every source aligned.