If you’ve ever opened a DMARC report and seen a wall of XML, you’re not alone. Most domain owners receive these reports daily. However, very few know how to read them or what to fix.
A DMARC report shows which systems are sending email as your domain, whether those messages passed SPF and DKIM authentication, and how receiving servers handled them. It’s your primary tool for detecting misconfigured senders, improving deliverability, and stopping email spoofing.
In this guide, I’ll walk through a real DMARC report field by field. You’ll learn how to identify legitimate senders, spot authentication failures, and take action to protect your domain
What is a DMARC report?
A DMARC report is feedback that receiving mailbox providers send back to you about emails claiming to come from your domain. Providers like Google and Yahoo generate these reports and send them to the address in your DMARC record.
You receive reports because your DNS DMARC record requests them.. The rua tag in that record is an email address where aggregate reports are delivered. No record, no reports.
Each report answers three questions:
- Which servers sent email using your domain?
- Did those messages pass SPF and DKIM?
- What did the receiver do with them (deliver, quarantine, reject)?
What’s the difference between aggregate (RUA) and forensic (RUF) reports?
Aggregate reports (RUA) are daily XML summaries of all email seen from your domain. Forensic reports (RUF) are detailed, per-message reports sent when a message fails.
You’ll work almost entirely with aggregate reports. They’re the standard, and nearly every provider sends them. Forensic reports are rare now, since most providers limit them for privacy reasons.
So when people say “read a DMARC report,” they almost always mean the aggregate XML. That’s our focus here.
Why are DMARC reports written in XML?
DMARC reports use XML so machines can parse and aggregate them at scale. The format is built for software, not for human eyes, which is why raw reports feel clunky to read.
That tradeoff matters. You can read a single report by hand to learn the structure. But once you receive dozens a day, a parser or dashboard becomes the practical choice. We’ll cover tools later.
How do you read a DMARC aggregate report?
You can read an aggregate report from top to bottom in four parts: metadata, published policy, record rows, and authentication results. Each part has a clear job. Let’s walk through a real one.
Prerequisites
Before a report makes sense, you need three things in place:
- A DMARC record published in your DNS with an
ruaaddress - At least one full day of sending, so receivers have data to report
- Basic familiarity with SPF and DKIM. Our guide on how SPF, DKIM, and DMARC work covers the basics.
Here’s a complete aggregate report we’ll reference section by section:
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>14829471028401</report_id>
<date_range>
<begin>1717200000</begin>
<end>1717286400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</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>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
The report metadata (who sent it and when)
The report_metadata block tells you who generated the report and the time period it covers. It’s the report’s cover page.
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>14829471028401</report_id>
<date_range>
<begin>1717200000</begin>
<end>1717286400</end>
</date_range>
</report_metadata>
Here’s what each field means:
org_name: the provider that sent the report (here, Google)email: the provider’s contact addressreport_id: a unique ID for this reportdate_range: the start and end of the reporting window, as Unix timestamps
These timestamps are in Unix epoch seconds. 1717200000 converts to June 1, 2026. Most parsers convert this for you.
The published policy
The policy_published block shows the DMARC policy the receiver saw in your DNS at report time. It confirms what rules you’re actually enforcing.
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
Each tag controls part of your policy:
p: your policy for the main domain (none,quarantine, orreject)sp: the policy for subdomainsadkim/aspf: alignment mode, relaxed (r) or strict (s)pct: the percentage of mail the policy applies to
A p of none means you’re only monitoring. The receiver is not taking any action on failures yet. That’s the right place to start, and most domains still sit on monitoring, but the goal is to move toward reject.
The record rows (source IP, volume, disposition)
Each record describes one sending source and what happened to its mail. This is the heart of the report.
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
Read the row like this:
source_ip: the server that sent the mailcount: how many messages came from that IP in the windowdisposition: what the receiver actually did (none,quarantine,reject)dkim/spf: the DMARC-aligned result for each check
Important: The disposition is what the receiver did, not what your policy asked for. A receiver can deliver a failing message while you’re on p=none. As you tighten your policy, the disposition starts to match it.
The authentication results (SPF and DKIM alignment)
The auth_results block shows the raw SPF and DKIM checks behind the row’s verdict. This is where you diagnose why something passed or failed.
<auth_results>
<dkim>
<domain>example.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
DMARC passes when at least one of SPF or DKIM passes and is aligned. Alignment means the authenticated domain matches the domain in the visible From address.
So a message can pass SPF at the server level but still fail DMARC if the SPF domain doesn’t align with your From domain. The auth_results domain is what you check against your sending domain.
What should you look for in a DMARC report?
Look first for legitimate senders that are failing, because those are your deliverability risks. Then look for unknown sources, which can signal spoofing. Work through this order:
- Your own services failing alignment: A marketing tool or CRM sending as your domain without an aligned SPF/DKIM. Fix these first.
- Unknown IPs that pass: Confirm they’re really yours before trusting them.
- Unknown IPs that fail: Often spoofing attempts that can hurt your sender reputation. Your policy is what stops them.
- Overall pass rate: Track the percentage of aligned mail over time. It should climb as you fix sources.
Pro Tip: Don’t jump straight to p=reject. Start at none, fix every legitimate source until it aligns. After that, move to quarantine, then reject. Rushing the policy blocks your own mail.
What tools make DMARC reports easier to read?
DMARC analyzers parse the XML and show it as charts and tables, so you don’t read raw files. They group sources, flag failures, and track trends over time.
Popular options include:
- MXToolbox DMARC Report Analyzer: Paste or forward a report for a quick read
- EasyDMARC, Valimail, and Postmark’s DMARC tool: Ongoing dashboards with source grouping
- Dmarcian and Dmarcreport: Monitoring with alerts and historical trends
For one-off checks, reading the XML by hand is fine. Once reports arrive daily, route your rua address to a parser. It saves hours and surfaces trends a single report can’t show.
How do you fix the problems a DMARC report reveals?
You can fix DMARC-related problems by aligning each legitimate sender, then tightening your policy. The report points to the exact source, so you can target the fix.
Common fixes by symptom:
- A real sender fails SPF: add its sending IP or include it in your SPF record. If your SPF is hitting the lookup limit, see SPF flattening.
- A real sender fails DKIM: enable DKIM signing for that service and publish its public key.
- Mail fails alignment only: match the authenticated domain to your From domain, or send from a dedicated subdomain.
- Spoofing from unknown IPs: keep tightening toward
p=rejectso receivers block it.
Note: Using a transactional email provider handles SPF and DKIM alignment for you. Your reports then show clean passes from that source, which makes the whole report easier to read.
FAQs – Reading a DMARC report
These are answers to some of the most common questions we see about reading DMARC reports.
What does a DMARC report tell you?
A DMARC report tells you every source sending email as your domain and whether each passed SPF and DKIM with alignment. It also shows what the receiver did with the mail, so you can spot both deliverability issues and spoofing.
Where do DMARC reports come from?
Receiving mailbox providers like Google, Yahoo, and Microsoft generate them. They send the reports to the rua address in your DMARC DNS record. If you haven’t set an rua address, then you won’t get any reports.
What’s the difference between RUA and RUF reports?
RUA reports are aggregate daily summaries in XML, and they’re what you’ll use most. RUF (forensic) reports are per-message failure samples, but most providers no longer send them due to privacy concerns.
How often do DMARC reports arrive?
Most providers send aggregate reports once every 24 hours. You’ll receive a separate report from each provider that handled your mail, so several reports a day are normal.
Do I need a tool to read DMARC reports?
No, you can read a single report by hand once you know the structure. But once reports arrive daily from multiple providers, a DMARC analyzer saves time and reveals trends a single file can’t.
That’s it! Now you know how to read a DMARC report.
Reading a DMARC report comes down to four parts: who reported it, your published policy, the per-source rows, and the authentication results. Once you can read those, you can find every sender that needs fixing.
Next, would you like to learn how email authentication works? Check out our SPF, DKIM, and DMARC guide for more information.