A DMARC aggregate report is a structured data file sent by receiving mail servers to domain owners, summarizing how email sent from their domain performed against DMARC authentication checks. It tells you which IP addresses are sending mail on behalf of your domain, whether those messages passed SPF and DKIM alignment, and how many were delivered, quarantined, or rejected. These reports are the foundation of any serious email authentication monitoring strategy, and the sections below break down exactly what they contain, how they work, and what to do with them.
What information does a DMARC aggregate report contain?
A DMARC aggregate report contains a summary of email authentication results for all messages received from a given domain over a defined reporting period, typically 24 hours. It includes the sending IP addresses, the volume of messages per IP, the SPF and DKIM alignment results, and the DMARC policy that was applied to each message group.
More specifically, each report is structured around individual records, and each record covers a distinct combination of sending IP, header-from domain, and authentication outcome. Within each record, you can see:
- Source IP address of the sending server
- Message count for that IP during the reporting period
- DMARC policy disposition applied (none, quarantine, or reject)
- SPF result and whether it aligned with the From domain
- DKIM result and whether it aligned with the From domain
- Reporting organization and its policy override reasons, if any
This combination of data gives domain owners a clear picture of who is sending email using their domain and whether that email is authenticated correctly. It is particularly valuable for spotting unauthorized senders, misconfigured third-party platforms, and forwarding scenarios that break authentication.
How does DMARC aggregate reporting actually work?
DMARC aggregate reporting works by having receiving mail servers automatically compile authentication data for all messages they receive claiming to be from your domain, then send that compiled data to a reporting address you specify in your DMARC DNS record. The process is fully automated and requires no manual action once the DMARC policy is published.
When you publish a DMARC record, you include an rua tag that points to one or more email addresses where aggregate reports should be delivered. Participating mailbox providers, including Gmail, Microsoft, and Yahoo, collect authentication data throughout the day and send reports at the end of each reporting cycle, usually every 24 hours.
The report arrives as an XML file, often compressed as a .zip or .gz attachment. Each report covers a specific time window and is scoped to a single reporting organization. If your domain receives mail at multiple large providers, you will receive separate reports from each one, giving you a distributed but comprehensive view of your sending landscape.
What’s the difference between aggregate reports and forensic reports?
The key difference is scope and detail. Aggregate reports summarize authentication outcomes across all messages from a domain over a time period, with no individual message content. Forensic reports, also called failure reports, are generated per message and include headers and sometimes partial content from individual emails that failed authentication.
Aggregate reports are sent using the rua tag in your DMARC record. Forensic reports are sent using the ruf tag. Because forensic reports can contain sensitive message data, many large mailbox providers have stopped sending them due to privacy concerns. In 2026, aggregate reports remain the primary and most reliably delivered source of DMARC feedback.
For most practical purposes, aggregate reports give you everything you need to monitor your domain’s authentication health. Forensic reports can be useful for diagnosing specific failure cases, but you should not depend on them as a consistent data source given how inconsistently they are delivered.
Why are DMARC aggregate reports written in XML?
DMARC aggregate reports are written in XML because the DMARC specification, defined in RFC 7489, mandates a standardized machine-readable format that any compliant receiver can generate and any compliant tool can parse. XML provides a consistent, structured schema that works across different mail systems and reporting organizations without requiring custom formatting.
The practical implication is that raw aggregate reports are not designed to be read directly by humans. A raw XML file full of IP addresses, timestamp integers, and nested policy tags is difficult to interpret without tooling. This is why most organizations use a DMARC reporting platform or visualization tool to parse and display the data in a readable format.
The standardized XML schema also means that the same report structure applies whether the report comes from Google, Microsoft, Apple, or a regional provider. That consistency makes it possible to aggregate data from multiple sources into a unified view of your domain’s authentication performance.
What do DMARC aggregate report failures actually mean?
A failure in a DMARC aggregate report means that a message claiming to be from your domain did not pass DMARC authentication. This happens when a message fails both SPF alignment and DKIM alignment simultaneously. A failure does not necessarily indicate malicious activity; it often points to a legitimate sending source that has not been properly configured.
Common causes of DMARC failures
Failures frequently appear when a third-party platform sends email on your behalf without being authorized in your SPF record or without signing messages with a DKIM key aligned to your domain. Marketing platforms, CRMs, transactional email services, and automated notification systems are common sources of these misconfigurations.
When failures indicate unauthorized sending
Failures can also indicate that someone is spoofing your domain, sending phishing or spam messages that impersonate your brand. If you see a high volume of failures from IP addresses you do not recognize and have never authorized, that is a signal worth investigating. Cross-referencing the IP against known sending infrastructure and threat intelligence sources can help distinguish spoofing from misconfiguration.
The DMARC policy applied to failing messages depends on what you have published. Under a none policy, failed messages are delivered and only reported. Under quarantine or reject, receiving servers take action. Monitoring failures under a none policy before moving to enforcement is the recommended approach, precisely because failures are not always malicious.
How should you act on what your DMARC aggregate reports show?
Acting on DMARC aggregate report data means identifying every IP address sending mail from your domain, confirming whether each one is authorized, fixing authentication gaps for legitimate senders, and progressively moving your DMARC policy toward enforcement once your legitimate sending streams are fully authenticated.
A practical workflow looks like this:
- Inventory your sending sources by reviewing all IP addresses appearing in reports and matching them against your known email service providers and internal mail infrastructure.
- Fix SPF and DKIM configuration for any legitimate sender that is generating failures, either by adding them to your SPF record or by configuring DKIM signing through their platform.
- Investigate unknown IPs that are generating failures and cannot be traced to authorized senders, as these may represent spoofing attempts or forgotten sending systems.
- Move from none to quarantine once the volume of unexplained failures drops to a level you are comfortable with, and monitor for any new legitimate senders that surface.
- Move from quarantine to reject once you are confident your authorized sending infrastructure is fully covered and authenticated.
Consistency matters here. DMARC aggregate reports are most valuable when reviewed regularly, not as a one-time exercise. Authentication configurations change as organizations add new tools, switch providers, or modify their sending infrastructure, and each change can introduce new failures that need to be addressed before moving to stricter enforcement.
How Email Industries helps with DMARC monitoring and authentication
Making sense of DMARC aggregate reports, and acting on them effectively, requires both the right tooling and the right expertise. That is exactly where we come in. At Email Industries, we help organizations at every stage of their DMARC journey, from initial setup through full enforcement and ongoing monitoring.
Here is what we bring to the table:
- DMARC record setup and policy configuration tailored to your sending infrastructure and risk profile
- Aggregate report analysis to identify unauthorized senders, misconfigured platforms, and authentication gaps
- SPF and DKIM alignment support across all your sending sources, including third-party platforms
- Guided policy enforcement to help you move safely from none to quarantine to reject without disrupting legitimate mail flow
- Ongoing monitoring to catch new authentication failures before they become deliverability or brand protection problems
Our email deliverability services are built around solving exactly these kinds of complex authentication challenges, and our Deliverability Assurance Packages give you structured, ongoing support so your domain stays protected as your sending landscape evolves. If you are ready to get clarity on what your DMARC reports are telling you and take meaningful action on them, we would love to help. Contact us to get started.
Related Articles
- What is the difference between a managed and self-service email platform migration?
- What authentication records do you need before domain warmup?
- What is the difference between email platform migration and IP warmup?
- How do you migrate to a new email platform without losing deliverability?
- What sending frequency is recommended during domain warmup?
- How do you monitor deliverability during an IP warming campaign?
- How do you recover from a failed IP warming attempt?
- What are the signs that your IP warming strategy is working?
- How do agencies handle email consent management?
- What is the difference between email agencies and marketing automation platforms?
- Which industries benefit most from email deliverability agencies?
- Why is email authentication critical for delivery success?
- How do delivery agencies handle international email regulations?
- How do email delivery agencies handle crisis situations?
- How do deliverability experts fix sender reputation issues?
