DMARC has two reporting channels, configured with two different tags. rua collects aggregate reports: daily XML summaries of authentication outcomes, containing no message content. ruf collects forensic reports (also called failure reports): individual copies of messages that failed, sent in near real time. They sound like two views of the same data. In practice they differ in what they contain, how often they arrive, what legal exposure they create — and crucially, whether you will receive them at all.
Side by Side
Aggregate (rua) | Forensic (ruf) | |
|---|---|---|
| What it contains | Counts, source IPs, SPF/DKIM results, disposition | Headers and often body of one failed message |
| Scope | All mail, pass and fail alike | Failures only |
| Timing | Once per day | Within minutes of the failure |
| Format | XML, gzip or zip compressed | AFRF message, RFC 6591 |
| Volume | Predictable — a few dozen files a day | Unbounded; one per failing message |
| Personal data | Essentially none | Recipient addresses, subjects, content |
| Sent by major receivers | Yes — Google, Microsoft, Yahoo and most others | Rarely; Google and Microsoft do not |
| Practical value | High — the basis of every rollout | Narrow; occasional deep debugging |
What an Aggregate Report Gives You
An aggregate report answers the question "who is sending mail as my domain, and does it authenticate?" It is statistical: identical outcomes are collapsed into a single record with a count, so a report describes traffic rather than messages.
<record>
<row>
<source_ip>198.51.100.24</source_ip>
<count>1482</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
</record>That single block tells you a specific IP sent 1,482 messages as your domain, DKIM aligned and passed, SPF did not align, and the receiver took no action. Multiply by a few hundred records and you have a complete inventory of your sending estate — which is exactly what you need before turning on enforcement.
What a Forensic Report Gives You
A forensic report is a copy of one failed message wrapped in a machine-readable envelope. Where the aggregate report says "IP 203.0.113.9 failed 40 times", the forensic report shows you one of those forty messages: its headers, its subject, its recipient, and depending on the receiver, its body.
Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1
Original-Mail-From: bounce@mailer.example
Original-Rcpt-To: victim@recipient.example
Arrival-Date: Tue, 28 Jul 2026 09:14:22 +0000
Source-IP: 203.0.113.9
Delivery-Result: reject
Auth-Failure: dmarc
Reported-Domain: example.com
--- original message headers follow ---
From: "Accounts Payable" <billing@example.com>
Subject: Invoice 88213 overdue
To: victim@recipient.exampleFor a phishing investigation this is genuinely useful — you can see the pretext, the subject line and the targeting. For routine authentication debugging it is usually more than you need, and the aggregate report would have told you the same thing a day later without the baggage.
ruf feed delivers real recipient addresses and message content to whatever mailbox you nominate — including content from messages you did not send, because the spoofed mail an attacker sends is exactly what gets reported. Under GDPR and similar regimes this is personal data you are now processing. Treat the destination mailbox accordingly, or do not enable the tag.Why You Probably Will Not Receive Forensic Reports
This is the decisive practical point. The privacy exposure that makes ruf risky for you to receive is the same exposure that makes it risky for receivers to send. Google and Microsoft — between them the majority of mailbox share — do not send forensic reports at all. Most of the providers that once did have stopped.
The result: publishing ruf typically yields nothing, or a trickle from a handful of smaller operators. It is not a substitute for aggregate reporting and it will not fill gaps in your visibility. Anyone treating ruf as the "detailed" option and rua as the summary is going to be waiting a long time.
Configuring Each
Both tags take comma-separated mailto: URIs. Forensic reporting additionally respects fo, which controls when a report is generated.
# Aggregate only — the right default for essentially every domain
v=DMARC1; p=none; rua=mailto:dmarc@example.com
# Both, with forensics on any authentication failure
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=1
# Forensics only on DKIM signature failures
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=dThe fo default of 0 is narrow: it reports only when both SPF and DKIM fail to produce an aligned pass. If you enable ruf for debugging, you almost certainly want fo=1 — report when either fails. Full tag semantics are in the DMARC Tag Reference.
rua or ruf address is on a different organizational domain from the DMARC record, that domain must publish an authorisation record or conforming receivers discard the reports silently: example.com._report._dmarc.vendor.example IN TXT "v=DMARC1".Which Should You Use?
For nearly every domain the answer is aggregate only. Publish rua, leave ruf out, and revisit the decision only if a specific need appears.
A reasonable case for adding ruf:
- You are actively investigating a phishing campaign against your brand and want message-level detail.
- You have a dedicated, access-controlled mailbox and a retention policy for what lands in it.
- You have considered the data-protection implications of receiving third-party message content.
- You accept that coverage will be partial, because the largest receivers send nothing.
Against it: unbounded volume during an active spoofing run, personal data you did not ask for, and a fair chance of receiving nothing at all. If the goal is simply "why is this sender failing", the aggregate report plus a look at a real message's Authentication-Results header will answer it.
Reading What Arrives
Aggregate reports arrive as compressed XML attachments with a machine-readable subject line. Point rua at a dedicated mailbox rather than a person's inbox — even a small domain collects dozens a day.
# Unpack whatever the receiver sent
unzip -o 'google.com!example.com!1753574400!1753660799.zip'
gunzip -k 'enterprise.protection.outlook.com!example.com!....xml.gz'
# Quick source-and-volume check without tooling
grep -oP '(?<=<source_ip>)[^<]+' report.xml | sort | uniq -c | sort -rnRaw XML works for a spot check and becomes painful as a habit. The DMARC Report Analyzer takes the ZIP or XML directly and lays out sources, counts, alignment and disposition. For a walkthrough of interpreting a single file, see How to Read Your DMARC Reports.
Frequently Asked Questions
Do I need both rua and ruf?
No. rua is essential and ruf is optional and rarely useful. Publishing rua alone is the correct configuration for the overwhelming majority of domains.
Why am I not receiving any forensic reports?
Most likely because the receivers your mail reaches do not send them — Google and Microsoft do not, and many others stopped for privacy reasons. Other possibilities: fo is at its narrow default of 0, the destination is on another domain without a _report._dmarc record, or no mail is failing.
Are forensic reports a GDPR problem?
They can be. They contain recipient email addresses and message content belonging to third parties, which is personal data you become responsible for once it lands in your mailbox. That is a large part of why receivers stopped sending them. If you enable ruf, treat the destination as a system holding personal data.
Can I send rua and ruf to different addresses?
Yes, and you should. They have entirely different volumes and sensitivity — aggregate reports suit a shared mailbox or analyzer, while forensic reports warrant a restricted one.
Do aggregate reports show me the message subject?
No. Aggregate reports contain only metadata — source IPs, counts, authentication results and the header-from domain. Subjects and bodies appear only in forensic reports, which is precisely the trade-off between the two channels.
Is there a cost to enabling ruf?
No monetary cost, but there is operational and compliance cost: unbounded inbound volume during a spoofing campaign, and third-party personal data arriving unrequested. Given the low delivery rate from major receivers, the expected benefit is usually smaller than the expected cost.