DMARC Reporting: How to Monitor and Analyze Your Reports

DMARC reports are the foundation of email authentication visibility. They're what separate "I published a DMARC record" from "I actually understand what's happening with email on my domain." Without them, enforcement is guesswork — you'd be blocking email without knowing what you're blocking.

This guide explains what DMARC reports contain, how to make sense of them, and how to build a reporting workflow that scales.

Two Types of DMARC Reports

DMARC defines two reporting mechanisms, each serving a different purpose:

Aggregate reports (RUA) are the ones you'll rely on. Every major email provider sends them — Google, Microsoft, Yahoo, Apple, and hundreds of smaller providers. When you add a rua=mailto:... address to your DMARC record, these providers start sending you daily XML summaries of every email they received claiming to be from your domain.

Forensic reports (RUF) are more detailed but far less common. They contain information about individual messages that failed DMARC, including message headers. In theory, they're useful for investigating specific incidents. In practice, most major providers don't send them — Google doesn't, Microsoft doesn't. Privacy concerns and the volume of potential reports have made providers cautious. Don't build your reporting workflow around RUF.

Most organisations should start with RUA only. Add a ruf= address if you want forensic data from the providers that support it, but don't rely on it.

For a detailed comparison of both report types, see DMARC RUA and RUF explained.

Understanding Aggregate Reports

Aggregate reports arrive as XML files, usually gzipped, attached to emails sent to your rua address. Each report covers a time period (typically 24 hours, though some providers send reports covering shorter windows) and comes from a single receiving provider.

Here's what a report contains and why each piece matters:

Report metadata — The provider that generated the report, the date range covered, and your DMARC policy as they saw it during that period. If you changed your policy mid-day, you might see different reports reflecting different policies.

Source records — The core of the report. Each record represents a unique combination of sending IP address, SPF result, DKIM result, and DMARC disposition. For each combination, the report includes the message count — how many emails matched that specific pattern.

A typical report from Google for an active domain might contain 10–50 source records per day. A record showing 5,000 messages from a single IP with dkim=pass and disposition=none is probably your main ESP doing its job. A record showing 200 messages from an unknown IP with spf=fail and dkim=fail is someone trying to spoof your domain.

Authentication details — Each source record includes:

• SPF result: pass, fail, softfail, neutral, none, temperror, permerror
• DKIM result: pass, fail, none, temperror, permerror
• DMARC disposition: none (delivered normally), quarantine (sent to spam), reject (blocked)
• Alignment: whether the SPF and DKIM domains aligned with the From header

The raw XML is dense. A single day's report from Google can be hundreds of lines. Here's a simplified fragment of what one record looks like:

<record>
  <row>
    <source_ip>198.51.100.25</source_ip>
    <count>1247</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <auth_results>
    <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
    <spf><domain>yourdomain.com</domain><result>pass</result></spf>
  </auth_results>
</record>

This tells you: 1,247 emails came from IP 198.51.100.25, both DKIM and SPF passed and aligned, and the policy disposition was "none" (meaning the email was delivered normally).

For a full walkthrough of reading reports with real-world examples, see how to read DMARC reports.

What to Look For in Your Reports

Raw data is useless without a triage process. Here's what to focus on, in priority order:

1. Legitimate senders failing DMARC

This is the most actionable finding. If your aggregate reports show a known sender (your marketing platform, CRM, or helpdesk) with dkim=fail or disposition=quarantine, something is misconfigured.

Common causes:

• The service is signing with their own domain (d=sendgrid.net) instead of yours — fix by configuring custom DKIM
• The service was recently added and nobody updated SPF — add their sending IPs
• Someone changed your DNS records and accidentally removed a DKIM CNAME
• The service changed their sending infrastructure without notifying you

These need fixing before you can safely increase enforcement. A legitimate sender failing at p=none will have email quarantined or rejected once you enforce.

2. Unknown senders passing DMARC

This is more subtle but equally important. If an IP you don't recognise is sending email as your domain and passing authentication, it could be:

• A service someone on your team set up without telling you (common with sales tools, event platforms, and automated notifications)
• An overly permissive SPF record that authorises IPs you didn't intend to (e.g., including an entire cloud provider's IP range via include:)
• A compromised account on a legitimate service you use

Investigate these. If they're authorised, document them. If they're not, tighten your SPF record.

3. High-volume unauthorised senders

Large numbers of messages from unknown IPs that fail both SPF and DKIM — this is spoofing. At p=none, these emails get delivered. At p=reject, they're blocked. This is exactly what enforcement is designed to stop.

