How DMARC Aggregate Reports Catch Sending Problems Before They Become Outages

What Is a DMARC Aggregate Report and What Does It Contain?

A DMARC aggregate report is an XML file that receiving mail servers send back to the domain owner once per day. It is the only regular signal that tells you what the rest of the internet sees when your domain sends email. Without a tool like DMARCFlow parsing these reports, the data stays locked in unreadable XML files while sending problems accumulate undetected.

The report covers a 24-hour window and includes every message that passed or failed DMARC checks at a given receiving server. Each entry contains:

• The source IP address that sent the message
• The hello name or reverse DNS of that IP
• The SPF result for the sending IP (pass, fail, softfail, neutral, or none)
• The DKIM result for the message (pass, fail, or none)
• The DMARC alignment result (aligned or not aligned with your From domain)
• The disposition applied to the message (none, quarantine, or reject)
• A comment field sometimes populated by the receiver

The alignment field is the part that matters most. A message can have SPF pass and DKIM pass individually but still fail DMARC if neither authenticated identifier aligns with the domain shown in the From header. That distinction is only visible in aggregate reports.

Why Most Organizations Never See the Problems in Their Reports

Two reasons explain why aggregate reports go ignored at most organizations.

First, they arrive as XML attachments. The file format is machine-readable, not human-readable. You cannot open it in a browser and make sense of it. Parsing DMARC XML requires either a specialized tool or custom scripting, and most email administrators have neither configured.

Second, even if you could read the file, the data volume makes manual review impractical. A medium-sized organization sending to Gmail, Microsoft, Apple, and a dozen other receivers gets a separate report from each receiver every day. That is dozens of XML files per week containing thousands of rows of data. No human is going to read all of that consistently.

The result is predictable. Organizations set DMARC to p=none, get their first XML report, cannot read it, and move on. The reports sit in an inbox until someone deletes them. Meanwhile, senders keep sending, problems keep accumulating, and the organization finds out something is wrong only when email stops working.

Five Problems Only DMARC Aggregate Reports Reveal

Aggregate reports are the only place where these five problems become visible.

1. Subdomains sending mail without SPF coverage

A subdomain like newsletter.example.com sends email but nobody added it to the SPF record. From the sender's side, everything looks normal. The receiving server accepts the mail. But DMARC aggregate reports show every message from that subdomain as an SPF failure. If the domain later moves to p=reject, all that mail starts bouncing with no warning.

2. Third-party services not covered by SPF or DKIM

Marketing platforms, billing systems, and customer communication tools often send on your domain's behalf. If they are not in your SPF record and do not sign with your DKIM key, every message fails DMARC. Aggregate reports show which ESPs are failing and how much mail is affected.

3. Unexpected sending IPs from compromised credentials or shadow IT

A compromised account or an unauthorized mailing system starts sending from an IP not on your SPF record. It is not your ESP, and it has no business sending as your domain. It shows up in aggregate reports as an unknown source. Without monitoring, you find out when recipients report your domain as a spam source.

4. DKIM alignment failures

Some ESPs sign with their own domain, not yours. DKIM passes, but the signature domain does not match the From header, so DMARC alignment fails. This is a common misconfiguration with SendGrid, Mailgun, and similar services. Aggregate reports show which selectors are failing and whether the problem is alignment versus a pure authentication issue.

5. SPF alignment failures

Some mail systems use a generic relay domain as the MAIL FROM while the From header shows your actual domain. SPF passes on the relay domain, but DMARC alignment fails because the two domains do not match. The report distinguishes between SPF failures and alignment failures, which is the only way to tell these apart.

Real-World Example: The Subdomain That Silent-Failed

One DMARC practitioner who writes DMARC guides for a living recently caught their own monitoring gap through aggregate reports. A subdomain was sending mail without an SPF record. The sending application showed no errors, delivered mail normally from the sender's perspective, and never alerted anyone. The only signal that something was wrong came from the daily aggregate reports, which showed every message from that subdomain as an SPF failure.

The lesson is not that this practitioner was careless. The lesson is that expertise does not protect against this problem. Knowing DMARC well does not mean you are actively reviewing your own reports. The only reliable protection is consistent automated monitoring that alerts on new subdomains, new sending sources, and authentication failures before they cascade into a full outage.

How to Read a DMARC Aggregate Report Manually

If you receive a DMARC report and want to understand it before building automation, here is what the key fields look like.

