A DMARC aggregate report is a gzipped XML file sent daily by a receiving provider, listing every IP address that sent mail claiming to be from your domain and whether each one passed SPF, DKIM, and alignment. Reports arrive at the address in the rua tag of your DMARC record, one per provider per day.
The XML is machine-readable rather than deliberately obscure. A domain with a handful of sending services can be monitored by reading the reports directly, and the fields that matter number about eight.
What arrives, and from whom
| Sender | What they send | Frequency |
|---|---|---|
| Aggregate report for all Gmail-received mail | Daily | |
| Yahoo | Aggregate report | Daily |
| Microsoft | Aggregate report | Daily |
| Smaller providers and forwarders | Aggregate reports of varying completeness | Daily to weekly |
Each file is a .gz or .zip containing one XML document covering a 24-hour window. Volume scales with the number of providers your recipients use, not with your list size — a small sender still receives several files a day.
Aggregate reports contain no message content. They report counts by source IP and authentication outcome. Forensic reports (ruf) do contain message detail, and most providers do not send them for privacy reasons.
The structure of a DMARC report
Every report has three parts.
Part 1 — Report metadata
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>1234567890123456789</report_id>
<date_range>
<begin>1755993600</begin>
<end>1756080000</end>
</date_range>
</report_metadata>
org_name identifies who sent the report. The date_range values are Unix timestamps covering the reporting window.
Part 2 — Published policy
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
<pct>100</pct>
</policy_published>
This is the provider's reading of your DMARC record at the time of the report. Checking it against what you intended to publish catches DNS mistakes — a record showing p=none when you set p=quarantine means the change never propagated or a second record exists.
Part 3 — Records
The part that matters. One <record> block per sending IP address.
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>1250</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
<selector>s1</selector>
</dkim>
<spf>
<domain>mail.esp-provider.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
What each field actually tells you
| Field | Meaning |
|---|---|
source_ip |
The server that sent the mail. Identifies the service |
count |
How many messages that IP sent in the window |
disposition |
What the receiver did: none, quarantine, or reject |
policy_evaluated/dkim |
Whether DKIM aligned — not merely whether it passed |
policy_evaluated/spf |
Whether SPF aligned — not merely whether it passed |
header_from |
The domain in the visible From address |
auth_results/dkim/domain |
The domain DKIM actually signed as |
auth_results/spf/domain |
The domain SPF actually validated |
The single most important distinction in the whole report: policy_evaluated reports alignment, auth_results reports the raw pass or fail.
In the example above, auth_results shows SPF passing — and policy_evaluated shows SPF failing. Both are correct. SPF validated mail.esp-provider.com, the visible From domain is yourdomain.com, and those do not align. DKIM saved the message, because DKIM signed under the right domain.
That pattern is the mechanism behind "everything passes but DMARC fails", explained in full in email authentication: SPF, DKIM, DMARC and BIMI.
How to read a report in ten minutes
Five steps, repeatable weekly.
Step 1 — Unzip and open the file
The attachment is a .gz or .zip containing one XML file. Any text editor opens it; a browser renders it with collapsible nodes, which is easier for a first pass.
Step 2 — Check the published policy against what you intended
Compare policy_published against your DMARC record. A mismatch means a propagation delay, a typo, or a duplicate record — and it invalidates any conclusion drawn from the rest of the report.
Step 3 — Sort records by count, descending
The highest-volume sources are your real sending services. Reading in volume order puts the meaningful entries first and the noise last.
Step 4 — Categorise every source
| What you see | What it means | Action |
|---|---|---|
High count, dkim: pass in policy_evaluated |
A correctly configured service | None |
High count, both policy_evaluated results fail |
A legitimate service that is not authenticated, or a spoofer | Identify the IP before doing anything |
High count, raw results pass but policy_evaluated fails |
Misalignment — signing under the platform's domain | Configure custom domain authentication |
| Low count, mixed results | Usually a forwarder | Tolerate |
| Unfamiliar IP, meaningful volume, everything failing | Possible spoofing | Investigate before tightening policy |
Identify unfamiliar IP addresses before assuming spoofing. A reverse DNS lookup on the IP usually names the service, and the answer is frequently a tool a colleague set up months ago.
Step 5 — Record what you learned
Keep a running list of every source with its status. That list is the inventory that governs when the DMARC policy can safely tighten, described in how to set up DMARC safely.
Why legitimate mail fails DMARC
Four causes account for nearly all legitimate failures.
Misalignment. The service authenticates under its own domain. Fixed in the platform's domain authentication settings.
Forwarding. A recipient forwards to another address, and the forwarding server rewrites the path. SPF breaks; DKIM usually survives, which is why DKIM alignment is the more resilient of the two.
Mailing lists. Discussion lists modify subject lines and add footers, breaking the DKIM signature. Well-configured lists rewrite the From address to avoid the problem.
A missed sending service. A tool that sends as your domain without ever being added to SPF or configured for DKIM.
Forwarding failures are the reason to reach enforcement via DKIM alignment rather than SPF alignment. A message that survives forwarding is one whose DKIM signature aligned.
When a paid DMARC analyzer earns its cost
Reading raw XML is practical up to a point, and past that point it stops being a good use of anyone's time.
| Situation | Manual reading | Paid analyser |
|---|---|---|
| One domain, three or four sending services | Practical | Unnecessary |
| One domain, ten or more sending services | Tedious | Worth it |
| Multiple domains | Impractical | Necessary |
| Moving to enforcement on a complex estate | Risky | Necessary |
Ongoing monitoring after reaching p=reject |
Adequate | Convenient |
What an analyser genuinely adds: source identification by name rather than IP, trend charts across weeks, alerting on new sources, and forensic detail on failures. What it does not add is any authority — the underlying data is identical to the XML in your inbox.
Free tiers exist at most analyser vendors and generally cover one domain at low volume, which suits exactly the sender who would otherwise read the XML manually.
What's in the book, not here. The weekly report-review routine and the thresholds that should trigger action are in The Email Deliverability Playbook.
Frequently asked questions
What is a DMARC aggregate report?
A DMARC aggregate report is a gzipped XML file sent daily by a receiving provider, listing every IP address that sent mail claiming to be from your domain and whether each passed SPF, DKIM, and alignment. Reports arrive at the address in the rua tag and contain no message content.
Why am I getting DMARC failures from my own domain?
Usually misalignment rather than a genuine failure. A sending platform that signs DKIM under its own domain produces a raw pass in auth_results and a fail in policy_evaluated, because the authenticated domain does not match the visible From domain.
Are DMARC analyzers worth paying for?
Not for a single domain with three or four sending services, where the XML is readable directly. They become worthwhile at ten or more sending services, across multiple domains, or when moving a complex estate to enforcement.
What is the difference between policy_evaluated and auth_results?
policy_evaluated reports whether SPF and DKIM aligned with the visible From domain, which is what DMARC actually judges. auth_results reports the raw pass or fail of each check regardless of alignment. A record can show a pass in one and a fail in the other.
Do DMARC reports contain the content of my emails?
Aggregate reports do not. They report counts by source IP and authentication outcome only. Forensic reports, requested with the ruf tag, can contain message detail, and most providers do not send them for privacy reasons.
Why does forwarded email fail DMARC?
Forwarding servers rewrite the return path, which breaks SPF, while the DKIM signature usually survives intact. A message that aligns on DKIM survives forwarding, which is why DKIM alignment is the more resilient route to enforcement.
How often do DMARC reports arrive?
Once per day per reporting provider, covering a 24-hour window. Volume depends on how many different providers your recipients use rather than on the size of your list, so even small senders receive several files a day.
What to do next
Open the most recent report and check policy_published against your DMARC record. That single comparison catches DNS mistakes that would otherwise invalidate weeks of observation.
Then sort the records by count and identify the top three sources. Those are your real sending services, and their alignment status is what determines whether the policy can tighten.
Free: The 60-Minute Email Authentication Fix — verify SPF, DKIM, DMARC, and alignment on your own domain.
Go deeper: The Email Deliverability Playbook — the weekly review routine and the thresholds that trigger action.
Related guides
- How to set up DMARC safely — what these reports gate
- Email authentication: SPF, DKIM, DMARC and BIMI — why alignment fails
- How to read Google Postmaster Tools — the other free provider dashboard
- Bulk sender requirements 2026 — the policy level providers expect
- Why authenticated emails still land in spam — what clean reports do not guarantee
The short version
- Unzip and open the fileThe attachment is a .gz or .zip containing one XML document. Any text editor opens it, and a browser renders it with collapsible nodes for an easier first pass.
- Check the published policy against what you intendedCompare the policy_published block with your DMARC record. A mismatch means a propagation delay, a typo, or a duplicate record.
- Sort records by count, descendingThe highest-volume sources are your real sending services, so reading in volume order puts the meaningful entries first.
- Categorise every sourceSort each into correctly configured, misaligned, unauthenticated, forwarder, or possible spoofing. Run a reverse DNS lookup on unfamiliar IP addresses before assuming spoofing.
- Record what you learnedKeep a running list of every source with its status. That list governs when the DMARC policy can safely tighten.
Free: The 60-Minute Email Authentication Fix
A no-fluff checklist to set up SPF, DKIM & DMARC correctly and pass Gmail & Yahoo's sender requirements.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Abandoned Cart Emails: Why Timing Beats Discounting
An abandoned cart email sequence is three automated emails sent over 48 hours to someone who added an item to a cart without buying, with the first sent one to four hours after abandonment. Speed has a larger effect on recovery than any copy decision in the flow. The discount belongs in email three, and […]
Email Blocklists: How to Check, and How to Get Removed
An email blocklist is a published list of IP addresses or domains that receiving servers consult before accepting mail, and only a handful of them meaningfully affect delivery. Checking tools flag dozens. Most of those listings change nothing about where your email lands. Knowing which listings matter is the difference between a ten-minute fix and […]
Why Your Emails Suddenly Went to Spam: The Diagnostic Order
Email that went to spam suddenly has one of five causes: a DNS or authentication change, a list or sending change, a linked-domain problem, a blocklist listing, or a complaint spike. Each one leaves a different trace, and each can be confirmed or ruled out in minutes. The order matters more than the effort. Working […]