How to Interpret DMARC Aggregate Reports

If you have published a DMARC record, you are probably receiving aggregate reports - and you are not sure what to do with them. They arrive as gzip-compressed XML attachments from dozens of different receivers. The data inside is precise, but reading it manually takes time you do not have.

That is the problem. And it is the reason most admins either ignore their reports or glance at them once and move on.

This guide fixes that. Walk through every major section of a DMARC aggregate report, what each field actually tells you, and how to use the data to catch spoofing, fix authentication failures, and make better decisions about your email security.

One thing to know upfront: parsing all this data manually is slow. That is why most people who take DMARC seriously end up using a tool like DMARCFlow to handle the parsing and normalization. But you still need to understand what the data means - and that is what this guide teaches.

Why DMARC Reports Exist and What They Give You

When you publish a DMARC record in your DNS, receivers that honor your request send periodic aggregate reports summarising authentication results for mail carrying your domain in the From: header.

These reports give you three things you cannot get anywhere else:

Which IP addresses are sending mail that claims to be from your domain
Whether SPF, DKIM, and DMARC checks passed or failed for each source
What the receiving mail server decided to do with mail that failed checks

Without aggregate reports, you are working blind. You do not know if your legitimate mail is passing authentication, if third parties are sending forged mail from your domain, or if your DMARC policy is actually being enforced by receivers.

Reports are typically sent daily per receiving domain. Send mail to Google Workspace, Microsoft 365, and Fastmail? You get three separate reports covering roughly 24 hours each.

The Three Main Sections of an Aggregate Report

Every DMARC aggregate report breaks into three layers.

Report metadata tells you who sent the report and what time window it covers:

The reporting domain (the receiver generating the report)
The date range (start and end timestamps)
Your domain as the report is for
A report ID you can reference when contacting the receiver about issues

The <record> array is the core of the report. Each record covers one message or one batch of identical messages from a single source IP. For each record you get:

The source IP address sending the mail
A count of how many messages
The results of SPF, DKIM, and DMARC checks (in auth_results)
The receiver is decision on what to do with the mail (in policy_evaluated)

Policy_evaluated is the outcome the receiving mail server reached after running authentication checks. This is not just a pass/fail - it tells you what the receiver actually did with the mail.

What auth_results Shows vs What policy_evaluated Means

This is where most people get confused, and it is the most important distinction in the entire report.

auth_results tells you the raw outcome of each individual check:

SPF check: pass, fail, softfail, or none
DKIM check: pass or fail
DMARC check: pass or fail

These are technical check results. They say nothing about what the receiver decided to do with the message.

policy_evaluated tells you what the receiver decided:

disposition: none, quarantine, or reject
SPF alignment: aligned or not aligned
DKIM alignment: aligned or not aligned

Alignment is the key concept. For DMARC to pass, either SPF or DKIM must align with the From: domain. That means the domain used in the SPF check (the return-path domain) or the domain in the DKIM signature must match the domain in the From: header that recipients see.

Here is the specific failure pattern that trips up most people:

An email passes SPF on the return-path domain and DKIM signs a subdomain like s1._domainkey.example.com. The From: header shows support@example.com. Because the DKIM signing domain does not match the From: domain, DMARC alignment fails - even though both SPF and DKIM individually passed.

This is why an email can show DKIM pass in auth_results and still fail DMARC in policy_evaluated. The DKIM check itself passed; the alignment check failed.

Decoding the <source> Element: Who Is Sending Mail From Your Domain

Every record in your aggregate report has a <source> element containing the IP address of the server that sent the mail.

This is the most actionable part of the report for most admins. The source IP tells you who is actually sending mail on behalf of your domain.

Unknown source IPs in your reports almost always mean one of three things:

A SaaS tool you forgot was sending mail from your domain (Salesforce, Zendesk, Microsoft 365, a marketing platform)
A legitimate email forwarding chain where the forwarder is rewriting the From: address
Someone spoofing your domain

When you see an unknown IP, cross-reference it against your known infrastructure. If you cannot identify it, look up the IP in a BGP/routing database to see which network it belongs to. A reverse DNS lookup on the IP often tells you what service is sending from it.

Keeping a running inventory of your authorized sending sources is the single most useful habit for interpreting DMARC reports over time. When you add a new SaaS tool, you should see it appear in your reports within 24-48 hours.

For organizations receiving reports from many different providers, tracking source IPs across multiple XML files manually is time-consuming. DMARCFlow maintains this inventory automatically, cross-referencing each new source against your known list and flagging unknowns as they appear.

What Disposition Values Mean in Practice

The disposition field in policy_evaluated tells you what the receiving mail server decided to do with the mail:

disposition "none" means the receiver took no special action. This typically occurs when the message passed DMARC alignment. It can also mean the receiver ignored your DMARC policy - some receivers implement DMARC loosely.

disposition "quarantine" means the receiver marked the message as suspicious. It may have gone to spam or a quarantine folder. The recipient may not have seen it at all.

disposition "reject" means the receiver refused the message entirely. The sending MTA received a 550 reject. The recipient never received the message.

A common misconception: disposition "none" in a DMARC aggregate report does not mean everything is fine. It means the receiver chose not to take action - which may simply mean the message passed authentication, but it might also mean the receiver does not fully enforce DMARC.