You don't need to fix these. They're someone else's infrastructure impersonating your domain. Enforcement handles them automatically.

4. Alignment failures

Sometimes SPF and DKIM both pass, but DMARC still fails because neither aligns with the From header. This shows up in reports as spf=pass and dkim=pass in the authentication results, but disposition=quarantine or disposition=reject in the policy section.

This is an alignment configuration issue, not an authentication failure. The fix is usually configuring custom DKIM on the sending service so it signs with your domain.

Sending Reports to Multiple Addresses

You can specify multiple RUA destinations by separating them with commas:

rua=mailto:dmarc@yourdomain.com,mailto:dmarc@thirdparty.com

This is useful if you want reports going to both your internal team and a DMARC reporting service. Each destination receives the same reports independently.

Cross-domain reporting requires authorisation. If you send reports to an address on a different domain (e.g., rua=mailto:reports@dmarcservice.com), the receiving domain must publish a special DNS record authorising it. Without this record, providers will skip that destination — they won't send your reports to a domain that hasn't opted in.

The authorisation record is a TXT record at yourdomain.com._report._dmarc.dmarcservice.com with the value v=DMARC1. The receiving domain (the reporting service) publishes this, not you. Most DMARC reporting services handle this automatically.

Practical tip: Don't send aggregate reports to a personal inbox. At any meaningful email volume, you'll receive dozens of XML files per day. Use a dedicated mailbox, an email alias with filtering rules, or (ideally) a DMARC reporting service that parses and visualises the data for you.

Full details on multi-destination reporting and the authorisation mechanism at DMARC RUA: how to send reports to multiple addresses.

Managing Report Volume

The volume problem is real. A domain that sends 50,000 emails per day might receive aggregate reports from 30+ different providers daily. Each is a gzipped XML file ranging from a few kilobytes to several megabytes.

If you're parsing reports manually, you'll drown. Even if you're using a reporting service, it helps to understand the volume patterns so you can set up your workflow efficiently.

Strategies for managing volume:

Use a DMARC reporting service. This is the most practical solution for most organisations. Services like Postmark's free DMARC tool, or paid platforms, automatically receive your reports, parse the XML, aggregate the data across providers, and present it as dashboards and alerts. You get human-readable summaries instead of raw XML.

Consolidate RUA addresses. If you're sending reports to multiple internal addresses "just in case," consolidate to one. Every additional rua destination multiplies the volume.

Focus on failures first. Most report data shows passing results from legitimate senders — that's good news, but it's not actionable. Sort by failures. A report showing 50 source records where 48 pass and 2 fail means you only need to look at 2 records.

Set up alerts, not reviews. Once your enforcement is stable, you don't need to read every report. Set up alerts for: new failing sources, sudden drops in pass rates, new high-volume senders. Review the full data periodically (weekly or monthly), but let alerts catch the urgent issues.

See how to manage DMARC reports when you're overwhelmed by volume for more strategies and tooling recommendations.

DMARC Monitoring Beyond Reports

Aggregate reports are backward-looking — they tell you what happened yesterday. Monitoring fills the gaps by giving you real-time or near-real-time awareness of your DMARC posture.

A good monitoring setup covers:

Record changes. If someone modifies your DMARC record — intentionally or by accident — you should know immediately. A policy downgrade from p=reject to p=none (perhaps during a debugging session that was never reverted) leaves your domain unprotected. A deleted record is worse.

Authentication pass rate trends. A healthy domain at p=reject should see 95%+ of legitimate email passing DMARC. If that rate drops suddenly — say from 98% to 80% — something changed. Maybe a sender rotated their DKIM keys without notifying you, or your SPF record hit the 10-lookup limit after someone added a new include.

New senders. When a new IP address starts sending email as your domain, you want to know. It could be a new tool someone on your team set up, or it could be a spoofing attempt. Either way, it needs investigation.

DNS health. DMARC depends on SPF and DKIM, which depend on DNS. If your SPF record has a syntax error, or your DKIM TXT record is missing, DMARC fails regardless of how well your policy is configured. Monitoring should check the full authentication chain, not just the DMARC record.

See what is DMARC monitoring and why it matters for a deeper look at monitoring strategies and tools.

Check Your Reporting Setup

Use our free DMARC record checker to verify your RUA and RUF destinations are configured correctly, confirm that your rua domain authorisation is in place, and validate that your full reporting setup is ready to receive data.