DMARC aggregate reports (RUA) are daily XML summaries that mailbox providers send showing every IP that sent mail claiming to be from your domain, and whether each passed SPF, DKIM, and alignment. The trick is to read the XML not as a file but as a table of sending sources and outcomes. Once you can inventory your senders, fix their alignment, and confirm clean results, you can safely move your policy from p=none to p=reject. This is the only reliable path to full DMARC enforcement.
You published a DMARC record, added a reporting address, and now cryptic XML files are arriving in your inbox every day from Google, Microsoft, Yahoo, and others. Most senders glance at one, find it unreadable, and never look again. That is a mistake, because these aggregate reports are the single most powerful tool for understanding who is sending mail as your domain and the only safe way to reach full DMARC enforcement.
This guide teaches you to read DMARC aggregate reports. It covers what the reports contain, how to interpret the XML structure, how to map each sending source, and how to use the data to move from monitoring (p=none) to enforcement (p=reject) without blocking your own legitimate mail. The key mental shift is simple: stop reading the report as a big XML file and start reading it as a table of sending sources and their authentication outcomes.
The Two Types of DMARC Reports
DMARC defines two reporting mechanisms, configured with separate tags in your DMARC record.
Aggregate Reports (RUA)
Aggregate reports are the workhorse and the focus of this guide. Configured with the rua= tag, they are daily XML summaries covering all mail traffic that claimed to use your domain over a 24-hour period. Every DMARC-supporting mailbox provider (Gmail, Microsoft, Yahoo, and others) sends one daily to the address in your rua tag. Crucially, RUA reports contain IP addresses, volumes, and authentication results, but no message content or personally identifiable information, which makes them privacy-safe and the standard tool for monitoring.
Forensic Reports (RUF)
Forensic reports, configured with the ruf= tag, provide per-message failure detail including headers and the specific reason authentication failed. They are useful for investigating individual spoofing attempts, but in practice they are rare and increasingly constrained by receiver privacy choices; many providers do not send them at all. For most senders, RUA reports provide everything needed, and RUF is optional.
How Reports Arrive and What They Look Like
Aggregate reports arrive as email attachments: a ZIP or GZIP file containing an XML document. Each report comes from one reporting organization and covers one 24-hour window. High-volume domains can receive dozens per day from different providers, which is why manual handling does not scale past a single domain.
When you decompress and open the XML, it has three logical sections:
- Report metadata: Who sent the report (the reporting org), the date range, and a report ID.
- Policy published: The DMARC policy the receiver saw for your domain (your p value, alignment modes, and percentage).
- Records: The heart of the report; one row per sending source, showing the source IP, message count, and the SPF, DKIM, and DMARC results.
Reading the XML Field by Field
You do not need to memorize tag names. You need to understand what each row tells you. A single record row in the XML reads, in plain English: "messages from this IP, claiming to be from your domain, evaluated like this for SPF and DKIM, aligned (or did not) with your From domain, and would receive this DMARC disposition."
The fields that matter in each record:
| Field | What It Tells You |
|---|---|
| source_ip | The IP that sent mail claiming to be your domain. This is your starting point for identifying the sender. |
| count | How many messages this IP sent in the reporting window. |
| disposition | What the receiver did: none (delivered), quarantine (spam), or reject (blocked), based on your policy. |
| dkim (result) | Whether DKIM passed for this mail. |
| spf (result) | Whether SPF passed for this mail. |
| dkim (aligned) | Whether the DKIM domain aligned with the From domain. |
| spf (aligned) | Whether the SPF domain aligned with the From domain. |
The distinction between a result passing and a result aligning is the crux of DMARC. SPF or DKIM can pass for some domain, but DMARC only counts it if that domain aligns with the From address your recipients see. A row where SPF passes but does not align contributes nothing to DMARC; the alignment column is the one that determines DMARC pass or fail.
The Table Mindset: Sources and Outcomes
Here is the shift that makes DMARC reports manageable. Do not read the XML top to bottom as a document. Read it as a table where each row is a sending source and the columns are its outcomes. Once you adopt this view, the report becomes an inventory: a list of every server sending as your domain and whether each is authenticating correctly.
With that table in hand, DMARC analysis becomes a three-step operational process:
- Inventory: List every source IP and identify what it is.
- Align: Ensure every legitimate source passes alignment.
- Enforce: Once all legitimate sources align, tighten your policy.
Step One: Inventory and Map Your Sources
For each source IP in your reports, classify it into one of three buckets:
- Authorized and known: Your ESP, your mail server, Google Workspace or Microsoft 365, a CRM, a transactional provider. These are sources you recognize and want to authenticate.
- Unknown but possibly legitimate: A source you do not immediately recognize but which might be a forgotten internal system, a vendor sending on your behalf, or a tool a colleague set up. These need investigation.
- Suspicious: A source with no plausible legitimate reason to send as your domain. These are potential spoofing or phishing attempts, which is exactly what DMARC exists to stop.
Use reverse DNS and IP ownership lookups to identify each source. A reverse DNS checker helps map an IP back to its operator. Many reports can be cross-referenced against known provider IP ranges to quickly classify the major sources. The goal of this step is a complete inventory: every IP accounted for and bucketed.
The forgotten-sender trap: The most common surprise in a first DMARC report review is discovering legitimate systems you forgot were sending as your domain: an old marketing tool, a help desk, an invoicing system, a notification service. If you move to enforcement before finding these, you will block their mail. The inventory step exists specifically to surface every legitimate sender before you enforce.
Step Two: Fix Alignment for Legitimate Sources
For every source you classified as authorized, confirm it passes DMARC alignment, meaning either SPF or DKIM passes and aligns with your From domain. Common alignment problems and their fixes:
- An ESP sends with its own domain in SPF: The mail passes SPF for the ESP domain but does not align with yours. Fix by configuring a custom return-path or relying on aligned DKIM.
- DKIM not configured for a source: The source sends unsigned mail. Fix by enabling DKIM signing with your domain at that provider.
- Subdomain mismatch: Mail sent from a subdomain may need alignment configured for that specific subdomain.
The granular mechanics of strict versus relaxed alignment are worth understanding in depth, but the operational goal here is straightforward: every legitimate source in your inventory must show alignment in the reports before you enforce. Work through them one by one until the reports show clean alignment for all your real senders.
Step Three: Move Safely to p=reject
Once your reports show that every legitimate source passes alignment consistently, you can tighten your policy. Do this in stages, never jumping straight to reject.
- Start at p=none. Monitor only. This is where you do all the inventory and alignment work, with no impact on delivery.
- Move to p=quarantine. Once alignment is clean, set quarantine so unaligned mail goes to spam rather than the inbox. Monitor reports to confirm no legitimate mail is being quarantined.
- Move to p=reject. After a period of clean quarantine results, set reject so unaligned mail is blocked entirely. This is full enforcement: spoofed mail claiming your domain is now rejected outright.
The reports are your safety mechanism at every stage. They tell you, before and after each tightening, whether any legitimate source would be caught. Reaching p=reject without the report data is guesswork that risks blocking your own mail; reaching it with the report data is a controlled, verifiable process.
Reading raw XML works for a single domain with low volume, but it does not scale. High-volume or multi-domain organizations receive dozens of reports daily, and manual parsing becomes impractical fast. Most teams use an automated DMARC analyzer that ingests the XML and presents the data as a dashboard of senders and their alignment status. The reading skills in this guide still matter, because they let you interpret what the dashboard shows and debug the cases the tool flags.
Troubleshooting: Reports Not Arriving
If you published a rua tag but no reports arrive, the usual causes are:
- DNS propagation delay: Reports begin within 24 to 48 hours of publishing the record. Wait before assuming a problem.
- Incorrect rua syntax: The
mailto:prefix is required in the tag. A missing prefix means no reports. - External domain verification missing: If your rua address is at a different domain than the DMARC record, the receiving domain must publish a verification record authorizing it to receive your reports. Without it, providers will not send.
Verify your record is correctly formed with a DMARC checker, and if you need to build or correct the record, a DMARC generator produces valid syntax with the right reporting tags.
Why This Skill Matters
DMARC reports turn blind email sending into visible, controllable infrastructure. Without reading them, you are publishing a DMARC record and hoping; many domains do exactly this, sitting forever at p=none because no one analyzed the reports needed to safely enforce. With the reports, you gain a complete map of who sends as your domain, you can spot spoofing attempts, you can fix authentication for every legitimate sender, and you can reach the p=reject enforcement that actually blocks impersonation and is increasingly required for inbox placement and brand-indicator eligibility.
The skill is not memorizing XML tags. It is learning to see the report as a table of senders and outcomes, then running the inventory, align, enforce loop until your domain is fully protected. That loop, grounded in the report data, is the difference between a DMARC record that exists and a DMARC deployment that works. Tie it into your broader email authentication practice and review the reports as a routine part of your deliverability monitoring.
Frequently Asked Questions
A DMARC aggregate report (RUA) is a daily XML summary that a mailbox provider sends to the address in your DMARC record's rua tag. It lists every IP that sent mail claiming to be from your domain over a 24-hour period, with the SPF, DKIM, and alignment results for each. It contains no message content or personal information, making it privacy-safe, and it is the primary tool for identifying spoofing and misconfigured senders.
RUA (aggregate) reports are daily summaries of all mail traffic claiming your domain, with no message content, and are the workhorse of DMARC monitoring. RUF (forensic) reports provide per-message failure detail including headers, useful for investigating individual spoofing attempts. RUF reports are increasingly rare because receivers limit them for privacy reasons, so most senders rely entirely on RUA reports.
Read it as a table rather than a document. Each record row represents one sending source and shows its IP, message count, disposition, and whether SPF and DKIM passed and aligned with your From domain. Inventory every source IP, identify what each is, confirm legitimate sources align, and watch for unknown sources that may be spoofing. For volume beyond a single domain, an automated analyzer presents this data as a dashboard.
The reports show you every legitimate source sending as your domain and whether each aligns. By inventorying all sources and fixing alignment while at p=none, you confirm no legitimate mail will be blocked before you enforce. Then you move to p=quarantine, verify clean results, and finally p=reject. The reports are the safety mechanism that lets you reach full enforcement without blocking your own mail; without them, enforcement is guesswork.
The common causes are DNS propagation delay (reports start within 24 to 48 hours of publishing your record), incorrect rua syntax (the mailto: prefix is required), or missing external domain verification (if your report address is on a different domain than the DMARC record, that domain must publish a verification record authorizing it). Check your record with a DMARC checker to confirm it is correctly formed.