How to read DMARC aggregate (rua) reports for B2B services newsletters

Every major receiver — Google, Yahoo, Microsoft, Mail.ru, Comcast — sends aggregate reports to the rua= address once per 24-hour window. The reports accumulate in an inbox most firms never open. Until someone reads them, the DMARC record is a monitoring tool with the monitoring turned off.

This page is part of our Newsletter Deliverability playbook — the broader guide on inbox placement and 2024 bulk-sender rules. The sections below walk through the report structure, what to look for in the data, which tools parse the XML, and how the data drives the p=none to p=quarantine advance.

What is a DMARC aggregate report and what is in it?

Short answer: An RFC 7489 §7.2 XML file covering one 24-hour window. It identifies every source IP that sent mail claiming your domain, the volume from each source, whether SPF and DKIM passed, whether the authenticated domains aligned with the From: header, and what disposition the receiver applied. The inputs for every authentication decision you will ever make live in this file.

The report schema is defined in RFC 7489 §7.2 and has not changed since the RFC's 2015 publication. Every compliant receiver uses the same XML structure. The top-level fields are: org_name (the reporting receiver), report_id (unique identifier for this report), and date_range (begin/end Unix timestamps for the 24-hour window). The policy_published block records what your DMARC record said at the time the receiver evaluated the messages — useful for confirming that a policy change propagated correctly.

The substantive data lives in record blocks. Each record represents a unique combination of source IP, SPF result, and DKIM result observed during the reporting window. The record contains: a row with the source_ip, count, and policy_evaluated (disposition + DKIM/SPF outcomes); an identifiers block with the header_from domain; and an auth_results block with granular SPF and DKIM result detail including the domains that were evaluated. A trimmed example of a healthy record:

In the example above, 209.85.220.41 is a Google SMTP IP, confirming the send originated from a Gmail-infrastructure source. Both SPF and DKIM passed with firm.com as the authenticated domain — aligned with the header_from. Disposition is none because the policy at the time of evaluation was p=none. This record requires no action.

Reports are delivered to the rua= address as gzip-compressed XML attachments. The subject line follows the pattern: Report Domain: firm.com Submitter: google.com. Most firms set a dedicated mailbox ([email protected]); redirecting to a personal inbox works but adds noise. A parsing tool is strongly recommended — reading raw XML for more than a handful of sources is impractical.

What do you actually look for when reading them?

Short answer: Four signals. Authorized sources passing both SPF and DKIM (healthy), authorized sources passing only one (investigate alignment), authorized sources failing both (broken authentication), and unknown source IPs sending in your name (potential abuse or forgotten authorization). The first category needs no action; the other three do.

The 4-signal pattern covers the decision tree for every record in an aggregate report. Signal one: an authorized source IP (one belonging to your ESP or internal mail server) passes both SPF and DKIM, with the authenticated domains aligning to your From domain. This is the baseline healthy state — the source is authorized, the authentication is working, and the alignment holds. No action required.

Signal two: an authorized source passes only one mechanism. DKIM-only DMARC pass occurs when SPF fails but DKIM is aligned — common when an ESP sends from an IP range not covered by your SPF record, but the DKIM signature is correctly set to your domain. Under RFC 7489 and RFC 6376, a DKIM-only pass is a valid DMARC pass; the message is compliant. However, the SPF failure should still be investigated and corrected — a future DKIM rotation without an SPF fix would break compliance. SPF-only DMARC pass — SPF passes but DKIM fails — is less stable because DKIM pass is required by some forwarding and compliance archiving scenarios (RFC 8617 ARC does not rescue messages that were never DKIM-signed in the first place).

Signal three: an authorized source fails both SPF and DKIM. This is a broken authentication state. The source is legitimate, but it is sending unauthenticated mail. Common causes: an ESP migration where the new platform has not yet been added to SPF and DKIM has not been configured; a new subdomain or sending IP that was not added to the DNS records; or a DKIM key rotation that was completed on the ESP side but the old DNS record was deleted before the new one propagated. At p=none, these messages are delivered but flagged. At p=quarantine or p=reject, they will be filtered or rejected.

Signal four: an unknown source IP is sending in your name. The header_from is your domain, but the IP does not belong to any service you authorized. Two explanations: a third-party service you forgot you authorized (a CRM trial, a notification tool, a support desk), or genuine abuse — someone spoofing your domain. Look up the IP in ARIN/RIPE WHOIS and cross-reference against your ESP and application inventory. If it is not a service you recognize, it is the primary reason to advance from p=none to p=quarantine.

Which tools parse the XML and which to skip?

Short answer: Postmark DMARC Digest (free, weekly summary) and dmarcian (free tier for low volume) are the most practical starting points for B2B professional services firms. Valimail Authenticate and EasyDMARC add automated source classification and policy recommendation at paid tiers. The trap is relying on any single vendor's interpretation without understanding the underlying data.

Postmark DMARC Digest is a free weekly email digest that parses your incoming aggregate reports and summarizes source IPs, pass/fail counts, and alignment status. No dashboard to maintain; the summary arrives by email. It covers the monitoring phase well for most small senders.

