What DMARC Aggregate Reports Actually Tell You — and How to Turn Raw XML Into an Authorized Sender Inventory

DMARC aggregate reports arrive as XML attachments in a zipped file — which makes them effectively unreadable without dedicated tooling, and the organizations that most need to monitor DMARC reports (those with complicated sending infrastructure) are exactly the ones generating the most complex, hardest-to-parse reports

The previous articles on this site covered DMARC basics, deployment progression, reading XML reports, alignment failures, and DMARC for non-sending domains. This article addresses DMARC reporting infrastructure — specifically, what the aggregate report data can reveal when properly tooled, how to build a picture of your email ecosystem from it, and the third-party DMARC reporting services that make this accessible without custom tooling.

What's actually in a DMARC aggregate report

DMARC aggregate reports (rua=) contain per-IP, per-source authentication results — summarized over the reporting period (typically 24 hours). Each report entry shows:

• The IP address that sent messages claiming to be from your domain
• How many messages were sent from that IP
• Whether SPF passed or failed (and the result reason)
• Whether DKIM passed or failed (and which selector was used)
• Whether DMARC passed or failed (and whether it was SPF-aligned, DKIM-aligned, or both)
• The disposition applied (none, quarantine, reject)

A sample (simplified) report entry:

Source IP: 198.51.100.42
Count: 847
SPF: pass (aligned)
DKIM: pass (aligned, selector: s1)
DMARC: pass
Disposition: none

847 messages from this IP, all passing DMARC — this is a legitimate sending source you've authorized.

Another entry:

Source IP: 203.0.113.7
Count: 1,203
SPF: fail
DKIM: fail
DMARC: fail
Disposition: quarantine

1,203 messages failing all authentication, being quarantined — either spoofing attempts or a sending source you use but haven't configured for authentication.

The two types of findings in aggregate reports

Legitimate sending sources that need authentication fixing — the most common and actionable finding, especially during initial DMARC deployment. These are IPs you recognize as belonging to your marketing platform, CRM, help desk system, or third-party service — but SPF/DKIM isn't configured for them yet. The report reveals: "this IP is sending email as you, but isn't authenticated."

Unknown or hostile sources — IPs you don't recognize sending as your domain. These could be: compromised accounts being used to send spam, spoofing attempts targeting your brand, legitimate services you forgot about, or previous ESP/service providers whose contracts ended but whose infrastructure still has your domain configuration.

The key diagnostic question for each IP: "do I recognize this as a service I've authorized to send email on behalf of my domain?"

Building your authorized sender inventory from report data

DMARC aggregate reports are the most reliable way to discover all sources sending email as your domain — because they show what's actually happening, not what you've intended or documented.

Recommended process:

1. Enable DMARC at p=none (monitoring only) for at least 2-4 weeks before any enforcement
2. Collect aggregate reports during this period
3. For each unique source IP, resolve the IP to identify the sending service (reverse DNS, IP WHOIS)
4. Categorize: authorized-and-authenticated, authorized-but-unauthenticated, unauthorized
5. Fix authorized-but-unauthenticated sources (configure SPF/DKIM for each)
6. Document the authorized sender list
7. Only then consider moving to p=quarantine or p=reject

The most common deployment failure — moving to p=reject too quickly without first completing this inventory exercise — results in blocking legitimate email from services the team didn't know were sending on their behalf (transactional email services, HR tools, invoice systems, IT monitoring alerts).

Third-party DMARC reporting services

The XML reporting format is functional but not human-readable. Third-party DMARC reporting services parse the raw XML reports on your behalf, aggregate them across reporting periods and reporters, and present the data in dashboards:

Key features to look for in DMARC reporting tools:

• Source IP identification and vendor attribution (automatically recognizing Mailchimp's IPs, Google Workspace's IPs, Salesforce Marketing Cloud's IPs, etc.)
• DMARC pass/fail trends over time
• Alerting when new unknown sources appear
• Forensic report (ruf=) handling, with appropriate privacy filtering
• Subdomain breakdown (reports distinguish mail.example.com from example.com)

The market includes free tiers from services like Postmark, Mailtrap, EasyDMARC, Dmarcian, and others, as well as enterprise-grade platforms. For most small-to-medium organizations, free-tier reporting tools provide sufficient visibility.

Forensic reports (ruf=): individual message details

DMARC forensic reports (if enabled via ruf= in the DMARC record) send individual message reports when a message fails DMARC — including the actual message headers and sometimes body content.

Why many organizations don't enable forensic reports:

• Privacy concerns: receiving full or partial copies of failed messages (which may be from real users who made mistakes or were spoofed) raises data protection questions
• Volume: a domain being actively spoofed might generate millions of forensic reports per day, overwhelming the report mailbox
• Support inconsistency: not all receiving mail servers send forensic reports (Gmail doesn't, for example)

When forensic reports are useful: early in deployment, when you need to understand specific failure cases; when investigating a specific spoofing campaign; when debugging alignment issues that aggregate reports have identified but not explained in sufficient detail.

How to use the DMARC Lookup on sadiqbd.com

1. Verify your rua= is configured and pointing to an accessible mailbox — or a third-party reporting service's address — before expecting to receive reports
2. Check the reporting period tag (ri=) — the default is 86400 seconds (24 hours); some reporting services prefer different intervals
3. After publishing a DMARC record, check Search Console-equivalent tools to confirm reports are being received; 24-48 hours after first publish should see initial reports from major providers (Google, Yahoo, Microsoft)

Frequently Asked Questions

My DMARC aggregate report shows a p=none policy even though I've set p=quarantine — what's happening? The report shows the policy that was applied at the time the messages were received, not your current policy. Reports are sent by receiving mail servers after the fact — the policy shown reflects what was in your DMARC record when those messages were processed. If you recently changed your policy, reports for the period before the change will show the old policy, while reports for the period after will show the new one. This is expected behavior, not an error.

Is the DMARC Lookup free? Yes — completely free, no sign-up required.

Try the DMARC Lookup free at sadiqbd.com — check your domain's DMARC record, policy, and reporting configuration instantly.