How to Read a DMARC Aggregate Report (RUA): Field Guide

How to read DMARC aggregate reports in one pass: group by source, check volume against expectation, verify SPF/DKIM and alignment, note receiver disposition, then label each source (known good / needs setup / suspicious). Aggregate (RUA) reports are daily XML summaries of who sent as your domain — not full message copies. Use them for sender inventory and enforcement readiness, not single-incident forensics.

Publishing a DMARC record is step one. Reading the feedback is how you know whether that record is doing useful work or quietly watching spoofing and misconfigured senders pass by.

Most domains start with something like:

v=DMARC1; p=none; rua=mailto:reports@example.com;

That rua= address receives DMARC aggregate reports (RUA). Mailbox providers that accepted mail claiming to be from your domain send short summaries: counts, sources, pass/fail, and what they did under your policy. This guide is for teams who have reports arriving but still cannot answer: who is sending as us, is it legitimate, and are we ready to enforce?

How to read a DMARC aggregate report

Open any reporting period (or your monitor’s source table) and walk these five columns in order. You do not need to parse every XML tag on the first pass.

What to look at	Plain-language question	Action if wrong
Source (IP / org)	Who is sending as our domain?	Label known, needs setup, or unknown
Volume (count)	Is this volume plausible for that system?	Spike + unknown → spoofing candidate
SPF / DKIM result	Did authentication pass at the hop?	Fail → fix platform DNS or path
Alignment	Did pass apply to our brand domain?	Unaligned pass ≠ DMARC pass
Disposition	What did the receiver do under our p=?	Under p=none, fails often still deliver

Answer first, then dig: if a high-volume source is unknown and failing, treat it as a spoofing or mis-set From problem before you debate SPF syntax. If a known ESP fails alignment, open a ticket with that platform owner — do not jump straight to p=reject.

For public DNS posture while you sort sources, use free tools. For ongoing report visibility someone will actually open weekly, point rua= at a monitor rather than an unwatched mailbox.

What is a DMARC aggregate report (and what it is not)

An aggregate report typically covers a short time window (often about a day) and answers:

• Which source IPs or organisations sent mail using your domain
• How much volume each source produced
• Whether SPF and DKIM passed
• Whether those results aligned with the DMARC policy domain
• What the receiver did under your current policy (none, quarantine, or reject)

It is not:

• A full copy of every email
• A substitute for mailbox or gateway logs
• Proof that a human “clicked phishing”
• A complete inventory of every edge case (some receivers report late, incompletely, or not at all)

If you need message-level detail for a specific incident, use headers, gateway logs, and forensic/RUF only if you understand the privacy and volume trade-offs. Aggregate reports are for trend and inventory, not courtroom evidence of a single spam message.

Related: when you are ready to act on clean inventory, follow the safe path from p=none to p=reject. Marketing teams under Gmail/Yahoo rules should also read Gmail and Yahoo sender requirements.

DMARC aggregate report fields that matter

Raw RUA XML varies slightly by reporter, but the operational fields map cleanly:

Report metadata

• Report ID / org name — which mailbox provider produced the summary (Google, Microsoft, Yahoo, etc.)
• Date range — usually ~24 hours; late or partial windows are normal
• Policy published — the DMARC record the receiver saw for your domain (p=, sp=, alignment modes)

Per-source (row) fields

• Source IP — connecting IP that delivered the message to that reporter
• Count — how many messages this row represents in the window
• Disposition — what the receiver applied (none / quarantine / reject style outcomes)
• SPF result — pass / fail / softfail / neutral / none (and related evaluation states)
• DKIM result — pass / fail / none for signatures evaluated
• SPF domain / DKIM domain — which domains were evaluated (critical for alignment)
• Header From domain — the visible From domain users saw
• Auth results vs policy evaluated — whether authentication satisfied DMARC under the published policy

You do not need every optional tag. You need enough to answer the four questions below for each material source.

The four questions that matter when reading DMARC reports

Ignore deep XML until you can answer these in plain language for the reporting period.

1. Who is sending as our domain?

Group by source organisation or IP range. You are looking for:

• Known platforms (Microsoft 365, Google Workspace, ESP, CRM, billing)
• Forgotten systems (old newsletter tools, web forms, printers)
• Unknown bulk sources (possible spoofing or mis-set From addresses)

A healthy early report set is messy. That is normal. The goal is a sender inventory, not a clean dashboard on day one. Cross-check high-volume unknowns against your SPF and DKIM setup work — many “unknown” rows are tools that were never finished in DNS.

2. Is the volume legitimate for that source?

A support desk might send dozens of messages a day. A billing system might spike at month-end. A random IP in another country sending thousands of messages as your domain is not “noise” — it is a signal.

Compare report volume to what you expect from each platform. Large unexplained volume is either:

• spoofing worth blocking later with enforcement, or
• a real sender you have not authorised in DNS yet

3. Did authentication pass — and did it align?

SPF or DKIM can “pass” in a technical sense while still failing DMARC alignment. Alignment is the bridge between authentication and your brand domain.

In practice:

• SPF aligned: the domain used in the SMTP MAIL FROM / return-path path lines up with your DMARC organisational domain under your policy rules
• DKIM aligned: the domain in the DKIM d= signature lines up with your From domain under those same rules