dmarcian's free tier allows one domain and provides a UI for exploring individual reports, a source classification feature that maps IPs to known ESP infrastructure, and a policy advancement recommendation. The paid tiers add multi-domain management, historical trend analysis, and alert rules — useful when you are actively managing the pct= ramp and need to detect new unauthorized sources quickly.

Valimail Authenticate and EasyDMARC both offer automated SPF and DKIM configuration management alongside aggregate report parsing — the value proposition is reducing the manual DNS work during initial setup. Cloudflare Email Routing forwards inbound reports to any destination but does not parse them; it is infrastructure, not a reporting tool.

A note on forensic (ruf) vs. aggregate (rua) reporting in these tools: most dashboards surface aggregate data only, because ruf delivery has declined sharply (covered in the next section). The paid “failure reporting” features in dmarcian and Valimail process ruf reports when they arrive, but do not manufacture them. If a tool claims to provide message-level failure detail without a configured ruf= address, read the fine print.

The trap of single-vendor interpretation: every vendor normalizes and classifies report data differently. A source IP that dmarcian classifies as “known ESP infrastructure” may be an IP range that was reassigned or is shared between services. Before advancing policy based on dashboard output, read at least one raw report to understand what the underlying data actually contains.

How does the report data drive the p=none to p=quarantine advance?

Short answer: Advance when 95% of mail volume passes DMARC on a rolling 14-day average AND the remaining 5% is identified and either authorized or remediated. Move to p=quarantine; pct=25 first, not directly to pct=100. Ramp weekly. Never advance on partial data.

The 95% threshold is the industry consensus starting point — M3AAWG and Google's own guidance reference it as the minimum confidence level before moving to enforcement. The remaining 5% should be understood, not merely assumed to be noise: is it forwarded mail losing DKIM through a gateway (addressable with ARC, RFC 8617), a quarterly-send service that only fires in January, or genuine unauthorized use?

The quarterly-service trap deserves explicit attention. A firm that advances from p=none to p=quarantine in March based on clean February and March data may have missed a tax-document service or annual renewal system that only sends in January. That service shows up in the aggregate reports only when it fires. If the advance happened in February, the next send from that service in January gets quarantined — potentially a high-priority transactional email. Wait for a full quarterly volume baseline before advancing if your sending profile includes seasonal or annual services.

The staged pct= ramp reduces the blast radius of any configuration error. Starting at pct=25 means 75% of failing messages are still processed under the previous policy (effectively p=none). If a legitimate source appears in the failing 25%, you can identify it before it affects 100% of traffic. The ramp sequence — 25, 50, 75, 100 — gives one to two weeks of data at each step. At each step, check the aggregate reports for new source IPs and for any shift in the pass-rate distribution.

Once p=quarantine; pct=100 has been stable for two to four weeks with no new unauthorized sources appearing and no legitimate mail quarantined, advance to p=reject. The p=reject policy is the end state Microsoft's Outlook sender policies page explicitly recommends, regardless of sender volume. BIMI eligibility requires p=quarantine or stricter; p=reject satisfies that requirement.

An example working record at p=quarantine; pct=25 with both rua= and ruf= configured:

The fo=1 tag requests forensic reports for any authentication failure (SPF or DKIM fail), not only full DMARC failures. This is the most informative setting during the ramp phase, though as the next section explains, most major receivers no longer send forensic reports regardless of the fo= value.

What does forensic / failure (ruf) reporting add — and is it worth it?

Short answer: Forensic reports are per-failure message samples with header and body detail. Most major receivers have stopped sending them. Google does not send ruf reports at all. Yahoo and Microsoft still send selectively. In 2026, ruf is rarely useful for firms under high volume; aggregate is the workhorse.

Forensic (ruf) reports, specified in RFC 7489 §7.3, are per-failure notifications that include message-level detail — headers, body fragments, and the specific authentication failure that triggered the report. They were designed as a diagnostic tool for investigating individual authentication failures in detail: identifying exactly which message from which source failed and why.

The privacy problem is structural. A forensic report may include the contents of the original message, which can include personal data of the recipient or sender. GDPR Article 6 lawful basis and CCPA/CPRA data minimization obligations created legal risk for receivers forwarding message content to a third-party address they do not control. The response from most major receivers was to stop sending ruf reports rather than to solve the privacy scoping problem. Google halted ruf report sending in 2023. Microsoft and Yahoo continue to send selectively, primarily for high-volume senders with established feedback relationships, but the volume and reliability of ruf delivery from both providers is low.

The practical implication for B2B professional services firms: do not rely on ruf reports as a diagnostic tool. Configure the ruf= address and fo=1 flag in your DMARC record as a best-effort signal — some receivers and smaller providers still send them, and they can surface specific forwarding failures or misconfigured services that do not appear clearly in aggregate data. But the aggregate reports from rua= are the primary diagnostic tool for the policy advancement decision. If you are not seeing ruf reports, that is not a configuration error — that is the current state of the ecosystem.