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, and has run 100+ email campaigns for ecommerce brands, coaches, and B2B senders. He writes about email, SEO, WordPress, and AI — with a bias toward what can be tested over what sounds good.
Related Articles
How to Read Google Postmaster Tools
Google Postmaster Tools is a free dashboard reporting how Gmail treats mail from your domain, and since 2025 it no longer reports a reputation grade — it reports compliance, spam rate, and a plain-language verdict on whether Gmail's users want your email. No third-party checker carries the same authority, because no third party is making […]
Email Verification Tools: Which Are Worth Paying For
Email verification checks whether an address can receive mail, and it cannot tell you whether anyone behind it wants yours. That distinction decides whether the spend is worth it, because a verified address that never opens damages your reputation exactly as much as it did before you paid to confirm it exists. Verification solves one […]
Email Spam Traps: How to Find and Remove Them
A spam trap is an email address that exists only to catch senders with poor list practice, and no tool can tell you whether one is on your list. Traps accept mail silently. They do not bounce, they do not complain, and they do not appear in any report until the damage is already done. […]