Reading DMARC aggregate reports: what the XML is actually telling you

What aggregate reports are

When you publish a DMARC record with a rua= address, receiving mail servers — Google, Microsoft, Yahoo, and thousands of others — send you a daily XML summary of every message they saw claiming to be from your domain. Each report covers one reporting period from one receiver, and it answers three questions:

1. Who is sending as you? (source IP and volume)
2. Did they pass SPF and DKIM?
3. Did those pass results align with your From: domain?

Raw, the XML is unfriendly. But once you know the shape, it's the single most useful artifact in email authentication — it's how you find the systems you forgot about and the attackers you didn't know about.

Anatomy of a report

Every report opens with metadata and the policy the receiver applied:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>...</begin><end>...</end></date_range>
</report_metadata>
<policy_published>
  <domain>yourdomain.com</domain>
  <p>reject</p>
  <sp>reject</sp>
  <pct>100</pct>
</policy_published>

Then comes the part that matters — one <record> per sending source:

<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>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>yourdomain.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Read it like this: 42 messages came from 203.0.113.10, claiming to be from yourdomain.com, and they passed both DKIM and SPF with alignment. That's a healthy, legitimate source.

The fields that matter most

• source_ip — who actually sent the mail. Reverse-look it up. Recognize it (your ESP, your mail server) or you don't.
• count — how many messages. A high count from an unknown IP is your first spoofing signal.
• policy_evaluated — the aligned pass/fail. This is the verdict DMARC acts on.
• auth_results — the raw SPF/DKIM result before alignment. The gap between this and policy_evaluated is almost always an alignment problem.
• disposition — what the receiver did: none, quarantine, or reject.

Key distinction: auth_results can say SPF pass while policy_evaluated says SPF fail. That means the mail authenticated against some domain — just not yours. Classic misalignment, and exactly what attackers exploit.

Reading the four common patterns

Pass / aligned. Both checks pass and align. Legitimate, authorized mail. Nothing to do.

Pass raw, fail aligned. SPF or DKIM passes but against the wrong domain. Usually a third-party platform signing with its own domain. Fix the alignment — don't ignore it.

Fail / forwarded. SPF fails but DKIM passes. Typically a mailing list or forwarder that rewrote the path. DKIM survives forwarding, which is why alignment on DKIM is what you lean on.

Fail / unknown source. Both fail, from an IP you don't recognize, often in volume. This is the one to investigate — it's spoofing until proven otherwise.

Spotting spoofing

The reports make impersonation visible. Look for:

• Unfamiliar source IPs sending in volume with both checks failing.
• Geographic anomalies — bursts from networks where you have no infrastructure.
• Failing mail that spikes around a phishing campaign against your brand or customers.

While you're at p=none, those messages still reached inboxes — the report is your evidence to justify moving to enforcement. Once you're at p=reject, the same records show the receiver rejecting the spoof. That's the system working: you can see the attack and see it being blocked.

From XML to insight

Nobody should read raw XML at scale — a handful of receivers a day across several domains is thousands of lines. The job is aggregation: group by source, resolve IPs to organizations, separate aligned-pass from everything else, and surface the unknowns. That's exactly what DDMARC does — turning the daily flood of reports into a readable view of who sends as you and what's failing.

If you're using these reports to drive toward enforcement, pair this with the rollout playbook. The reports tell you when it's safe to advance; the playbook tells you how.