DMARC Aggregate Reports: How to Read and Use Them

If you have DMARC configured with a rua= email address, you are receiving XML reports from inbox providers. These reports arrive daily. They look like walls of angle brackets and numbers. Most marketers ignore them entirely.

That is a mistake. DMARC aggregate reports are the most complete picture available of who is sending email using your domain name, whether those sends are passing authentication, and whether anyone is spoofing your domain for malicious purposes.

What DMARC Aggregate Reports Are

When you publish a DMARC record with a rua= tag, you are asking inbox providers to send you data about email that arrives claiming to be from your domain.

Here is what the rua= tag looks like in a DMARC record:

`v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`

The rua address (Reporting URI for Aggregate) is where Gmail, Outlook, Yahoo, and other participating providers send daily XML files. Each file covers 24 hours. It reports every IP address that sent email using your domain name during that day, along with authentication pass/fail results and message counts.

Aggregate reports are different from forensic reports (ruf=). Aggregate reports show summary statistics: how many messages, which IPs, and pass or fail counts. Forensic reports show details of individual failed messages. Most providers now send only aggregate reports due to privacy considerations, so the rua= reports are what you will primarily receive.

Why You Should Read Your DMARC Reports

DMARC reports answer questions your ESP dashboard cannot.

Are all your legitimate sending sources passing authentication? If your CRM sends email using your domain and is not in your SPF record, your DMARC reports show this immediately. The CRM’s IP appears in the report with SPF=fail.

Is anyone spoofing your domain? If a phishing campaign is sending email claiming to be from your domain, those sends show up in your DMARC reports with authentication failures from IP addresses you do not recognise.

Do your authentication records work across all sending paths? You might think your authentication is perfectly configured. DMARC reports show the actual pass rates from real sends. A pass rate of 85% means 15% of your legitimate email is failing authentication often because a sending tool was added or updated without updating the authentication records.

Without reading these reports, you are operating blind on all three of these questions.

The Structure of a DMARC Report

A DMARC aggregate report is an XML file. Here is a simplified version of what one looks like:

<report_metadata>

<org_name>Google</org_name>

<date_range>

</date_range>

</report_metadata>

<policy_published>

<domain>yourdomain.com</domain>

</policy_published>

<row>

<source_ip>198.51.100.5</source_ip>

<policy_evaluated>

</policy_evaluated>

</row>

<auth_results>

<dkim>

<domain>yourdomain.com</domain>

</dkim>

<spf>

<domain>mail.yourdomain.com</domain>

</spf>

</auth_results>

</record>

</feedback>

This looks complex, but the parts you need to understand are limited.

The Key Fields to Focus On:

org_name: which inbox provider sent this report (Google, Outlook, Yahoo).

source_ip :p the IP address that sent email claiming to be from your domain during this period.

count:t how many messages were sent from that IP during the reporting period.

dkim: under policy_evaluate, whether the DKIM check passed or failed for this source IP.

spf: under policy_evaluated, whether the SPF check passed or failed for this source IP.

disposition: what DMARC did with messages that failed. “none” means the email was delivered despite the failure (you are in monitoring mode). “quarantine” means failed messages went to spam. “reject” means they were rejected.

The auth_results section shows the underlying details: which DKIM selector was used, which domain the SPF check was against. This helps you identify which sending tool corresponds to which IP.

What Good DMARC Data Looks Like

A healthy DMARC report for a well-configured sending programme looks like this:

Every IP address in the report corresponds to a tool in your sending stack that you recognise. Your ESP’s IPs, your transactional email provider’s IPs, your CRM’s outbound email IPs.

Every recognised IP shows DKIM=pass and SPF=pass under policy_evaluated.

Message counts for each IP roughly match your expected sending volumes. Your primary ESP handles most of the volume. Meanwhile, your CRM manages a smaller portion. At the same time, your transactional ESP delivers product notifications.

No unrecognised IPs appear, or if they do, they appear with very low message counts that might reflect misdirected email or forwarding chains.

If your DMARC data consistently looks like this, your authentication is working correctly across all sending paths.

What Problems DMARC Reports Reveal

Problem 1: A Recognised IP Failing Authentication

You see your ESP’s IP address in the report, with a high message count, but DKIM=fail or SPF=fail. This means your ESP is sending email using your domain but failing one of the authentication checks.

Common causes: your ESP is signing with their default DKIM key rather than a custom key for your domain (DMARC alignment failure), or your ESP’s sending IPs are not included in your SPF record.

Action: Check your ESP’s authentication configuration. For DKIM alignment, enable custom domain signing in your ESP settings. For SPF, add your ESP’s IP range or include statement to your SPF record.

Problem 2: Unrecognised IPs with High Volume

You see an IP address you do not recognise sending thousands of emails per day using your domain name.

Common causes: a marketing tool or integration you forgot to account for, a tool added by a colleague without authentication setup, or a phishing campaign spoofing your domain.

Action: Look up the IP address (use ipinfo.io or similar) to identify what organisation owns it. If it is a legitimate service you use, add it to your authentication records. If it is unrecognised and sending high volumes, you may be facing a spoofing attack. Progress your DMARC policy from p=none to p=quarantine or p=reject to block these unauthorised sends.

