/Guides/Reading Aggregate Reports

Report Analysis

Reading Aggregate Reports

DMARC aggregate reports arrive as XML files that look intimidating at first. This guide teaches you how to interpret the data, identify issues, and take action to improve authentication.

10 min read

Updated January 2025

Anatomy of an Aggregate Report

Let's walk through a real aggregate report from Google. You receive these as gzipped XML email attachments.

Email Subject Line

Report domain: yourdomain.com Submitter: google.com Report-ID: 12345678901234567890

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1704067200</begin>
      <end>1704153599</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>

  <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>
    <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>
</feedback>

Understanding Each Section

1. Report Metadata (Who & When)

<org_name>google.com</org_name>

org_name: Who sent this report (Gmail, Outlook, Yahoo, etc.)

begin/end: Unix timestamps for 24-hour reporting period (Jan 1, 2025 00:00 - 23:59 UTC)

report_id: Unique identifier for this report

2. Policy Published (Your DMARC Record)

<p>quarantine</p>

p: Main domain policy (none/quarantine/reject)

sp: Subdomain policy

adkim/aspf: Alignment mode (r=relaxed, s=strict)

pct: Percentage of messages policy applies to

3. Record (The Data You Care About)

<source_ip>209.85.220.41</source_ip>

source_ip: IP address that sent email (209.85.220.41 = Google Workspace)

count: Number of emails from this IP (1,523 messages)

disposition: What Gmail did with these emails (none=delivered, quarantine=spam, reject=blocked)

dkim/spf: Authentication results (pass/fail)

Interpreting Authentication Results

✅ PASS: Both SPF and DKIM Pass

Meaning: Perfect! Email is fully authenticated. This is your legitimate email passing through.

Action: No action needed. Document this IP as legitimate sender.

✅ PASS: SPF Fails, DKIM Passes

Meaning: DMARC still passes! Only ONE of SPF/DKIM needs to pass for DMARC compliance.

Common cause: Email forwarding (breaks SPF but DKIM survives).

Action: No action needed if DKIM passes. This is normal for forwarded email.

⚠️ PARTIAL: Only One Passes (SPF or DKIM)

Meaning: DMARC passes (only one required) but you're missing redundancy.

Risk: If SPF breaks (forwarding), email will fail DMARC.

Action: Configure DKIM for this sender for redundancy.

❌ FAIL: Both SPF and DKIM Fail

<disposition>reject</disposition>

Meaning: DMARC FAILS. This is either a spoofing attempt OR misconfigured legitimate sender.

Action required:

Look up source IP (whois, reverse DNS)
If legitimate: Add to SPF record and configure DKIM
If unknown/suspicious: This is spoofing - your DMARC policy is blocking it

Step-by-Step Report Analysis

Open the XML File

Download attachment from report email. Decompress .gz file (gunzip on Mac/Linux, 7-Zip on Windows). Open XML in text editor or use online DMARC XML parser.

Check Date Range

Convert Unix timestamps to dates. Reports cover 24 hours. Example: 1704067200 = Jan 1, 2025 00:00 UTC.

Find All <record> Sections

Each <record> represents one unique sending source. A report might have 5-50 records depending on your email volume and number of ESPs.

Identify Source IPs

For each record, look up the source IP:

209.85.x.x = Google Workspace

167.89.x.x = SendGrid

205.201.x.x = Mailchimp

Unknown IP? Use whois lookup

Check Pass/Fail Status

For EACH record, check if SPF and/or DKIM passed. DMARC passes if at least ONE of them passes with alignment.

Create Action Items

Passing sources: Document as legitimate. Failing legitimate sources: Fix SPF/DKIM. Unknown failing sources: Monitor for spoofing.

Common Patterns You'll See

High Volume, All Passing

source_ip: 209.85.220.41

dkim: pass, spf: pass

Interpretation: Your primary email server (Google Workspace). Everything is working perfectly.

Low Volume, All Failing

source_ip: 185.220.101.x (unknown)

dkim: fail, spf: fail

Interpretation: Likely spoofing attempt. Low volume suggests manual attack or testing. Your DMARC policy blocked it.

Known ESP, Partial Pass

source_ip: 167.89.x.x (SendGrid)

spf: pass

dkim: fail

Interpretation: SendGrid authenticated with SPF but DKIM not configured. Action: Set up DKIM signing in SendGrid dashboard.

Tools for Easier Analysis

• TrustYourInbox: Automatic parsing, visualization, and alerts
• DMARC XML Converter (free): Paste XML, get human-readable summary
• Postmark DMARC Digests: Weekly email summaries
• dmarcian: Enterprise reporting platform

Skip Manual XML Parsing

TrustYourInbox automatically analyzes your aggregate reports and highlights issues that need attention. No XML expertise required.

Start Free Trial See Report Dashboard