The root of the report file contains metadata: your domain, the receiver's domain, the report ID, and the date range. Then comes the record block for each sending event:

  
    203.0.113.45
    12
    
      none
      pass
      pass
    
  
  
    
      pass
      example.com
      yes
    
    
      pass
      example.com
      yes
    
  

In this example, 12 messages from IP 203.0.113.45 were evaluated. SPF and DKIM both passed, alignment was confirmed, and the policy applied was none. This is a clean result.

Now compare a failing entry:

  
    198.51.100.22
    3
    
      reject
      fail
      fail
    
  
  
    
      fail
      mail.thirdpartyplatform.com
      no
    
    
      pass
      mail.thirdpartyplatform.com
      no
    
  

Three messages from an IP at a third-party platform were rejected. DKIM failed because the signature domain did not match the From domain. SPF passed but alignment failed because the MAIL FROM domain did not match the From domain. The receiver applied the reject policy. This is exactly the kind of entry that tells you a third-party sender is not properly configured for your domain.

Manual parsing like this proves two things: the data is there, and human review at scale is not a realistic solution. You need automation.

Why Automated Monitoring Catches Problems That Manual Review Misses

Automated monitoring parses every report the moment it arrives. It tracks every source IP, every sending subdomain, every DKIM selector, and every SPF result across all receiving domains. When something changes, it alerts you. When something fails for the first time, it flags it.

The difference between automated and manual is not just speed. It is coverage. A human reviewing reports manually will check the most obvious entries, spot-check the big numbers, and miss the small anomalies that indicate early-stage problems. Automation checks everything, every time, without fatigue.

Specifically, automated monitoring catches these things that manual review misses:

• A new subdomain that started sending in the last 24 hours
• An existing subdomain whose SPF record stopped working because someone changed the DNS
• A third-party ESP that changed its sending IP range without warning
• A slow drift in DKIM pass rates that precedes a larger authentication problem
• Alignment failures that affect only a small percentage of traffic but indicate a misconfiguration that will eventually cause widespread failures

How DMARCFlow Monitors Aggregate Reports for You

DMARCFlow is purpose-built for this. It connects to your DMARC reporting address, parses every incoming RUA report, and transforms the XML data into actionable alerts. When a subdomain starts sending without SPF coverage, DMARCFlow flags it. When a new sending IP appears that is not on your SPF record, you get an alert. When your DKIM pass rate drops, it surfaces the specific selectors affected.

The monitoring covers both SPF and DKIM alignment checks. It tracks authentication pass rates over time so you can see whether your domain is improving or degrading. It alerts on new senders and on lookalike domains that may indicate spoofing attempts against your brand.

The practical benefit over manual review is straightforward: you stop finding out about problems when email stops working. You find out when the first message fails, while there is still time to fix the configuration before it becomes an incident.

For teams already using Slack, Jira, or Microsoft Teams, DMARCFlow can push alerts directly into those tools via webhook. That means the first person who sees a new sending source or an authentication failure is whoever handles email operations, not whoever happens to be monitoring an inbox full of XML attachments.

FAQ

How often do you receive DMARC aggregate reports?

Most major email receivers send aggregate reports once per day. Gmail, Microsoft, Yahoo, and Apple all send daily reports. Some receivers send more frequently or bundle multiple days into a single report. The frequency depends entirely on the receiver's policy, not on your DMARC record.

What happens if you ignore your DMARC reports?

Ignoring DMARC reports means you will not know about sending problems until they cause an incident. Subdomains that are misconfigured will keep sending failing email. Third-party ESPs that are not properly authenticated will accumulate rejections. Compromised credentials that are sending spam will damage your domain reputation. In the worst case, your domain gets added to blocklists and all outbound email, including legitimate mail, starts bouncing or landing in spam.

How do you start receiving DMARC aggregate reports?

Add a rua tag to your DMARC DNS record with an email address where reports should be delivered. The tag looks like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace the email address with a dedicated inbox or a DMARC monitoring service. Without the rua tag, no aggregate reports are generated or delivered.

What is the difference between aggregate reports and forensic reports?

Aggregate reports (RUA) are daily summaries covering thousands of messages. They show trends, source IPs, and overall pass/fail rates. Forensic reports (RUF) are real-time alerts for individual message failures. Forensic reports are useful but generate significant volume; most organizations prioritize aggregate report monitoring first.