Overview: Why DMARC Reports Matter

DMARC reports are your eyes into email authentication. They tell you:

Who is sending email using your domain (legitimate and fraudulent)

Which emails are failing SPF, DKIM, or DMARC authentication

How receivers are handling your email based on DMARC policy

What needs fixing in your email authentication setup

Report Types: DMARC uses two report types - RUA (aggregate, daily summaries) and RUF (forensic, real-time failures). Most analysis focuses on RUA reports.

Aggregate Reports (RUA) Deep Dive

Aggregate reports are XML files sent daily by major email receivers (Google, Yahoo, Microsoft). They contain summary data about all email claiming to be from your domain.

Report Structure

<?xml version="1.0"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1735689600</begin>
      <end>1735775999</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>  <!-- DKIM alignment: relaxed -->
    <aspf>r</aspf>    <!-- SPF alignment: relaxed -->
    <p>none</p>       <!-- Policy: none/quarantine/reject -->
    <sp>none</sp>     <!-- Subdomain policy -->
    <pct>100</pct>    <!-- Percentage of emails policy applies to -->
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>142</count>  <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>  <!-- What receiver did -->
        <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>
        <selector>default</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Key Fields to Understand

source_ip

IP address that sent the email. Use reverse DNS lookup to identify the sender. Common patterns: 209.85.x.x (Google), 40.x.x.x (Microsoft), 167.89.x.x (SendGrid).

count

Number of messages from this IP with identical authentication results. High counts (1000+) suggest bulk email service. Low counts (1-10) may indicate individual senders or spoofing attempts.

disposition

Action taken by receiver: none (monitoring only), quarantine (spam folder), reject (blocked). This reflects your DMARC policy.

dkim / spf results

Authentication results: pass, fail, neutral, none. DMARC passes if either SPF or DKIM passes AND aligns with the From domain.

Pro Tip: Use our XML to JSON Converter to convert XML reports to readable JSON format for easier analysis.

Forensic Reports (RUF) Analysis

Forensic reports provide real-time notification of authentication failures. They include sample email headers and full authentication details.

Example Forensic Report

From: noreply@dmarc.yahoo.com
To: forensic@yourdomain.com
Subject: FW: DMARC Failure Report for yourdomain.com

Authentication-Results: yahoo.com;
  dkim=fail reason="signature verification failed" header.i=@yourdomain.com;
  spf=fail smtp.mailfrom=yourdomain.com;
  dmarc=fail (p=none dis=none) header.from=yourdomain.com

Source-IP: 185.220.101.45
Reported-Domain: yourdomain.com
Authentication-Failure-Type: dkim

Original-Mail-From: support@yourdomain.com
Original-Rcpt-To: victim@example.com

Arrival-Date: 2025-01-20 14:32:18 GMT

Original message headers:
From: support@yourdomain.com
To: victim@example.com
Subject: Urgent: Verify Your Account
Date: Mon, 20 Jan 2025 14:30:00 +0000
...

When to Investigate RUF Reports

Unknown IP addresses - May indicate spoofing or unauthorized sending

Suspicious subject lines - Phishing attempts often have urgent or threatening language

Legitimate services failing - May indicate configuration issues

Privacy Note: Many receivers (Google, Microsoft) do not send forensic reports due to privacy concerns. Don't rely solely on RUF reports for monitoring.

Common Report Patterns & What They Mean

✅ Perfect: Both SPF and DKIM Pass

<dkim>pass</dkim>
<spf>pass</spf>
<disposition>none</disposition>

What it means: Email is properly authenticated. No action needed. This is the goal for all legitimate email.

⚠️ Caution: SPF Fails, DKIM Passes (Email Forwarding)

<dkim>pass</dkim>
<spf>fail</spf>
<disposition>none</disposition>

What it means: Email forwarding detected. SPF fails because the forwarding server's IP isn't in your SPF record, but DKIM still passes. DMARC passes overall (only needs one). Common with personal email forwarding rules.

⚠️ Action Needed: Only One Passing (Lack of Redundancy)

<dkim>none</dkim>
<spf>pass</spf>
<disposition>none</disposition>

What it means: Email passes DMARC but lacks redundancy. If SPF breaks (forwarding, IP change), DMARC will fail. Configure DKIM for this sender as backup.

🚨 Critical: Both SPF and DKIM Fail

<dkim>fail</dkim>
<spf>fail</spf>
<disposition>quarantine</disposition>
<source_ip>185.220.101.45</source_ip>
<count>1</count>

What it means: Complete authentication failure. Check: (1) Is this a legitimate sender that needs configuration? (2) Is this spoofing? Unknown IPs with count=1-5 and suspicious patterns often indicate spoofing attempts.

Troubleshooting Workflow

When you find authentication failures in reports, follow this systematic workflow:

1Identify the Source IP

Run reverse DNS lookup to identify who owns the IP:

dig -x 185.220.101.45 +short

Or use WHOIS lookup to get organization details.

2Check Email Volume

High volume (100+): Likely legitimate service (ESP, email forwarding)
Medium volume (10-100): Could be internal system or small ESP
Low volume (1-10): Individual emails or potential spoofing

3Verify Legitimacy

Ask your team:

Do we use this email service provider?
Is this a known third-party sending on our behalf?
Could this be a legitimate business partner?

4Take Action

If Legitimate:

Add IP/domain to SPF record
Configure DKIM signing with the provider
Monitor for 1-2 weeks to verify resolution

If Spoofing:

No action needed (DMARC is working as intended)
Monitor to ensure volume doesn't increase
Move to p=quarantine or p=reject to block these attempts

Automation & Tools

Manual report analysis doesn't scale. Here's how to automate:

Option 1: Free Tools

TrustYourInbox XML to JSON Converter - Convert XML reports to readable format
DMARC Analyzer - Visualize report data and trends
Parsedmarc - Open source Python tool for parsing reports

Option 2: Automated Platforms (Recommended for Scale)

TrustYourInbox Platform Features:

Automatic report collection and parsing (no manual downloads)
Real-time dashboards with pass/fail rates and trends
Automatic IP identification with known sender database
Alerts for new senders or authentication failures
One-click SPF/DKIM configuration recommendations
Progressive enforcement automation (p=none → p=reject)

Time Savings: Automated platforms reduce report analysis from 2-3 hours/week to 15 minutes/week for most organizations.

Best Practices & Next Steps

Report Monitoring Schedule

Daily: Check for critical failures (both SPF and DKIM failing)

Weekly: Review new IP addresses and senders

Monthly: Analyze pass rate trends and policy effectiveness

Key Metrics to Track

DMARC Pass Rate

Target: 95%+ passing. Below 90% indicates configuration issues.

Unique Sender IPs

Monitor for sudden increases that may indicate unauthorized sending.

Email Volume

Track total volume over time. Sharp drops may indicate delivery issues.

Policy Compliance

Ensure receivers are honoring your DMARC policy correctly.

Next Steps

Set up automated report collection (use TrustYourInbox or similar platform)
Establish baseline pass rate and identify all legitimate senders
Configure missing SPF/DKIM for any legitimate failures
Move to progressive enforcement once 95%+ pass rate achieved
Implement ongoing monitoring and alerting for new issues

DMARC Reports: A Practical Guide

Table of Contents