Problem 3: Low Overall Pass Rate

You see that across all sources, your overall DKIM or SPF pass rate is 75%. One quarter of your sends are failing authentication.

Common causes: multiple sending tools in your stack, some of which are configured correctly and some of which are not. The aggregate is dragged down by the failing tools.

Action: Identify which IPs are generating the failures (they appear in the report with dkim=fail or spf=fail). Trace those IPs back to the tools they belong to. Fix the authentication configuration for those tools.

Problem 4: A Source You Did Not Know Was Sending

Your DMARC report shows sends from an IP belonging to a third-party service with a modest but consistent volume. You investigate and discover a tool in your stack a support platform, a webinar service, or an e-commerce plugin sends notification emails using your domain name as the From address.

This is extremely common. Many tools send email on your behalf without clearly surfacing this in their setup process.

Action: Review whether this tool should be sending email with your domain in the From address. If yes, add it to your authentication records. If no, update the tool’s settings to use a different From address or From domain.

Tools That Make DMARC Reports Readable

The XML format is not designed for human reading. Several tools parse DMARC reports and present the data in a readable dashboard.

DMARC Digests free tool for small volumes. It parses incoming DMARC report emails and presents a simplified summary in your browser.

Dmarcian the most widely used DMARC analytics platform. Free tier for up to 10,000 messages per month. Paid tiers for higher volumes. Provides source identification, historical trends, and specific guidance on failing sources.

Google Admin Toolbox is not a report parser, but Google’s own DMARC setup and verification tools at toolbox.googleapps.com/apps/checkmx are useful for diagnosing specific authentication issues.

EasyDMARC is another popular hosted DMARC analytics platform with a clean interface and source identification features.

For most email programmes, a free tier on Dmarcian or DMARC Digests is sufficient to make DMARC data actionable without manual XML parsing.

Acting on DMARC Report Findings

Reading DMARC reports is only valuable if you act on what they show.

Monthly review cadence. Set a calendar event to review DMARC data monthly. More frequent review is only necessary if you are actively troubleshooting an authentication problem or just launched a new sending tool.

New tool onboarding protocol. Whenever a new tool that sends email is added to your stack, add a DMARC check to the onboarding process. After the first week of sends, review DMARC data to confirm the new tool is appearing with authentication passes.

DMARC policy progression. DMARC reports are how you build confidence to progress from p=none to p=quarantine and eventually p=reject. Once your reports consistently show all legitimate sources passing authentication and no significant unauthorised sources, advancing the policy is safe. Without reading reports, you cannot make this progression safely.

Spoofing alerts. If a phishing campaign is using your domain, DMARC reports show it. A sudden appearance of an unrecognised high-volume IP with authentication failures is an early warning. At p=reject, these sends are blocked. At p=none, they are not, but you at least have visibility.

Key Takeaways

DMARC aggregate reports (rua=) show every IP that sent email using your domain during24 hoursd, with authentication pass/fail results for each. They answer questions your ESP dashboard cannot.
Key fields to read: source_ip (who is sending), count (how many messages), DKIM and SPF under policy_evaluated (did they pass authentication).
Good DMARC data: all recognised sending sources pass both DKIM and SPF. No unrecognised sources appear with high volumes.
Common problems revealed: a recognised tool failing authentication (fix the config), unrecognised IPs with high volume (investigate for spoofing), low overall pass rate (find and fix failing sources), and shadow sender tools you did not know were sending email with your domain.
Use a DMARC analytics tool (Dmarcian, DMARC Digests) to read reports without parsing raw XML. Most offer free tiers suitable for typical email programme volumes.
Review monthly. Progress your DMARC policy from p=none to p=reject using report data to confirm all legitimate sources pass before each policy advancement.

Frequently Asked Questions

How do I start receiving DMARC reports?

Add a DMARC TXT record with a rua= email address. Once processed, participating providers will send aggregate reports.

Why am I not receiving DMARC reports?

Check that your DMARC record is published correctly. Low email volume, provider limitations, or an incorrect reporting address can also prevent reports.

Do I need a ruf= forensic reporting address?

Usually not. Major providers mainly send aggregate reports, while forensic reporting has limited support due to privacy concerns.

How can I identify an IP in a DMARC report?

Use a reverse IP lookup to identify the organization behind the sending IP. Investigate any unfamiliar IP before treating it as authorized.

What should I do with DMARC reports?

Review them regularly to identify unauthorized senders, authentication failures, and potential configuration issues before moving toward a stricter DMARC policy.

Conclusion

DMARC reports are the most complete picture available of your domain’s sending ecosystem. They reveal authentication gaps, unauthorised senders, and tool configuration issues that are invisible in your ESP dashboard.

The barrier is the XML format; it looks complex but contains a small number of fields that matter. A DMARC analytics tool removes even that barrier, presenting the same data in a readable interface.

Set up the rua= reporting address if you have not already. Start using a DMARC analytics tool. Review monthly. Use what you find to fix authentication gaps and progress your policy toward p=reject. The result is a sending infrastructure that is both more secure and more reliable.

Start Monitoring DMARC Today