Mail that fails alignment will not satisfy DMARC, even if some hop “looked authenticated.” This is why third-party tools that only add SPF includes — without DKIM on your domain — often show up as failures once you look carefully. Fixing that path is covered in the DKIM setup guide and the DMARC setup guide.

4. What disposition did receivers apply?

Under p=none, most failing mail is still delivered. The report’s disposition field tells you what receivers would do under stronger policy, and what they did under the policy you published.

If failures are almost all unknown sources, enforcement is easier. If failures include your real ESP or ERP, fix those first — then move along the enforcement path.

How to read DMARC reports: weekly triage checklist

Use the same process every week until the inventory stabilises.

1. Confirm reports are arriving — rua= mailbox or monitor ingest for the last 7 days.
2. List new sources since last review (new IP ranges or provider names).
3. Label each source: known good, needs setup, unknown/suspicious.
4. For known good with failures: open a ticket with the platform owner (SPF include, DKIM CNAME, From domain).
5. For unknown with high volume: treat as spoofing candidates; do not “whitelist” by gut feel.
6. For low-volume unknowns: note and re-check next period before changing policy.
7. Record decisions in a short sender register (even a spreadsheet is fine).
8. Re-check after every DNS change — new includes and keys should show up as improved pass rates within a few report cycles.

Teams that skip the register re-discover the same senders every month.

Common patterns when understanding DMARC reports

Perfect-looking corporate mail with SPF fail

Forwarding, mailing lists, and some gateways break SPF. DKIM often still passes. Do not panic-delete includes until you understand the path. If DKIM is aligned, DMARC can still pass. (See also ARC and forwarded mail when intermediaries re-sign or alter the path.)

Marketing platform with no DKIM on your domain

The ESP is real, but it is sending with weak or unaligned authentication. Complete the platform’s domain authentication setup before you tighten policy. Gmail/Yahoo bulk-sender expectations make this non-optional for marketing volumes — see sender rules for marketing teams.

Huge unknown volume that never contacts your users

Spoofers and scanners probe domains constantly. Under monitoring policy you mostly observe it. Under p=reject much of that never reaches inboxes. That is the point of enforcement — not zero reports forever. Domain spoofing and lookalike domains are different problems; spoofing of your exact domain is what DMARC enforcement targets — see lookalike domains vs spoofing.

Subdomain traffic you did not expect

Check whether marketing or IT launched mail., news., or notify. hosts. Subdomain policy (sp=) and organisational domain coverage matter. Inventory the hostnames, not only the apex domain.

SPF permerror or broken SPF on a known platform

If a “legitimate” source fails SPF consistently, the record may be over the 10-lookup limit or syntactically broken. Fix that with the SPF setup guide and how to fix SPF permerror without breaking mail — do not only chase DMARC tags.

Mini example: reading three source rows

Illustrative rows (simplified):

Source	Count	SPF	DKIM	Aligned?	Disposition (p=none)	Read as
Your M365 range	1 240	pass	pass	yes	none	Known good — keep
ESP CDN IP	380	pass	fail	no	none	Real tool; finish DKIM on your domain
Random /24 abroad	9 100	fail	fail	no	none	Spoofing/probe volume — candidate for later reject

That middle row is the classic “we have SPF include but no brand DKIM” failure. Fix authentication before policy. The bottom row is why permanent p=none leaves the brand exposed.

How long to stay on monitoring

There is no universal calendar, but there is a decision rule:

Stay on p=none only while you are still discovering legitimate senders or remediating them.

If the same known platforms pass cleanly for several reporting cycles, and remaining failures are unexplained bulk or junk, you are ready to plan quarantine — not to “monitor forever.” Permanent monitoring is a common failure mode: the reports keep arriving, nobody acts, and spoofing continues. When inventory is clean, follow the enforcement path from none to reject.

What “good enough to move on” looks like

You can usually schedule a move toward enforcement when:

• Every intentional sender is identified and owned
• High-volume intentional senders pass DMARC alignment consistently
• Remaining fails are low-value unknown sources or known edge cases with a plan
• Someone is assigned to re-check reports after the policy change
• Rollback is possible (DNS access and a known prior record)

If you cannot name the owner of a high-volume fail source, you are not ready.

Tools vs raw XML

Raw XML is fine for a lab exercise. For ongoing operations, use a monitor that:

• rolls sources into readable totals
• highlights new senders
• separates pass / fail / disposition
• keeps history so you can see whether a fix worked

Whether you build that yourself or use a product, the operational outcome is the same: decisions from reports, not archives of XML. DMARC Shield Monitor is built for that weekly review loop; teams that want hands-on cleanup can look at managed service.

Practical next steps this week

1. Confirm rua= is receiving (or that your monitor is ingesting reports).
2. Export or view the last 7–14 days of sources.
3. Build a one-page sender inventory with owner and status.
4. Fix the top two failing legitimate sources (SPF / DKIM as needed).
5. Set a calendar reminder to re-read reports after each DNS change.
6. When known senders pass cleanly, plan the next step on the enforcement path.

DMARC without report review is a sign on the door that nobody checks. Report review turns it into a control.

Start with a free domain check on free tools, complete DMARC setup if you have not already, then point aggregate reporting at a monitor you will actually open.