Definition
A DMARC aggregate report is a structured XML summary that receiving mail servers send back to a domain owner, showing how email claiming to come from that domain performed against SPF and DKIM checks. The report is delivered to the address defined in the DMARC record's rua= tag, typically once per day. Aggregate reports are the primary way a domain owner learns which servers are sending on their behalf and whether those messages are passing authentication.
How It Works
When you publish a DMARC record with an rua= tag, every participating receiving server that processes mail from your domain compiles daily statistics. Each report is a gzipped XML file that lists the sending IP addresses, the number of messages observed, and the disposition result (pass, fail, or none) for both SPF and DKIM.
The key fields in an aggregate report include:
- The reporting organisation and date range covered.
- The
From:domain being evaluated. - Each source IP address and the count of messages from it.
- The SPF and DKIM authentication results per IP.
- The overall DMARC disposition (delivered, quarantined, or rejected).
Because the raw XML is dense and not designed for human reading, most teams parse it with a DMARC monitoring tool that visualises trends, flags misconfigured sources, and surfaces newly authorised senders.
Why It Matters
Aggregate reports are the only systematic feedback a sender receives about authentication failures across the entire mailbox-provider ecosystem. Without them, a domain owner has no way to know that a legitimate email marketing platform or an employee's CRM tool is sending mail that fails alignment and is being silently routed to spam.
Regularly reviewing aggregate reports lets teams:
- Detect spoofing attempts against the domain before they damage sender reputation.
- Confirm that third-party senders are correctly authenticating with your domain.
- Move safely from a
p=nonemonitoring policy top=quarantineorp=reject.
The practical workflow is to publish a monitor-only policy, let reports accumulate for a few weeks, correct every failing legitimate source, and only then tighten enforcement.
Example
A retailer publishes v=DMARC1; p=none; rua=mailto:dmarc@retailer.com. Over the next week, aggregate reports arrive from Gmail, Microsoft, and Yahoo. The reports show 98% of messages from the company's marketing platform passing DKIM, but a small stream from an unfamiliar IP failing SPF. Investigation reveals a forgotten invoicing tool. The team configures that tool to authenticate properly before switching the domain to p=reject.
Was this useful?
Related Glossary Terms
Abuse Complaint
An abuse complaint is a report from a recipient who marks an email as spam, which negatively affects sender reputation and deliverability.
Alt Text
Alt text is the written alternative to an image in an email, displayed when images are blocked, slow to load, or consumed by screen readers.
AOL Mail for Email Marketers
AOL Mail is a legacy email provider with specific deliverability requirements and rendering quirks, now operating as part of the Yahoo+AOL network under shared infrastructure.
Email Authentication Protocols
Email authentication protocols are technical standards that verify the identity of an email sender, helping mailbox providers distinguish legitimate mail from spam and phishing.
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Bounce Management
Bounce management is the process of handling emails that are rejected by mailbox providers, including classification, removal of bad addresses and protection of sender reputation.
Frequently Asked Questions
Most mailbox providers send aggregate reports once every 24 hours, though the timing varies by provider and can be delayed by several hours. Some smaller providers send them less frequently or only when traffic exceeds a minimum volume.
The `rua=` tag specifies where aggregate reports are delivered; these are daily XML summaries of all traffic. The `ruf=` tag specifies where forensic reports are delivered; those contain detailed message-level data about individual authentication failures. Aggregate reports are much more commonly used because they carry fewer privacy concerns.
Aggregate reports follow a standardised XML schema defined in RFC 7489 so that any provider's report can be parsed consistently by third-party tools. The format is intentionally machine-readable rather than human-friendly, which is why visualisation tools are recommended.
Not necessarily, but many providers only generate reports when they process a meaningful number of messages from a domain. Low-volume domains may receive reports sporadically. Even sparse reports are still worth reviewing for unexpected sources.