How to Read DMARC Aggregate Reports
You set up DMARC with a rua= reporting address, and now your inbox is filling up with XML files from Gmail, Microsoft, Yahoo, and other mail servers. These reports contain valuable data about who is sending email as your domain and whether their authentication is working. But the raw XML format is nearly unreadable by humans.
Here is how to decode DMARC aggregate reports, what to look for, and how to use the data to improve your email authentication and deliverability.
What Aggregate Reports Contain
Every mailbox provider that receives email claiming to be from your domain generates periodic aggregate reports. Gmail sends them daily. Microsoft and Yahoo send them daily or weekly. The reports cover a specific time period and include every IP address that sent email using your domain in the From header.
Each report contains: the reporting organization (who generated the report), the time period covered, your DMARC policy record as they see it, and a set of records, each representing a sending source.
For each sending source, the report includes: the source IP address, the number of messages received from that IP, the DMARC evaluation result (pass or fail), the DMARC policy applied (none, quarantine, or reject), SPF authentication results (pass, fail, or neutral), SPF alignment (aligned or not), DKIM authentication results (pass, fail, or none), and DKIM alignment (aligned or not).
The Raw XML Structure
DMARC reports arrive as gzipped XML files attached to emails. The XML follows a defined schema, but it is dense and repetitive. A single report from Gmail covering one day might contain dozens of records if many different servers sent email as your domain.
The key XML elements are: report_metadata (who sent the report and when), policy_published (your DMARC record as they see it), and record (one per sending source, containing row and auth_results).
Within each record, the row element contains the source IP, count of messages, and the policy evaluation results. The auth_results element shows the detailed SPF and DKIM results.
You can open these XML files in a text editor and read them, but this quickly becomes impractical if you have multiple sending domains or high email volume. Automated parsing is the way to go.
Using DMARC Report Analysis Tools
Several tools parse DMARC XML reports into human-readable dashboards. Free options include dmarcian (limited free tier), URIports, and DMARC Analyzer. Paid options with more features include dmarcian Pro, Valimail, EasyDMARC, and Agari.
These tools typically work by giving you a dedicated reporting email address that you use in your DMARC rua= tag. Reports flow to the tool, which parses them automatically and presents the data in a dashboard.
The dashboard typically shows: a summary of total messages, percentage passing DMARC, a list of all sending sources (identified by IP and, where possible, resolved to organization names), pass/fail status for each source, and trends over time.
What to Look For
Authorized sources that are failing. Your most important finding is any legitimate sending service that is failing SPF or DKIM. If your cold email platform appears in the report with dkim=fail, you have a configuration issue that is hurting your deliverability. Fix it immediately.
Unknown sending sources. Any IP address that you do not recognize sending email as your domain is potentially unauthorized. It could be a service you forgot about (an old marketing tool, a CRM integration), or it could be someone spoofing your domain. Investigate every unknown source.
Alignment failures. A sending source might pass SPF or DKIM but fail alignment. This happens when the authentication domain does not match the From domain. For example, your cold email platform might authenticate with its own domain (dkim=pass for platform.com) rather than your domain (dkim=fail for yourdomain.com). The fix is configuring custom DKIM for that service.
Volume anomalies. If a sending source suddenly starts sending thousands of messages as your domain when it usually sends hundreds, investigate. Volume spikes from legitimate sources might indicate misconfiguration. Volume spikes from unknown sources might indicate spoofing.
Reading the Authentication Results
Each record in the report shows SPF and DKIM results. Here is what each combination means:
SPF pass + DKIM pass + both aligned: This is the ideal result. Everything is properly configured and authenticated.
SPF pass + DKIM fail: SPF is working but DKIM is not configured or misconfigured for this sending source. Fix the DKIM configuration for that service.
SPF fail + DKIM pass: DKIM is working but the sending IP is not in your SPF record. Add the service's SPF include statement to your record.
SPF fail + DKIM fail: Neither authentication mechanism is working for this source. Either the source is unauthorized (someone spoofing your domain) or it is a legitimate service with no authentication configured. Investigate and fix or block.
Pass but not aligned: The authentication succeeds against its own domain but does not align with your From domain. This is a common issue with third-party services that sign with their own domain rather than yours. Configure custom signing.
Identifying Spoofing Attempts
One of DMARC's primary benefits is visibility into domain spoofing. Your aggregate reports show you every server that has attempted to send email as your domain, including unauthorized ones.
Spoofing attempts typically appear as records with unknown source IPs, high message volumes, and authentication failures across both SPF and DKIM. The source IP will not resolve to any service you use, and the authentication results will show complete failures.
If you see consistent spoofing attempts, it reinforces the importance of advancing your DMARC policy from p=none to p=reject. At p=none, spoofed emails are still delivered. At p=reject, they are blocked. The reports give you the evidence to justify the policy advancement.
Building a Monitoring Routine
Do not set up DMARC reporting and then ignore the data. Build a regular monitoring routine.
Weekly review: Check your DMARC analysis dashboard for any new failures, unknown sources, or volume anomalies. This 10-minute weekly review catches issues before they compound.
After adding new services: Whenever you connect a new email-sending tool (new cold email platform, new marketing tool, new CRM), check DMARC reports within a few days to verify the new service passes authentication with proper alignment.
After DMARC policy changes: When you advance from p=none to p=quarantine, or from quarantine to reject, monitor daily for the first week. You want to catch any legitimate email that is being affected by the stricter policy immediately.
Monthly summary: Track your overall DMARC pass rate monthly. It should be above 98% for all legitimate sending. If it is below that, you have authentication issues to address.
DMARC Reports for Cold Email Operations
Cold email operations benefit from DMARC report monitoring in several specific ways.
First, reports confirm that your cold email platforms are properly authenticated. If you set up 10 cold email domains and each has 2-3 sending services, that is 20-30 authentication configurations to get right. DMARC reports are the most reliable way to verify they are all working.
Second, reports reveal if any of your cold email domains are being spoofed. Cold email domains sometimes get abused by spammers who see them in email headers and attempt to spoof them. Catching this early and advancing to p=reject prevents reputational damage.
Third, reports help you diagnose deliverability issues. If one cold email domain suddenly shows authentication failures in DMARC reports, that domain's deliverability is likely degraded. The report pinpoints the specific authentication failure, allowing targeted fixes rather than guesswork.
DMARC reports are one of those rare tools that get more valuable the more you use them. They start as a compliance checkbox and become an essential monitoring system that protects your domains, catches problems early, and provides the data you need to make informed decisions about your email authentication strategy.
