How to Read DMARC XML Reports (With Examples)

DMARC XML reports can look intimidating if you've never seen one before. These aggregate reports arrive as email attachments in compressed XML format, and they contain critical data about who is sending email on behalf of your domain. This guide breaks down every section of a DMARC report with real-world examples so you can understand exactly what they're telling you.

Why You Receive DMARC Reports

When you publish a DMARC record with a rua tag (like rua=mailto:dmarc@yourdomain.com), you're telling email providers: "Send me reports about emails claiming to be from my domain."

These aggregate reports (RUA) are sent daily by providers like Google, Yahoo, Microsoft, and others. Each report covers a 24-hour window and summarizes:

• Every IP address that sent email using your domain
• How many messages each IP sent
• Whether those messages passed or failed SPF, DKIM, and DMARC
• What policy was applied to failing messages

This data is essential for understanding your email ecosystem before tightening your DMARC policy. Check your current DMARC setup with our DMARC Checker.

Anatomy of a DMARC XML Report

Let's walk through a real-world example report, section by section.

The Full Report Structure

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>...</report_metadata>
  <policy_published>...</policy_published>
  <record>...</record>
  <record>...</record>
</feedback>

Every DMARC report has three main sections:

1. <report_metadata> — Who generated the report and when
2. <policy_published> — Your DMARC policy as seen by the reporter
3. <record> — One or more records, each representing a sending IP

Section 1: Report Metadata

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>17238456789012345678</report_id>
  <date_range>
    <begin>1709251200</begin>
    <end>1709337600</end>
  </date_range>
</report_metadata>

Field	Meaning
org_name	The email provider that generated the report (Google, Yahoo, Microsoft, etc.)
email	Contact email for the reporting organization
report_id	Unique identifier for this report
date_range	Unix timestamps for the period covered (usually 24 hours)

The date_range timestamps tell you exactly which day this report covers. In this example, it covers March 1, 2024 00:00 UTC to March 2, 2024 00:00 UTC.

Section 2: Policy Published

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

This section reflects your DMARC policy as the reporting provider saw it:

Field	Meaning
domain	Your domain
adkim	DKIM alignment mode: r = relaxed, s = strict
aspf	SPF alignment mode: r = relaxed, s = strict
p	Your DMARC policy: none, quarantine, or reject
sp	Subdomain policy (inherits from p if not set)
pct	Percentage of messages the policy applies to

If something looks wrong here (like p=none when you've already set p=reject), it might mean your DNS record hasn't propagated yet or there's a caching issue. Verify your live record with the DMARC Checker.

Section 3: Records (The Important Part)

Each <record> block represents a group of emails from a specific source IP:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1524</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>google</selector>
    </dkim>
    <spf>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

This is where the actionable data lives. Let's break it down:

The <row> section:

Field	Meaning
source_ip	The IP address that sent these emails
count	How many messages this IP sent during the reporting period
disposition	What the provider did: none (delivered), quarantine (spam), reject (blocked)
dkim	DMARC evaluation of DKIM: pass or fail
spf	DMARC evaluation of SPF: pass or fail

The <auth_results> section:

Field	Meaning
dkim > domain	The domain that signed the email with DKIM
dkim > result	Raw DKIM check result (pass, fail, none)
dkim > selector	Which DKIM selector was used
spf > domain	The domain checked for SPF (envelope sender)
spf > result	Raw SPF check result (pass, fail, softfail, none)

How to Identify Legitimate Senders vs Unauthorized

When analyzing records, look at each source_ip and ask: "Do I recognize this sender?"

Legitimate senders you'll commonly see

IP Range	Service
209.85.x.x	Google Workspace
40.92–40.107.x.x	Microsoft 365
198.2.x.x / 198.21.x.x	Mailchimp
168.245.x.x	SendGrid
69.171.x.x	Facebook notifications

Red flags for unauthorized senders

• Unknown IPs sending high volumes with dkim=fail and spf=fail
• IPs from unexpected countries or hosting providers
• Records where header_from is your domain but auth_results show a completely different domain
• High count values from IPs you don't recognize

How to Spot Common Problems

Problem 1: SPF Passes but DKIM Fails

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>pass</spf>
</policy_evaluated>

This usually means the sending service is authorized in your SPF record but hasn't been configured with DKIM signing for your domain. Check your DKIM configuration with the DKIM Checker.

Problem 2: Forwarding Failures

<auth_results>
  <spf>
    <domain>forwarder-domain.com</domain>
    <result>pass</result>
  </spf>
</auth_results>
<policy_evaluated>
  <spf>fail</spf>
</policy_evaluated>

When SPF passes in auth_results but fails in policy_evaluated, it's an alignment failure. This happens frequently with email forwarding — the forwarding server's IP isn't in your SPF record, and the envelope sender domain doesn't match your header_from.

DKIM survives forwarding, so having DKIM properly configured protects against this. Check your full setup with the Email Compliance Checker.

Problem 3: Legitimate Service Failing Both Checks

<source_ip>168.245.100.52</source_ip>
<count>340</count>
<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>

If you recognize the IP (in this case, SendGrid) but both checks fail, the service needs to be configured properly:

1. Add the service to your SPF record → SPF Generator
2. Set up DKIM signing in the service's dashboard → DKIM Setup Guide
3. Verify alignment is correct → DMARC Checker

Why Reading Reports Manually Doesn't Scale

A single domain can receive dozens of reports per day from different providers. Each report can contain hundreds of records. Multiply that by the number of domains you manage, and manual review becomes impossible.

Common challenges with manual report analysis:

• Reports arrive as gzip-compressed XML attachments that need to be extracted and opened
• IP addresses need to be reverse-resolved to identify the sending service
• You need to track trends over time to spot new unauthorized senders
• Different providers use slightly different report formats
• There's no built-in way to aggregate data across multiple reports

Automate Report Analysis with DMARC Examiner

DMARC Examiner solves all of these problems by automatically processing your DMARC reports. It parses the XML, identifies sending services by IP, visualizes trends, and alerts you when unauthorized senders appear or authentication failures spike.

Instead of reading XML files, you get a clear dashboard showing exactly what's happening with your email authentication — and actionable recommendations to fix problems.

Start monitoring for free →

---

Related Articles:

• What is DMARC? A Simple Guide for Non-Technical People
• Understanding SPF, DKIM, and DMARC
• DMARC Policy Explained: None, Quarantine, and Reject