DMARC RUA vs RUF Reports: Which Should You Use?
Understand the difference between DMARC aggregate (RUA) and forensic (RUF) reports. Learn which report type you need and why most senders should focus on RUA.
Two Ways to Monitor Your Email Authentication
DMARC offers two reporting mechanisms to help you understand what's happening with email sent from your domain. They serve different purposes and have very different adoption rates.
RUA (Aggregate Reports): Statistical summaries of authentication results, sent daily by receiving ISPs.
RUF (Forensic Reports): Individual failure notifications with message details, sent in real-time when authentication fails.
Most senders should focus exclusively on RUA reports. Here's why—and when RUF might still be useful.
RUA: Aggregate Reports
Aggregate reports are the backbone of DMARC monitoring. Every major ISP sends them, and they provide the data you need to understand your email authentication posture.
What RUA Reports Contain
Each aggregate report covers a 24-hour period and includes:
- Report metadata: Which ISP sent it, the time period covered
- Your published policy: What DMARC record the receiver saw
- Authentication results: Grouped by source IP, showing pass/fail counts for SPF, DKIM, and DMARC alignment
Example RUA Data
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>1547</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
This tells you: 1,547 emails came from IP 192.0.2.1, and they all passed both DKIM and SPF authentication.
Who Sends RUA Reports
Every major email provider sends aggregate reports:
- Gmail (google.com)
- Yahoo/AOL (yahoo.com)
- Microsoft Outlook/Hotmail (microsoft.com)
- Apple (apple.com)
- Comcast, Verizon, and other consumer ISPs
- Most corporate mail servers
When you add rua=mailto:dmarc@yourdomain.com to your DMARC record, these providers automatically start sending daily reports.
RUA Privacy Considerations
Aggregate reports contain no message content and no personally identifiable information. They only include:
- Source IP addresses
- Message counts
- Authentication results
- Domain names
This makes them safe to send to third-party DMARC analysis services without privacy concerns.
RUF: Forensic Reports
Forensic reports provide detailed information about individual messages that fail DMARC authentication. In theory, they're useful for debugging specific failures.
In practice, they're rarely available.
What RUF Reports Contain
A forensic report includes:
- Message headers: The full email headers of the failed message
- Authentication details: Exactly why SPF, DKIM, or alignment failed
- Timestamps: When the failure occurred
- Partial or full message body: Depending on the sender's configuration
The Privacy Problem
Here's why RUF reports are problematic:
Headers contain sensitive information. Email headers reveal recipient addresses, subject lines, routing information, and internal server names. Sending this data to external parties raises privacy and compliance concerns.
GDPR and privacy laws apply. In many jurisdictions, email headers constitute personal data. ISPs are reluctant to transmit this information automatically.
Potential for abuse. Bad actors could use forensic reports to harvest email addresses or gather intelligence about an organization's email infrastructure.
Most ISPs Don't Send RUF Reports
Because of these privacy concerns, the major ISPs have stopped sending forensic reports:
| Provider | Sends RUA | Sends RUF |
|---|---|---|
| Gmail | Yes | No |
| Yahoo/AOL | Yes | No |
| Microsoft | Yes | No |
| Apple | Yes | No |
| Comcast | Yes | No |
The bottom line: Even if you configure ruf= in your DMARC record, you won't receive forensic reports from the providers that handle most consumer email.
Some smaller ISPs and corporate mail servers may still send RUF reports, but coverage is inconsistent and declining.
RUA vs RUF: Direct Comparison
| Feature | RUA (Aggregate) | RUF (Forensic) |
|---|---|---|
| Report frequency | Daily summaries | Real-time per failure |
| Data granularity | Aggregated by IP/count | Individual messages |
| Privacy impact | Low (no PII) | High (headers, content) |
| ISP adoption | Universal | Rare/declining |
| Gmail support | Yes | No |
| Microsoft support | Yes | No |
| Yahoo support | Yes | No |
| Best for | Ongoing monitoring | Specific debugging |
| Recommendation | Always use | Optional/skip |
How to Configure Each Report Type
Setting Up RUA (Recommended)
Add the rua= tag to your DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Best practices for RUA:
- Use a dedicated email address (not your personal inbox)
- Consider a DMARC analysis service to parse the XML
- You can specify multiple recipients:
rua=mailto:dmarc@yourdomain.com,mailto:dmarc@thirdparty.com
Setting Up RUF (Optional)
If you want to attempt receiving forensic reports, add the ruf= tag:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com
You can also control when forensic reports are generated with the fo= tag:
fo=0- Generate report if all authentication fails (default)fo=1- Generate report if any authentication failsfo=d- Generate report if DKIM failsfo=s- Generate report if SPF fails
Example with forensic options:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1
Reality check: Even with this configured, you'll receive few or no RUF reports from major ISPs.
When RUF Reports Are Still Useful
Despite limited ISP support, there are scenarios where RUF can provide value:
B2B Email Environments
If your recipients are primarily at organizations running their own mail servers (not Gmail/Yahoo/Microsoft), you may receive forensic reports. Corporate Exchange servers and smaller ISPs sometimes still send them.
Internal Email Monitoring
Some organizations configure their own mail servers to generate RUF reports for internal email. This helps debug authentication issues within the organization without relying on external ISPs.
Specific Incident Investigation
If you're investigating a targeted spoofing attack and the attacker is sending to recipients whose mail servers do send RUF reports, the forensic data can help identify the attack vector.
The Practical Recommendation
Focus on RUA reports. They provide everything you need for:
- Identifying all sources sending as your domain
- Monitoring authentication pass rates
- Detecting spoofing attempts
- Validating ESP configurations
- Proving compliance with ISP requirements
Skip RUF unless you have a specific need. The limited ISP support makes forensic reports unreliable for comprehensive monitoring. If you do configure ruf=, treat any reports you receive as a bonus rather than a complete picture.
Recommended DMARC Record
For most organizations, this is sufficient:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100
Start with p=none for monitoring, analyze your aggregate reports, fix any issues, then move to p=quarantine and eventually p=reject.
The aggregate reports will tell you everything you need to know to make that progression safely.
Parsing RUA Reports
Raw aggregate reports are XML files that aren't human-friendly. Options for processing them:
Manual review: Download the gzipped XML, extract, and read. Tedious but works for low volume.
DMARC analysis services: Tools like Postmark DMARC, dmarcian, Valimail, or DMARC Analyzer parse reports automatically and provide dashboards.
Custom scripts: Parse the XML programmatically if you have specific analysis needs.
For detailed guidance on reading aggregate reports and acting on the data, see our guide on using DMARC reports to improve deliverability.
The Bottom Line
DMARC's dual reporting system made sense when it was designed, but the email ecosystem has evolved. Privacy concerns have effectively deprecated RUF forensic reports at major ISPs.
What this means for you:
Always configure RUA. Aggregate reports are universally supported and provide the data you need.
RUF is optional. Configure it if you want, but don't depend on it for monitoring.
Use analysis tools. Raw XML is painful. Let a service parse your aggregate reports into actionable insights.
Focus on the data you get. Aggregate reports tell you who's sending as your domain and whether they're authenticated. That's the foundation of email security.
Your DMARC monitoring strategy should be built entirely on aggregate reports. Anything you get from forensic reports is supplementary.
Ready to set up DMARC reporting? See our complete guide to using DMARC reports for step-by-step instructions on configuring, reading, and acting on your aggregate reports.
Need to verify your DMARC record? Use our DMARC checker tool to confirm your record is configured correctly.