title: “How to Read DMARC Reports (Without Losing Your Mind)”
slug: “how-to-read-dmarc-reports-guide”
url: “/how-to-read-dmarc-reports-guide”
date: “2026-04-09”
author: “Mike Walton”
keywords:
– “how to read DMARC reports”
– “DMARC aggregate report”
– “DMARC XML report”
– “RUA report explained”
– “DMARC report analysis”
tags:
– “Email Security”
– “DMARC”
– “Email Authentication”
– “Troubleshooting”
status: “draft”
How to Read DMARC Reports (Without Losing Your Mind)
By Mike Walton, Founder of CertMS
*After 20+ years in IT infrastructure and PKI management, I’ve watched countless administrators set up DMARC, see XML attachments flood their inbox, and quietly ignore them forever. Those reports contain critical security intelligence. Let’s make them actually readable.*
You did everything right. You set up DMARC, configured SPF, deployed DKIM. Now Gmail and Yahoo are sending you daily emails with .xml.gz attachments. You opened one once, saw a wall of angle brackets, and closed it immediately.
You’re not alone. Those XML files are intentionally formatted for machines, not humans. But buried in that syntax is everything you need to know about who’s sending email as your domain – and whether they should be.
Here’s how to actually understand what those reports are telling you.
Why DMARC Reports Matter
Before we dive into the technical details, let’s be clear about what’s at stake.
According to DMARCReport’s 2025 data, organizations that actively monitor their DMARC reports can move from p=none to p=reject in a median of 41 days. Those who ignore reports? They stay stuck in monitoring mode indefinitely, getting zero protection from spoofing attacks.
DMARC reports tell you:
- Which IP addresses are sending email using your domain
- Whether those emails pass SPF and DKIM authentication
- Whether authentication aligns with your visible From address
- What receiving servers did with each message (delivered, quarantined, rejected)
Without this visibility, you’re flying blind. You might block legitimate emails from a forgotten third-party service. Or worse, you might not notice that attackers are actively spoofing your domain.
The Two Types of DMARC Reports
When you publish a DMARC record with reporting enabled, you’ll receive two types of reports – though in practice, you’ll mostly work with one.
Aggregate Reports (RUA)
These are your daily summary reports. Every email provider that receives mail claiming to be from your domain sends you a statistical overview: how many messages came from each IP address, whether they passed authentication, and what happened to them.
As PowerDMARC explains, aggregate reports provide everything you need for ongoing monitoring – which IPs are sending as your domain, authentication pass/fail rates, and receiving server actions.
You configure aggregate report delivery with the rua= tag in your DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Forensic Reports (RUF)
Forensic reports provide message-level details about individual authentication failures. Instead of statistics, you get actual email samples – headers, subject lines, sometimes body content.
Here’s the catch: most major providers don’t send forensic reports anymore. Google, Yahoo, and others stopped due to privacy regulations like GDPR. The email samples could contain sensitive recipient information.
If you’re expecting detailed failure data from forensic reports, you’ll likely be disappointed. Focus your energy on aggregate reports – they’re what you’ll actually receive.
Anatomy of an Aggregate Report
Let’s break down what you’re actually looking at when you unzip that .xml.gz file.
Every aggregate report has three main sections:
1. Report Metadata
This tells you who generated the report and what time period it covers.
xml
name>google.comname>
noreply-dmarc-support@google.com
id>12345678901234567890id>
1712620800
1712707199
The orgname tells you which email provider sent this report (Google, Yahoo, Microsoft, etc.). The daterange uses Unix timestamps – you’ll typically see 24-hour windows.
2. Policy Published
This section shows the DMARC policy that the receiving server saw when it checked your domain.
xml
yourdomain.com
r
r
quarantine
quarantine
100
The key tags here:
According to DMARCPal, most configurations use relaxed alignment because it’s more forgiving of legitimate mail setups while still providing security.
3. Record (The Important Part)
This is where the actual data lives. Each
xml
ip>192.0.2.1ip>
1523
none
pass
pass
|
from>yourdomain.comfrom>
yourdomain.com
pass
google
yourdomain.com
pass
Let me translate what matters here:
Reading Reports: What to Look For
Now that you understand the structure, let’s talk about what actually matters.
Healthy Traffic Patterns
When you see a record like this:
Source IP: 209.85.220.41 (Google)
Count: 5,000
DKIM: pass
SPF: pass
Disposition: none
That’s exactly what you want. A known sending source (Google’s mail servers), passing both authentication methods, with emails being delivered normally.
Warning Signs
Here’s what should grab your attention:
High volume from an unknown IP with authentication failures:
Source IP: 203.0.113.50
Count: 2,400
DKIM: fail
SPF: fail
Disposition: none (because you're on p=none)
This is either someone spoofing your domain, or a legitimate service you forgot to configure. Either way, it needs investigation.
SPF/DKIM pass but DMARC still fails:
This trips up a lot of people. You might see SPF show “pass” in authresults, but “fail” in policyevaluated. Why?
According to MXToolbox, DMARC requires alignment – the authenticated domain must match your visible From address. A third-party service might pass SPF using their own domain, but since that doesn’t align with your From address, DMARC fails.
Legitimate services failing authentication:
When you see failures from IPs belonging to services you actually use (like Mailchimp, SendGrid, or your CRM), that’s a configuration problem. Either:
Identifying Unknown Senders
Raw IP addresses don’t tell you much. Here’s how to figure out who’s actually sending.
Reverse DNS Lookup
Most legitimate email services have PTR records that identify their infrastructure:
192.0.2.1 → mail-yw1-f41.google.com (Google)
192.0.2.2 → mta.sendgrid.net (SendGrid)
192.0.2.3 → bounce.linkedin.com (LinkedIn)
IP Ownership Lookup
Use WHOIS or a tool like MXToolbox to identify who owns the IP range. Major cloud providers (AWS, Azure, Google Cloud) and email services have recognizable IP allocations.
Cross-Reference Your Vendor List
According to AutoSPF, many authentication failures come from “organizations adopting new email services, switching hosting providers, or starting using third-party tools without updating their SPF records.”
Keep a list of every service that sends email on your behalf:
When you see an unknown IP, check it against this list. A “mystery” sender is often just a tool someone on your team started using without telling IT.
Common Scenarios and What They Mean
Let me walk through real patterns you’ll see in your reports.
Scenario 1: Everything Passes
Total messages: 10,000
DKIM pass + aligned: 9,850
SPF pass + aligned: 9,800
DMARC pass: 9,900
Congratulations. Your authentication is working. The small number of failures might be legitimate edge cases (forwarded emails, mailing lists) or minor spoofing attempts that your eventual p=reject policy will block.
Scenario 2: High Volume Failures from One Source
Source: 198.51.100.25
Count: 3,500
DKIM: fail
SPF: fail
Either active spoofing or a seriously misconfigured service. Investigate the IP immediately. If it’s a vendor, fix the configuration. If it’s unknown, this is exactly what DMARC enforcement will protect you from.
Scenario 3: SPF Pass, DKIM Fail, DMARC Pass
SPF: pass (aligned)
DKIM: fail
DMARC: pass
DMARC only needs one authentication method to pass with alignment. This pattern often indicates a service that’s properly listed in your SPF but doesn’t have DKIM configured. It works, but adding DKIM would provide better security – especially for forwarded emails where SPF breaks.
Scenario 4: Both Pass, DMARC Fails
SPF: pass (not aligned)
DKIM: pass (not aligned)
DMARC: fail
Classic third-party alignment problem. The service is authenticated, but using their domain instead of yours. For example, a marketing platform might send with SPF passing for their infrastructure and DKIM signing with their domain, but your recipients see your domain in the From address.
As DMARC Report explains, you need to configure these services to either:
Most enterprise email services support both options.
The Volume Problem
Here’s the practical challenge: if you’re a medium-sized organization, you might receive 50+ aggregate reports daily. Each one is a separate XML file from a different email provider. Manually parsing them is tedious at best, impossible at scale.
According to DMARCPal: “The raw XML is verbose, and it’s normal to bounce off it the first time. That’s not you being ‘bad at DMARC.’ Aggregate reports are intentionally formatted for machines, not humans.”
Options for handling volume:
Manual parsing: Works for very small domains with minimal email traffic. Not sustainable otherwise.
Spreadsheet tracking: You can write scripts to extract data into spreadsheets. Better than nothing, but requires ongoing maintenance.
Dedicated monitoring tools: This is what most organizations end up needing. Platforms like MonitorDMARC accept your RUA reports, parse the XML automatically, and present the data in dashboards organized by domain, source, and authentication status.
The advantage of automation isn’t just convenience – it’s consistency. You’ll catch anomalies that would get lost in a flood of XML files.
From Reports to Action
Reading reports is only useful if you act on what they tell you. Here’s a practical workflow:
Week 1-2: Baseline Assessment
Week 3-4: Fix Configuration Issues
Week 5-8: Monitor for Stability
Week 9+: Move Toward Enforcement
According to DuoCircle’s guidance, once you hit 98%+ alignment with no legitimate sources failing, you’re ready to start enforcing:
DMARCReport’s 2025 data shows the median time from p=none to p=reject is 41 days when organizations actively monitor their reports. Without monitoring, many never make it to enforcement at all.
Monitoring Beyond Reports
DMARC reports show you authentication results, but they don’t catch everything. Your DNS records themselves can change – accidentally or maliciously.
MonitorDMARC addresses this by monitoring your SPF, DKIM, DMARC, and BIMI records for changes. If someone modifies your DNS configuration, you’ll know immediately – not after emails start bouncing.
This matters because:
The Compliance Angle
Since February 2024, Google and Yahoo require DMARC for bulk senders. As of 2026, non-compliant emails from high-volume senders face outright rejection.
Microsoft joined with similar requirements in May 2025, bouncing non-compliant bulk mail with error code 550 5.7.515.
Your DMARC reports are your evidence of compliance. They prove:
If deliverability problems ever arise, these reports are your first troubleshooting resource.
Quick Reference: Report Field Cheat Sheet
Keep this handy when reviewing reports:
| Field | Location | What It Means |
|——-|———-|—————|
| source_ip | row | IP address that sent the emails |
| count | row | Number of emails from this source |
| disposition | policy_evaluated | What happened (none/quarantine/reject) |
| dkim | policy_evaluated | Did DKIM pass AND align? |
| spf | policy_evaluated | Did SPF pass AND align? |
| header_from | identifiers | The domain recipients see |
| result | auth_results/dkim | Raw DKIM result (before alignment) |
| result | auth_results/spf | Raw SPF result (before alignment) |
| selector | auth_results/dkim | Which DKIM key was used |
Wrapping Up
DMARC reports aren’t optional reading. They’re the visibility layer that makes email authentication actually work. Without them, you’re guessing about whether your configuration is correct and whether anyone’s spoofing your domain.
The XML format makes them hard to read manually. That’s by design – they’re meant to be processed by tools, not humans staring at angle brackets.
Your options are:
MonitorDMARC transforms those XML files into actionable dashboards, alerts you to authentication failures, and monitors your DNS records for changes. Start with a free 14-day trial – no credit card required – and finally see what those reports have been trying to tell you.
Because the data you need to protect your domain is already arriving in your inbox. It’s just waiting to be read.
*Mike Walton is the founder of CertMS, a certificate management platform. He has 20+ years of experience in IT infrastructure and PKI management.*
Word Count: 2,847