DMARC ruf= forensic reports: what they are and why you barely get any

You added ruf= to your record expecting a copy of every spoofed message, and the mailbox stays empty. Nothing is broken. Here's what forensic reports actually are, who sends them, and where the real signal lives.

Two kinds of DMARC reports

	Aggregate (rua=)	Forensic / failure (ruf=)
What arrives	An XML summary per receiver, typically daily: every source IP, its SPF/DKIM results, message counts	An individual report about a single failing message, near real-time
Contains message content?	No — counts and results only	Yes — headers, sometimes body excerpts
Who sends them	Virtually every major mailbox provider	A small minority of receivers
Do you need it?	Yes — this is where DMARC's feedback loop lives	Optional at best

If aggregate reports are new to you, start with how to read DMARC reports — everything below is about the second column.

Why the ruf mailbox stays empty

Forensic reports contain other people's email — headers with sender and recipient addresses, often subject lines, sometimes content. Sending that to a third party (you) is a privacy problem, so most large providers, Gmail included, simply don't send forensic reports at all. The few receivers that do usually redact them heavily. The result: even a heavily-spoofed domain might see a trickle of ruf messages from small receivers, while the same spoofing shows up plainly — with source IPs and counts — in the aggregate reports everyone sends.

So an empty ruf mailbox tells you nothing about whether your record works. If aggregate reports aren't arriving either, that's a real symptom — work through not receiving DMARC reports.

The fo= tag: when a failure report is triggered

If a receiver does send failure reports, the fo= tag in your record says which failures you care about:

Value	Report when…
fo=0	both SPF and DKIM fail to produce an aligned pass (the default)
fo=1	any underlying check fails, even if DMARC passes overall — the most useful setting for debugging
fo=d	a DKIM signature fails, regardless of DMARC result
fo=s	an SPF check fails, regardless of DMARC result

Values combine with colons (fo=1:d:s). Without a ruf= address, fo= does nothing.

The external-destination rule (applies to rua too)

If your report address is on a different domain than the one publishing the record — say example.com sends reports to reports@monitor-service.com — receivers verify the destination actually agreed to receive them. The receiving domain must publish a TXT record at:

example.com._report._dmarc.monitor-service.com   TXT   "v=DMARC1"

Monitoring services (ours included) publish this authorization automatically for their report addresses. But if you point rua= or ruf= at, say, your personal address on another domain you own, and reports never arrive — this rule is a likely reason.

Should you use ruf at all?

• Fine to omit. A record with only rua= is complete; enforcement and reporting work fully without ruf. Our generator treats it as optional for exactly this reason.
• If you're in the EU, think before collecting them. Forensic reports can contain personal data of third parties (senders and recipients of failing mail). An unmonitored mailbox slowly filling with other people's message headers is a GDPR liability nobody assigned an owner to.
• Where it earns its keep: short diagnostic windows. Chasing a specific alignment failure you can't reproduce? Add ruf= with fo=1, catch whatever the minority of reporting receivers send you, and remove it when you're done.