If you have set up DMARC with another vendor, you have probably seen a `ruf=` tag alongside `rua=` in their instructions. SendOps omits it. This page explains why.


We are not planning to add forensic report support later. The reasons below are structural, and they do not change with a future release.


## What a forensic report is

DMARC defines two report types. The `rua` tag requests **aggregate** reports — daily statistical summaries with no message content. The `ruf` tag requests **forensic** (or failure) reports, which are different in kind: a copy of an individual failing message's headers, sent one message at a time, in near real time.

"Headers" understates it. Depending on the reporter, a forensic report may include the full message body.

## They carry personal data to a public address

This is the core objection, and it has two halves.

**A forensic report contains recipient email addresses and subject lines.** That is personal data about your correspondents — the people you write to — leaving your control. Under most privacy regimes it is your responsibility, and you would be handing it to a vendor as a side effect of a monitoring setup.

**The destination is published in public DNS.** A `ruf` address is written into a TXT record that anyone in the world can read. Combine that with the fact that the envelope sender of inbound mail is chosen entirely by whoever sends it, and the address becomes something anyone can post to. There is no authentication step in which we could establish that an arriving forensic report is genuine before its contents exist on our systems.

Aggregate reports share the second property but not the first. An aggregate report about a domain we have no address for is simply a count of nothing, discarded at parse time. A forensic report is a copy of somebody's mail.

## The signal is close to zero anyway

If forensic reports were the only way to identify a problem sender, the trade-off would at least be a trade-off. They are not.

**The large mailbox providers do not send them at all** — Google, Microsoft and Yahoo all declined years ago, for exactly the reasons above. What arrives instead comes from a small number of smaller reporters.

That makes the sample worse than small: it is **skewed**. The forensic reports you receive describe the mail you sent to the least representative slice of your recipients, and a conclusion drawn from them is a conclusion about that slice. You would be accepting a meaningful privacy cost in exchange for a biased sample.

## What we do instead

Aggregate reports already answer the question forensic reports are usually reached for. For every sending source, they give you:

- the source IP address and, through enrichment, who operates it
- how many messages it sent
- whether SPF and DKIM passed, and whether each aligned
- the DKIM selectors and signing domains involved
- the disposition the receiver applied

That is enough to identify a sender, tell your own misconfigured infrastructure apart from a third party, and decide what to do about it — without a single message body. The [source table](/domain-auth/reading-your-source-table) is built entirely from this data.

If you genuinely need per-message forensics — the exact content of a specific message that failed — that is a question for your own mail logs, where you already hold the message and already have a lawful basis for it. It is not a question DMARC should be answering for you.

## We do read your `ruf` tag

One clarification, since it surprises people.

If your existing DMARC record contains a `ruf=` tag, SendOps parses it, purely so the setup card can show you accurately what your record currently says. We never add one, never request forensic reports, and never process one if it arrives.

## Related

- [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting) — what we do ask for
- [Reading Your Source Table](/domain-auth/reading-your-source-table) — what aggregate data gets you