DMARC Aggregate Reports

Email Authentication

You set up DMARC, added a rua tag to receive reports, and now XML files are arriving in your inbox. They're dense, hard to read, and easy to ignore. But these aggregate reports are the only way to see who's sending email as your domain — and whether authentication is working.

Here's how to read them and what to do with what you find.

What DMARC Aggregate Reports Are

When you publish a DMARC record with a rua tag (like rua=mailto:[email protected]), receiving email servers send you daily reports summarizing how they handled messages from your domain.

Each report contains:

Who sent the report — The receiving mail server (Gmail, Yahoo, Microsoft, etc.)
The time period covered — Usually 24 hours
Source IP addresses — Every IP that sent email claiming to be from your domain
Authentication results — Whether each source passed or failed SPF, DKIM, and DMARC alignment
What action was taken — Whether the message was delivered, quarantined, or rejected based on your DMARC policy

These reports are aggregate — they don't contain individual email content or recipient addresses. They show patterns, not specific messages.

Understanding the XML Format

DMARC reports arrive as gzipped XML files. Here's what the key sections mean:

Report Metadata

The report header tells you who generated it and the time period:

org_name — The organization that sent the report (e.g., "google.com")
date_range — Start and end timestamps in Unix epoch format

Policy Published

This section mirrors your DMARC record as the receiving server saw it:

p — Your policy (none, quarantine, reject)
sp — Subdomain policy (if set)
pct — Percentage of messages the policy applies to

Records

Each record block represents a group of messages from a single source IP with the same authentication results:

Field	What It Tells You
source_ip	The IP address that sent the email
count	How many messages came from this IP
disposition	What happened: none, quarantine, or reject
dkim (result)	pass or fail for DKIM
spf (result)	pass or fail for SPF
header_from	The domain in the From header

How to Read a Report — Step by Step

Identify the source IPs

Each record block has a source_ip. Look up these IPs to determine what service is sending email from your domain. Use a reverse DNS lookup or IP reputation tool.

Check authentication results

For each source, check whether SPF and DKIM passed. Both should pass for legitimate senders. If one fails, there's a configuration problem.

Look for unauthorized senders

Any IP you don't recognize sending email as your domain is a potential threat. It could be a forwarding service, a forgotten tool, or someone spoofing your domain.

Check alignment

DMARC requires alignment — the domain in SPF or DKIM must match the From domain. A source might pass SPF but fail alignment if the envelope sender uses a different domain.

Review the volume

The count field shows how many messages came from each source. High volumes from unknown IPs are more concerning than a single message.

Monitor authentication automatically

Check your SPF, DKIM, and DMARC configuration daily. Get alerts when authentication fails instead of digging through XML reports.

Common Patterns and What They Mean

Legitimate sender failing SPF

You see a known service (like your CRM or support tool) with SPF failing. This usually means the service isn't included in your SPF record.

Fix: Add the service's include: value to your SPF record. Check your ESP's documentation for the correct include.

DKIM passing but SPF failing

Common with email forwarding. When an email is forwarded, the sending IP changes (breaking SPF), but the DKIM signature stays intact.

What to do: This is expected behavior. As long as DKIM passes and aligns, DMARC will pass. This is exactly why having both SPF and DKIM configured matters.

Unknown IPs with both failing

These are either spoofing attempts or services you've forgotten about. Check:

Did someone on your team start using a new tool that sends email?
Is this a legitimate forwarding service?
If neither, it's likely spoofing — your DMARC policy is working.

Everything passing but low volume

If you see very few messages in reports, you may not be sending enough email to the reporting provider, or your rua address might not be receiving all reports correctly.

Tools That Make Reports Readable

Reading raw XML is painful at scale. These approaches help:

Free Options

Google Postmaster Tools — Shows aggregate authentication data for Gmail specifically
DMARC XML-to-Human converters — Various free online tools parse individual XML files into readable tables
Spreadsheet parsing — Extract the XML data into a spreadsheet for manual analysis

Paid DMARC Reporting Services

If you receive many reports (common for high-volume senders), dedicated services aggregate, visualize, and alert on DMARC data:

They combine reports from all receiving servers into a single dashboard
They identify unauthorized senders automatically
They track authentication trends over time
They alert you when new sources appear or failures spike

Using Reports to Strengthen Your DMARC Policy

DMARC aggregate reports are essential for safely progressing your policy from p=none to p=quarantine to p=reject.

Policy Stage	What to Check in Reports
p=none (monitoring)	Identify all legitimate senders, fix authentication failures
p=quarantine	Verify no legitimate email is being quarantined, monitor disposition
p=reject	Confirm only unauthorized senders are being rejected

The Process

Start at p=none — Collect reports for 2–4 weeks to see all email sources
Fix authentication — Ensure every legitimate sender passes SPF or DKIM with alignment
Move to p=quarantine — Start with pct=10 to quarantine only 10% of failing messages
Increase gradually — Raise the percentage as you confirm no legitimate mail is affected
Move to p=reject — The final state where unauthorized senders are blocked entirely

Common Mistakes

Ignoring reports entirely

The most common mistake. If you set rua but never read the reports, you won't catch authentication failures or spoofing until deliverability suffers.

Not adding all senders before tightening policy

Moving to p=reject before confirming all legitimate senders pass authentication means you'll reject your own email. Always verify with reports first.

Using a mailbox you don't monitor

If your rua address goes to a shared inbox that nobody checks, the reports are useless. Either monitor the inbox or use a DMARC reporting service.

How to Read DMARC Aggregate Reports (RUA): A Practical Guide