Aggregate reports (rua) tell you how much mail failed DMARC and from where, once a day, in a batch. Forensic reports (ruf) are supposed to do something more useful: send you a copy of the individual failing message, close to the moment it failed. In principle, that’s the difference between a spreadsheet and a crime-scene photo.

In practice, almost none of the reports you’d want ever arrive. Here’s what ruf actually asks for, why the two biggest mailbox providers largely don’t send it, and the narrow set of situations where configuring it is still worth the DNS line.

What a forensic report contains

A DMARC record can request forensic reports with the ruf tag, pointed at a mailto address:

v=DMARC1; p=quarantine; rua=mailto:agg@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1

Two supporting tags shape what you get:

rf= — the report format. afrf (Authentication Failure Reporting Format) is the only registered value and the default, so you rarely need to set it explicitly.
fo= — failure reporting options, a colon-separated list that controls when a report is generated: 0 (default) fires only when every underlying mechanism fails; 1 fires if any mechanism fails to produce an aligned pass; d and s narrow it to DKIM or SPF failures specifically.

Where a receiver actually implements ruf, the report arrives as a per-message AFRF document that can include the original headers, the authentication results, and — this is the part that matters — portions of the message itself, potentially including the subject line and body. A minimal report looks roughly like this:

Feedback-Type: auth-failure
User-Agent: SomeMTA/1.0
Version: 1
Original-Mail-From: sender@example.com
Original-Rcpt-To: recipient@theirdomain.com
Arrival-Date: Fri, 24 Jul 2026 09:14:22 -0700
Source-IP: 203.0.113.44
Authentication-Results: theirdomain.com; dmarc=fail (p=quarantine) header.from=example.com
Delivery-Result: policy
Auth-Failure: dmarc

Compare that to a rua aggregate report, which never names a recipient and only ever reports on volume and disposition:

	Aggregate (`rua`)	Forensic (`ruf`)
Contents	Counts, source IPs, auth results, per sending source	Per-message headers, possibly subject and body
Timing	Batched, roughly once every 24 hours	Near real-time, per failing message
Recipient identifiable	No	Often yes
Provider adoption	Near-universal among receivers who validate DMARC	Sparse and inconsistent
Best for	Ongoing monitoring, source inventory, climbing the policy ladder	Investigating a specific active incident

Why aggregate and forensic reports diverge so sharply

rua reports are anonymized by design: sender IP, volume, disposition, authentication results, aggregated by day. No message content, no recipient-identifying detail. Every major provider treats generating them as safe, and adoption is close to universal.

ruf reports are the opposite shape. A forensic report can carry the actual failing message, which means it can carry a real recipient’s email address in the To: header, a subject line that reveals what the message was about, and body content that may contain personal information about whoever received it. Sending that data to a third party — the domain owner who published ruf, not the recipient — raises the same privacy questions email itself is regulated to avoid.

That tension is exactly what pushed adoption down. Google has never sent forensic reports, citing the same privacy reasoning. Microsoft’s consumer and enterprise mail (Outlook.com, Microsoft 365) does not send them either. Yahoo and AOL have historically sent forensic reports for some failure conditions, making them something of an exception among large mailbox providers, though behavior there is inconsistent and not something to build a monitoring plan around. Smaller providers and self-hosted mail servers are more likely to honor ruf if the receiving MTA happens to be configured for it — but you cannot assume any specific inbox you care about will comply.

The practical result: publish ruf on a domain that sends primarily to Gmail and Outlook recipients, and you should expect close to zero reports back, regardless of how much mail is actually failing.

The 2026 spec update didn’t change the incentives

In May 2026, the IETF published a three-document replacement for the 2015 DMARC specification — RFC 9989 (core mechanism), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) — collectively obsoleting the original RFC 7489 and formally moving DMARC onto the IETF Standards Track for the first time. RFC 9991 tightens the failure-report format and adds an explicit privacy section instructing report generators to redact local-parts and sensitive content where possible.

What it doesn’t do is create new pressure on Gmail or Microsoft to start sending reports they’ve avoided for a decade. The privacy reasoning that kept ruf niche in 2015 is, if anything, stronger under current data protection law than it was then. Configuring ruf correctly today gets you a marginally better-specified report if and when one arrives — it doesn’t make one more likely to arrive from the providers that matter most to a typical B2B sending domain.

What to use instead, day to day

For the failure visibility that actually shows up reliably, aggregate reports are the whole game. Every major provider sends them, they cover 100% of evaluated mail rather than a best-effort subset, and they’re enough to identify every sending source, spot a spoofing attempt, and track your climb from p=none to enforcement. How to read DMARC reports walks through the raw XML field by field, and our DMARC report viewer turns a folder of gzipped attachments into a readable table without asking you to parse anything by hand.

If you haven’t set up the policy record itself yet, p=none vs p=quarantine vs p=reject covers the climbing order — and the rua tag that actually earns its keep — before ruf is worth a second thought.

When configuring ruf is still worth it

There are a handful of situations where publishing ruf is a reasonable, low-cost addition to a DMARC record — as long as you keep expectations calibrated to how few reports will actually land:

You control or influence a mixed mail ecosystem — a university, an ISP, or an enterprise with many smaller or self-hosted domains in the recipient mix — where a meaningful share of mail flows through servers more likely to honor forensic reporting.
You’re investigating a specific, active spoofing incident and want every available signal while you chase it down, understanding that most of the useful evidence will still come from the aggregate reports and from the sample headers major providers do expose through their own postmaster tools.
A downstream security or SOC team specifically asked for it as one input among several, rather than as the primary detection mechanism.

Outside of those cases, ruf is a few extra characters in a DNS record that mostly returns silence. It doesn’t hurt to publish — a ruf tag with no reports arriving costs nothing — but don’t build a monitoring plan that assumes it will.

If you do configure it, do it deliberately

A ruf address is, itself, a mailbox that will receive whatever a receiver decides to send it — including message content belonging to other people. Treat it accordingly:

Point ruf= at a dedicated mailbox, not the same inbox that receives your rua aggregate reports or your day-to-day mail. Forensic reports can contain data you don’t want mixed into a general support inbox.
Set retention and access controls on that mailbox deliberately — you’re now storing fragments of other people’s email, which is exactly the category of data that made providers cautious about sending it in the first place.
Start with a narrow fo= value (0, the default) rather than fo=1, so you’re not asking for a report every time SPF alone fails on a message that still passes DKIM and DMARC overall.
Expect to build your actual monitoring workflow around rua, and treat anything that shows up in the ruf mailbox as a bonus, not a dependency.

None of this is a reason to avoid ruf entirely. It’s a reason to size the effort correctly: a low-maintenance addition to a record that already has aggregate reporting doing the real work, not a forensic pipeline you build a process around.