DMARC Report Analyzer: How to Read and Act on Aggregate Reports

Report Types: Aggregate vs Forensic

Feature	Aggregate (rua)	Forensic / Failure (ruf)
Format	XML (gzipped)	AFRF message (RFC 6591)
Frequency	Daily (typically)	Per-failure (real-time)
Content	Statistics: IP, count, SPF/DKIM/DMARC results	Full message headers of failing emails
Privacy	No PII—only IPs and counts	May include headers with recipient addresses
Adoption	Universally supported	Many providers refuse to send forensic reports

Aggregate Report XML Structure

Each aggregate report follows the schema defined in RFC 7489 §7. Here is an annotated example:

<feedback>
  <!-- Report metadata: who generated it and the reporting period -->
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>17248456789012345678</report_id>
    <date_range>
      <begin>1712880000</begin>  <!-- Unix timestamp: start of period -->
      <end>1712966400</end>      <!-- Unix timestamp: end of period -->
    </date_range>
  </report_metadata>

  <!-- Your published DMARC policy as seen by the reporter -->
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>   <!-- DKIM alignment: r=relaxed, s=strict -->
    <aspf>r</aspf>     <!-- SPF alignment: r=relaxed, s=strict -->
    <p>reject</p>      <!-- Policy: none, quarantine, reject -->
    <pct>100</pct>     <!-- Percentage of messages policy applies to -->
  </policy_published>

  <!-- One <record> per unique source-IP + result combination -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1524</count>
      <policy_evaluated>
        <disposition>none</disposition>   <!-- Action taken: none, quarantine, reject -->
        <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>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Key Fields Explained

Field	Location	Meaning
source_ip	row	The IP address that sent the email. Key for identifying the sending server.
count	row	Number of messages from this IP with the same result combination.
disposition	policy_evaluated	What the receiver did: none, quarantine, or reject.
dkim / spf	policy_evaluated	DMARC-level pass/fail (includes alignment check).
auth_results	record	Raw SPF and DKIM authentication results before alignment evaluation.
header_from	identifiers	The domain in the From: header—must align with SPF or DKIM domain.

Analysis Workflow

Identifying Legitimate vs Spoofing Sources

Indicators of a legitimate source with a configuration problem:

• IP belongs to a service you use (check the provider's published IP ranges).
• DKIM passes but SPF fails (common when third-party sends on your behalf without SPF include).
• Consistent, moderate volume matching expected sending patterns.

Indicators of spoofing/phishing:

• IP belongs to an unknown hosting provider or residential ISP.
• Both SPF and DKIM fail with no alignment.
• Irregular volume spikes, especially from geographic regions you don't operate in.

IP Investigation

For each suspicious source IP, perform:

1. Reverse DNS — dig -x 209.85.220.41 to get the PTR record.
2. WHOIS — Identify the network owner (ISP, cloud provider, or hosting company).
3. Reputation Check — Query blocklists (Spamhaus, Barracuda) and reputation services.
4. Geo-location — Map the IP to a country to cross-reference against your expected sending regions.

Escalation Criteria

Escalate to your security team or email administrator when:

• A single source IP sends > 1,000 messages with both SPF and DKIM failing.
• Spoofing volume exceeds 10% of your total legitimate email volume.
• The spoofing source IP is on a known bulletproof hosting network.
• You detect spoofing patterns targeting your customers or partners.

Automated Processing

For domains receiving more than a handful of reports daily, manual parsing is impractical. Automate with:

• A dedicated rua mailbox with auto-extraction and XML parsing scripts.
• Third-party DMARC analytics platforms (Valimail, dmarcian, Postmark) that aggregate and visualize data.
• Open-source tools like parsedmarc that ingest reports into Elasticsearch for dashboarding.

Common Report Patterns

Pattern	Likely Cause	Action
High volume, SPF pass, DKIM pass	Normal legitimate traffic	No action needed
SPF fail, DKIM pass, from known provider	Missing SPF include: for the provider	Add the provider to your SPF record
SPF pass, DKIM fail, from your own IP	DKIM signing not enabled or key mismatch	Verify DKIM configuration and selector
SPF fail, DKIM fail, from unknown IP	Spoofing or phishing attempt	Ensure DMARC policy is p=reject; investigate IP
Small volume, SPF fail, from residential IP	Auto-forwarding by a recipient	Usually benign; monitor but no action needed

Best Practices

• Set up a dedicated mailbox or group alias for rua reports—don't send them to a personal inbox.
• Review reports weekly during DMARC rollout; monthly once policy is at p=reject.
• Correlate DMARC data with your email marketing and transactional email dashboards.
• Move to p=reject only after confirming all legitimate sources pass authentication.
• Keep historical reports for trend analysis—spoofing campaigns often recur.

Common Mistakes

Mistake	Impact	Fix
Ignoring aggregate reports	Spoofing goes undetected; legitimate mail silently fails	Process reports weekly minimum
Setting p=reject without analyzing reports	Legitimate email from third-party senders gets rejected	Start with p=none, analyze, then escalate
Using a personal email for rua	Inbox overwhelmed; reports ignored	Use a dedicated functional mailbox
Not investigating failing IPs	Misconfigured senders remain broken	Look up every failing IP and categorize
Confusing raw auth_results with DMARC evaluation	Misdiagnosing pass/fail status	DMARC pass requires alignment; raw SPF/DKIM pass alone is insufficient

Tools

References

• 📄 RFC 7489 §7 — DMARC Aggregate Reports
• 📄 RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• 📄 DMARC.org — Overview and FAQ

🚀 Free ToolZilla tools used in this article

All client-side, no signup, no upload — open them in a new tab while you read:

• 🔧 DMARC Report Analyzer — try it free in your browser.
• 🔧 DMARC Checker — try it free in your browser.
• 🔧 IP Address Lookup — try it free in your browser.
• 🧰 Browse all 60+ free tools →

---