Reading and Understanding DMARC Reports (RUA)

You’ve configured DMARC with a rua= tag and reports are starting to arrive. But what do you do with these often incomprehensible XML files? This guide teaches you how to read them, interpret them, and take concrete action.

What Is a DMARC RUA Report

An RUA (Report URI Aggregate) report is an XML file sent daily by mailbox providers (Google, Microsoft, Yahoo, etc.) to the address defined in your DMARC record.

It summarizes all sending attempts observed for your domain over the last 24 hours: who sent, from which IP, what SPF/DKIM/DMARC result.

What a Report Contains

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1717200000</begin>
      <end>1717286400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.42</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>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Key Fields to Analyze

`<source_ip>`: Who’s Sending

The IP address of the server that sent the emails. This is the first clue to identify the source:

Known IP (your ESP, your server) → legitimate source
Unknown IP → potential shadow IT or spoofing

Use an IP lookup service (whois, rDNS) to identify the owner.

`<count>`: The Volume

The number of emails sent from this IP during the report period. High volume from an unknown IP is a red flag.

`<disposition>`: What Happened

The action applied by the provider:

Value	Meaning
`none`	No action (most common when `p=none`)
`quarantine`	Message sent to spam
`reject`	Message rejected

`<dkim>` and `<spf>` in `<policy_evaluated>`

The DMARC result (with alignment):

pass: authentication succeeded and the domain is aligned
fail: either authentication failed, or alignment isn’t met

`<auth_results>`: Raw Results

SPF and DKIM results before DMARC alignment checking. An spf=pass here with spf=fail in policy_evaluated means SPF passed but the Return-Path domain doesn’t align with the From:.

Common Report Scenarios

Everything Passes: Properly Configured Legitimate Source

source_ip: 198.51.100.42 (your ESP)
dkim: pass, spf: pass, disposition: none

Nothing to do, everything is in order.

SPF Pass but DKIM Fail: Signature Problem

source_ip: 198.51.100.42 (your ESP)
dkim: fail, spf: pass, disposition: none

Your ESP sends on your behalf but the DKIM signature isn’t configured or is broken. Enable custom DKIM at your ESP.

Unknown IP, Everything Fails: Spoofing Attempt

source_ip: 203.0.113.99 (unknown)
dkim: fail, spf: fail, disposition: reject

Someone is trying to send emails using your domain. If p=reject, messages are blocked. DMARC is doing its job.

Unknown IP, SPF Passes: Shadow IT

source_ip: 203.0.113.50 (Salesforce, HubSpot, etc.)
dkim: fail, spf: pass, disposition: none

A SaaS service that someone in your organization uses to send emails from your domain. SPF passes because the IP is in your SPF record, but DKIM isn’t configured for this service. This is shadow IT: identify the service and configure DKIM, or remove the SPF authorization if not legitimate.

Automating the Analysis

Reading raw XML is painful. Several approaches:

Sender Audit Dashboard

If you add your domain on Sender Audit , a unique RUA address is generated for your account. Once configured in your DMARC record, reports are:

Automatically parsed
Visualized with charts and tables
Alerts on anomalies
History available in the dashboard

Manually with Open-Source Tools

Tools like parsedmarc (Python) can parse XML files and store them in a database for analysis.

From Reports to Action

The goal of DMARC reports is to guide you toward p=reject. Here’s the workflow:

Inventory all source IPs in reports
Identify each source: own server, ESP, SaaS, spoofing
Fix legitimate sources that fail (missing DKIM, incomplete SPF)
Remove SPF authorizations for non-legitimate sources
Escalate the policy progressively: none → quarantine → reject

For a detailed migration guide, see DMARC: From p=none to p=reject.