What are DMARC aggregate reports?

Publish a DMARC record with a rua tag and something useful happens: every major mailbox provider that receives mail claiming to be from your domain starts emailing you a regular accounting of it. Google's documentation puts it plainly: reports tell you "which servers or third-party senders are sending mail for your domain" and "what percentage of messages from your domain pass DMARC". That includes senders you forgot about and spoofers you never knew about.

The format is fixed by RFC 9990: an XML file that should be gzip-compressed, attached to an email, with a filename that encodes the receiver, your domain, and the reporting window. Cadence is convention rather than a rule, the spec describes daily or more frequent feedback without mandating an interval, and RFC 9989 retired the ri tag that used to request one. In practice you get one report per receiver per day, so a domain with real traffic collects dozens of XML files a week.

Aggregate means aggregate. A report never contains a message body, a subject line, or a recipient address; it contains counts. That distinction matters because DMARC defines a second, separate report type (ruf, the failure or forensic report) that does reference individual messages, and the two get conflated constantly. The next section splits them properly.

RFC 9989 defines both tags, and the DMARCbis split gives each its own spec. rua requests aggregate feedback, defined in RFC 9990: the XML count summaries this page describes, safe to receive because they carry no message content. ruf requests message-specific failure information, defined in RFC 9991: a per-message failure report in AFRF format (RFC 6591) generated when an individual message fails DMARC, which can include headers from the actual message.

In practice the two are not equally available. Google states in its DMARC setup documentation that "Gmail doesn't support the ruf tag, which is used to send failure reports", and most large receivers have followed the same path for privacy reasons. Plan your DMARC rollout around aggregate reports; treat any ruf data that arrives as a bonus, not a data source you can depend on. The glossary entries for the rf and fo tags cover the failure-report format and trigger options if you do publish one, note that RFC 9989 retired rf along with ri and pct.

Open a report and skip to the record blocks; everything else is context. For each record, read three things in order. First, source_ip and count: who sent, and how much. Look the IP up (the PTR record or an IP reputation check usually names the service) and decide whether you recognize it as your mail server, your CRM, your helpdesk, or nothing you run.

Second, policy_evaluated: the dkim and spf values here are the aligned verdicts, and disposition is what the receiver did (none, quarantine, or reject). A legitimate source showing fail on both aligned checks is a misconfiguration you need to fix before tightening policy; an unrecognized source showing fail is exactly the spoofing DMARC exists to stop.

Third, when something fails aligned but you know the sender is real, drop down to auth_results and identifiers to see why. The classic pattern is SPF passing for the service's own bounce domain in envelope_from while header_from is your domain: raw pass, alignment fail. That specific failure mode has its own page at /learning/email-questions/why-is-dmarc-failing-but-spf-passes.

One report is readable. The steady state is not: every receiving provider sends its own file for its own window, so a real domain accumulates hundreds of gzipped XML attachments a month, keyed by IP address rather than by sender name, with the same third-party service scattered across dozens of IPs. Answering the one question that matters ("is every legitimate sender passing aligned, and who is the rest?") means joining thousands of records across files and mapping IP ranges to services.

That is why DMARC report parsing exists as a product category: everything from open-source parsers to managed platforms ingests the XML at the rua address and turns it into a per-sender view over time. Palisade does this as part of its managed DMARC service, with unlimited report retention on paid plans, and uses the parsed data to drive enforcement rather than just chart it. Whatever tooling you choose, the goal is the same: stop reading XML, start reading senders.

It is easy to run DMARC as a reporting hobby: reports arrive, a dashboard fills, and the policy stays at p=none forever, which blocks nothing. The reports have exactly one job: to prove, sender by sender, that tightening the policy will not break legitimate mail. Once they prove it, the value is in acting on it.

Palisade's agent does the acting: it hosts your SPF, DKIM, and DMARC records, reads the aggregate reports continuously, and executes the walk to p=reject when the evidence supports it, so spoofed mail gets dropped by receivers instead of counted by dashboards.

Aggregate report volume scales with tenants: fifty client domains means fifty streams of daily XML from every receiver, and hand-parsing stops being a viable service model at about domain number three. The MSP play is one ingest pipeline and a per-client sender inventory, so onboarding a new client starts with two weeks of reports naming every shadow-IT mailer before you touch a record. Palisade runs that pipeline per client domain with unlimited report retention on paid plans, walks each domain to p=reject, and pushes alerts into ConnectWise, HaloPSA, or Autotask so a new unauthenticated source becomes a ticket. Pricing is per client domain with rates that improve as the portfolio grows, client email volume is not metered, and your own MSP domain is a free NFR domain to run it on first.