Understanding DMARC Reports

Aggregate Reports (rua)

Aggregate Reports are XML files sent by receiving mail servers (Google, Microsoft, Yahoo, etc.) to the addresses specified in your DMARC record's rua tag. They contain:

• The reporting organization's identity
• The time period covered (usually 24 hours)
• Your published DMARC policy
• Per-source-IP statistics: how many emails were sent, and whether they passed or failed SPF, DKIM, and DMARC

Reports are typically sent as gzipped XML files (.xml.gz) or ZIP archives (.zip) attached to emails.

Forensic Reports (ruf)

Forensic Reports (also called "failure reports") provide details about individual emails that failed DMARC. They include headers, and sometimes message content, of failing emails. However:

• Many large receivers (Google, Microsoft) do not send Forensic Reports due to privacy concerns
• When sent, they may be redacted or limited
• They are most useful for debugging specific authentication failures

Focus on Aggregate Reports — they provide the visibility needed for 99% of DMARC management tasks.

Understanding the XML structure is essential for interpreting your reports. Here's a complete annotated example:

<feedback>
  <!-- WHO sent this report -->
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16234567890123456789</report_id>
    <date_range>
      <begin>1709164800</begin>  <!-- Unix timestamp: 2024-02-28 00:00 UTC -->
      <end>1709251200</end>      <!-- Unix timestamp: 2024-02-29 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- YOUR published DMARC policy at the time -->
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>    <!-- DKIM Alignment: relaxed -->
    <aspf>r</aspf>      <!-- SPF Alignment: relaxed -->
    <p>quarantine</p>   <!-- Policy: quarantine failing emails -->
    <sp>none</sp>       <!-- Subdomain policy: monitor only -->
    <pct>100</pct>      <!-- Apply to 100% of failing emails -->
  </policy_published>

  <!-- INDIVIDUAL RECORDS — one per source IP + result combination -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>  <!-- The IP that sent these emails -->
      <count>1542</count>                    <!-- Number of emails from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>       <!-- What the receiver DID -->
        <dkim>pass</dkim>                    <!-- DMARC DKIM evaluation -->
        <spf>pass</spf>                      <!-- DMARC SPF evaluation -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>  <!-- The From: header domain -->
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>  <!-- Domain that signed -->
        <result>pass</result>
        <selector>google</selector>   <!-- Which DKIM key was used -->
      </dkim>
      <spf>
        <domain>example.com</domain>  <!-- Domain in Return-Path -->
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The <source_ip> field in each record tells you which server sent emails claiming to be from your domain. This is the most actionable data in DMARC reports.

How to Analyze Source IPs

1. Identify the IP: Use reverse DNS (PTR), WHOIS, or IP geolocation to determine who owns the IP.
2. Categorize the sender:
   • Your own servers: IPs from your organization's network
   • Authorized third parties: Google, Microsoft, SendGrid, Mailchimp, etc.
   • Forwarding services: Mailing lists, forwarding rules, security gateways
   • Unknown/suspicious: Potentially spoofed emails — investigate further
3. Check the count: High volume from an unauthorized IP indicates active abuse.
4. Check disposition: none means the email was delivered; quarantine means it went to spam; reject means it was blocked.

Common Source IP Ranges

Reports contain two sets of results that are often confused:

<policy_evaluated>

This is the DMARC verdict. It tells you whether DMARC passed or failed, considering Alignment:

• dkim=pass means DKIM passed AND the DKIM domain aligned with the From: domain
• spf=pass means SPF passed AND the SPF domain aligned with the From: domain
• disposition tells you what the receiver actually did with the email

<auth_results>

This is the raw authentication result, regardless of Alignment:

• SPF result for the actual Return-Path domain (may be different from From: domain)
• DKIM result for each signature found (may include third-party signatures)
• The domain and selector fields show exactly which key was used

Example: SPF Passes but DMARC Fails

<!-- Email: From: ceo@example.com, Return-Path: bounce@sendgrid.net -->
<policy_evaluated>
  <dkim>fail</dkim>  <!-- No aligned DKIM signature -->
  <spf>fail</spf>   <!-- SPF domain (sendgrid.net) ≠ From domain (example.com) -->
</policy_evaluated>
<auth_results>
  <spf>
    <domain>sendgrid.net</domain>  <!-- SPF passed for sendgrid.net... -->
    <result>pass</result>           <!-- ...but it's not aligned with example.com -->
  </spf>
</auth_results>

Fix: Configure SendGrid to use a custom Return-Path like bounce.example.com and set up DKIM signing with d=example.com.