How to Read and Interpret DMARC Reports

What Are DMARC Reports

DMARC reports are automated messages that receiving mail servers (Gmail, Outlook, Yahoo, and others) send to domain owners. They contain data about who is sending emails from your domain and whether those emails pass SPF and DKIM authentication.

You receive reports at the address specified in the rua= tag of your DMARC record. If you don't have a DMARC record yet, start with How to Set Up DMARC.

There are two types of reports:

• Aggregate reports (RUA) — daily XML summaries sent by most major providers. They contain statistics, not email content.
• Forensic reports (RUF) — detailed reports about individual failures. In practice, very few providers send them (Gmail and Outlook don't) due to recipient privacy concerns.

This article focuses on aggregate reports — the primary source of information for managing email authentication.

What an Aggregate Report Looks Like

Aggregate reports arrive as compressed XML files (.xml.gz or .zip). The filename identifies the sender, your domain, and the time period:

google.com!example.com!1713744000!1713830400.xml.gz

Once extracted, you'll find an XML document with three main sections:

Report Metadata

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>12345678901234567890</report_id>
  <date_range>
    <begin>1713744000</begin>
    <end>1713830400</end>
  </date_range>
</report_metadata>

Identifies the report sender and the time period covered (Unix timestamps). In this example, the report covers 24 hours from google.com.

Published Policy

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

The DMARC policy the receiving server found on your domain:

Records

The core of the report. Each <record> groups emails from the same source IP with the same authentication outcome:

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

This is the most important part. Let's break down each element.

How to Read Individual Records

source_ip and count

The IP address of the server that sent the emails and the message count for the reporting period. A reverse DNS lookup (via DNS lookup) reveals who owns the IP. Address 209.85.220.41 belongs to Google — a legitimate sender if you use Google Workspace.

policy_evaluated

What the receiving server did with the emails:

Important — dkim and spf in policy_evaluated reflect alignment, not just authentication alone. An email can pass SPF (the server is in the SPF record) but fail alignment (the envelope sender domain doesn't match the From header domain).

auth_results

Raw authentication results without alignment consideration:

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

By comparing auth_results with policy_evaluated, you can determine whether the issue is with authentication itself or with alignment. If auth_results shows pass but policy_evaluated shows fail, you have an alignment problem — the SPF/DKIM domain doesn't match the From header domain.

Common Report Scenarios

Legitimate Sender — All Clear

<row>
  <source_ip>209.85.220.41</source_ip>
  <count>842</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</row>

Both DKIM and SPF passed including alignment. Emails are delivered. This is the target state for every legitimate sender.

Legitimate Sender — Missing Configuration

<row>
  <source_ip>198.2.135.10</source_ip>
  <count>47</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<auth_results>
  <spf>
    <domain>sendgrid.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

SPF passed for sendgrid.net, but alignment failed — the email claims to be from example.com, but SPF verified sendgrid.net. Fix: configure SendGrid for DKIM signing with your domain and add include:sendgrid.net to your SPF record.

Spoofing — Forged Email

<row>
  <source_ip>45.33.18.92</source_ip>
  <count>3</count>
  <policy_evaluated>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<auth_results>
  <spf>
    <domain>unknown-domain.ru</domain>
    <result>pass</result>
  </spf>
</auth_results>

Unknown IP, both checks failed, foreign domain in SPF. This is spoofing — someone is attempting to send emails on behalf of your domain. With a p=reject policy, these emails are rejected.

Forwarding — Legitimate Failure

<row>
  <source_ip>72.14.199.25</source_ip>
  <count>12</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

SPF failed (the forwarding server isn't in your SPF record), but DKIM passed — signatures remain valid after forwarding. DMARC requires at least one mechanism to succeed, so the email passed. This is common with forwarded emails and doesn't require action if you have working DKIM.

Report Analysis Workflow

When evaluating reports, follow a systematic approach:

1. Identify all source IP addresses — use reverse DNS or DNS lookup to determine ownership. Cross-reference with the services you use for sending emails.

2. Check disposition — if you see quarantine or reject for a legitimate sender, you have a configuration issue that needs urgent attention.

3. Distinguish authentication from alignment — compare auth_results with policy_evaluated. If authentication passed but DMARC failed, fix alignment (usually by configuring DKIM signing with your domain for third-party services).

4. Ignore spoofing (with enforcement policy) — records showing disposition: reject from unknown IPs prove that DMARC is working. With p=reject, forged emails are blocked.

5. Monitor trends — a single report isn't enough. Track changes over time: are new failures appearing? Have new source IPs emerged?

Why You Shouldn't Read Reports Manually

Raw XML aggregate reports are hard to parse. A domain with active email traffic can receive dozens of reports daily from different providers. Manual XML parsing is:

• Time-consuming — extracting, reading XML, searching for issues across thousands of records
• Error-prone — it's easy to miss a problematic record
• Lacking context — a single report shows only a snapshot; you need an aggregated view across time and providers

SPF Monitor automatically processes, visualizes, and alerts you to issues in your reports. Point your rua= address to example.com@rua.spfmonitor.com and data collection begins. No need to deal with XML, compressed files, or manual aggregation.

Forensic Reports (RUF)

Forensic reports contain details about individual emails that failed DMARC verification — including headers and sometimes parts of the message body. They're configured with the ruf= tag in your DMARC record:

v=DMARC1; p=reject; rua=mailto:example.com@rua.spfmonitor.com; ruf=mailto:example.com@ruf.spfmonitor.com; fo=1

The fo= (failure options) tag determines when a forensic report is sent:

The practical value of RUF reports is limited — most major providers (Gmail, Microsoft, Yahoo) don't send them due to recipient privacy concerns. When you do receive them, they're useful for diagnosing specific failures quickly.

Checklist

After setting up DMARC reporting, verify:

• Your DMARC record contains a rua= tag with a valid address
• First reports arrive within 24–72 hours
• You've identified all legitimate senders in the reports
• Legitimate senders show dkim: pass and spf: pass in policy_evaluated
• Third-party senders have DKIM configured for your domain
• Failed records from unknown IPs are spoofing (verify with reverse DNS)
• Only tighten the policy to quarantine and then reject after resolving all legitimate failures

Check your DMARC record and verify that reporting is properly configured.