How to Read DMARC Reports: A Practical Guide to Understanding Aggregate and Forensic XML

**DMARC aggregate reports are XML files that list every IP address that sent email from your domain, how many messages each sent, and whether SPF, DKIM, and DMARC passed or failed for each source. They’re sent by receiving mail servers (Gmail, Outlook, Yahoo, etc.) to the address you specified in your DMARC record’s rua= tag — typically once per day.

DMARC (RFC 7489) ties SPF and DKIM together by requiring alignment between the envelope sender and the visible From header. According to Google’s February 2024 bulk sender requirements, a DMARC policy of at least p=none is now mandatory for any domain sending 5,000+ messages per day to Gmail users.

From an operations standpoint, the difference between a domain with DMARC monitoring and one without is visibility, says Vasile Diaconu, Operations Lead at DuoCircle. We see organizations discover unauthorized senders they didn’t know existed within 48 hours of enabling DMARC reporting. That visibility alone justifies the setup time.

The problem: raw DMARC XML reports are unreadable. A single day’s reports from a domain with moderate email volume can contain dozens of XML files, each with hundreds of records. That’s why DMARC Report exists — it parses and visualizes them automatically.

What Does a DMARC Aggregate Report Look Like?

Here’s a simplified example of the key XML structure:

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

<feedback>
  <reportmetadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1711929600</begin>
      <end>1712016000</end>
    </date_range>
  </reportmetadata>
  <policypublished>
    <domain>yourdomain.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policypublished>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1523</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

What Do the Fields Mean?

Field	Meaning
org_name	Which receiver sent this report (google.com, outlook.com, yahoo.com, etc.)
date_range	The time period covered (Unix timestamps)
domain	Your domain being reported on
p	Your published DMARC policy
source_ip	The IP address that sent email from your domain
count	How many messages this IP sent during the reporting period
disposition	What the receiver did: none (delivered), quarantine (spam), or reject (blocked)
dkim	DKIM result: pass or fail
spf	SPF result: pass or fail

How Do You Read the Results?

Look for three things: 1. Sources with pass on both DKIM and SPF — these are your legitimate, properly configured senders. No action needed.

2. Sources with fail on SPF or DKIM but legitimate IPs — these are your real senders that aren’t properly authenticated. Fix their SPF/DKIM configuration.

3. Sources with fail on both from unknown IPs — these are unauthorized senders (potentially spoofing your domain). When you move to p=reject, these get blocked.

Why Not Read XML Manually?

• A medium-traffic domain receives 10-50 XML reports per day from different receivers
• Each report can contain hundreds of source IP records
• You’d need to reverse-DNS every IP to identify the sender
• Tracking trends over time requires a database

DMARC Report solves all of this — it ingests XML automatically, identifies senders by name (Google, Microsoft, SendGrid, etc.), tracks trends, and alerts you to unauthorized senders.

Start analyzing your DMARC reports → Check your DMARC record →

Sources

• CISA Binding Operational Directive 18-01
• Microsoft Outlook DMARC Enforcement May 2025 (2025)
• PCI DSS v4.0 — DMARC Requirement (2025)
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)