What matters is the combination of auth_results and policy_evaluated together. If you see SPF and DKIM both failing in auth_results but disposition is "none", the receiver is not enforcing your DMARC policy.

How to Spot Spoofing Attempts in Your Aggregate Report

Your aggregate reports are your early warning system for domain spoofing. Here is what to look for.

Unknown source IPs with high message counts. If a source IP you do not recognize is sending thousands of messages from your domain, that is almost always either a forgotten SaaS tool or spoofing. Check your sending source inventory first.

Subject lines and recipient patterns. Aggregate reports do not include subject lines - RFC 9990 intentionally excludes message content to protect recipient privacy. But if you hear from users that recipients are receiving suspicious emails with specific subject lines, and you see an unknown source IP generating failures, that is a corroborating signal.

Failures from your own IP ranges that you do not recognize. Sometimes admins find their own corporate mail server appearing in reports as a failure source - meaning the server is sending mail but the SPF or DKIM configuration is wrong. That is not spoofing, it is a configuration problem you need to fix.

Sudden spikes in failure volume. If your aggregate report shows a sharp increase in failed messages from sources you do recognize, something changed - either on your end (a new mail system, a configuration change) or someone launched a spoofing campaign using your domain.

DMARCFlow monitors for exactly these patterns - new source IPs, sudden failure spikes, and unusual rejection volumes - and alerts you before the problem reaches your users.

Why Reading Raw XML Is Painful and What to Do Instead

Raw DMARC aggregate reports arrive as gzip-compressed XML attachments. The XML structure is precise and machine-readable, but deeply unfriendly for human analysis.

For a small domain with one receiving provider, opening the XML and searching by hand might be manageable. For any organization that sends mail to multiple major receivers (Google, Microsoft, Apple, Fastmail, Proton, and others), you are receiving dozens of XML files per day covering overlapping time windows.

Comparing failure patterns across providers means opening multiple XML files, extracting the same fields, and reconciling the data manually. That is a full-time job.

This is exactly what DMARCFlow solves. DMARCFlow connects to your aggregate report destination, parses all incoming reports automatically, and normalizes the data across all receivers into a single dashboard. You see every source IP, every failure type, and every trend in one place, without touching XML.

For the routine daily review, DMARCFlow is significantly faster than manual XML analysis. For the occasional deep-dive into a specific failure event, knowing how to read the underlying XML remains valuable.

Your DMARC Report Interpretation Checklist

Use this checklist every time you review an aggregate report:

Identify every source IP in the report - confirm each one is a known, authorized sender
Check auth_results for any SPF or DKIM failures - note which sources and which check failed
Understand why each failure occurred - missing SPF include, wrong DKIM signing domain, alignment issue
Look for disposition=reject events and investigate immediately - those are emails that were refused
Check if new unknown sources appeared compared to the previous report - new sources are the most common sign of a new SaaS integration or a spoofing campaign
Note the ratio of passing to failing messages across all sources - a rising failure rate is an early warning
If using DMARCFlow, verify the dashboard shows no unexpected new sources or failure spikes since your last review

Frequently Asked Questions

How often should I review my DMARC aggregate reports?

At minimum, review them weekly during active DMARC monitoring. If you are in the process of moving from p=none to p=reject, review daily for the first two weeks after changing your policy. If you have DMARCFlow configured, set up daily or weekly digest alerts so you do not have to check manually.

My report shows SPF pass but DKIM fail. Does that mean DMARC passed?

Not necessarily. DMARC requires alignment on at least one mechanism (SPF or DKIM). If SPF passes and aligns, or DKIM passes and aligns, DMARC passes. If DKIM fails but SPF aligns, DMARC can still pass. Check the alignment fields in policy_evaluated to see whether each mechanism aligned with your From: domain.

I see failures from my own mail server. Should I be worried?

Yes, but it is usually a configuration problem, not spoofing. Your own mail server should pass both SPF and DKIM. Failures from your own IPs usually mean your SPF record does not include that IP, your DKIM selector is misconfigured, or your mail server is signing with a domain that does not match your From: domain. Fix the configuration - DMARCFlow will show you exactly which check is failing and why.

Can I get reports more frequently than daily?

Some receivers offer sub-daily report delivery, but daily is the most common. The reporting interval is set by the receiver, not by your DMARC record. You can request reports more frequently by adjusting your rua tag, but receivers are not obligated to honor shorter intervals.

What is the difference between aggregate reports and failure reports?

Aggregate reports (RUA) give you a summary of authentication results across many messages over a time period. Failure reports (RUF) give you detailed forensic information about individual message failures. Most organizations only use aggregate reports. Failure reports can be very large and contain sensitive recipient information, so they require careful handling.

What to Do With What You Find

Interpreting DMARC aggregate reports is a skill that improves with practice. The first few reviews take longer than you expect. After a month of regular reviews, you will recognize your sending patterns and spot anomalies faster.

The goal is not to read every report in detail every time. It is to develop a routine where you catch new sources, failure spikes, and unexpected rejection events before they become problems.

Start by reviewing your last 30 days of reports - most receivers will send archives if you request them. Build your sending source inventory first. Then set a weekly review habit. If you are moving to p=reject, move to daily reviews until you are confident your failure rate is near zero.

If that sounds like more manual work than you have time for, that is the exact problem DMARCFlow solves - automated parsing, normalized dashboards, and alert-based monitoring so you only dig into the details when something actually needs attention.