Why almost nobody sends them

After this lesson you can

Explain why a valid ruf address receives nearly nothing, and decide whether to publish one.

Assumes you have read fo, and what each value asks for.

Failure reports contain message headers and sometimes the message itself. That is what makes them useful, and it is the entire reason you will receive almost none.

Why receivers do not send them

They contain personal data. A failure report identifies a sender, a recipient and the content of their correspondence. Forwarding that to a third party on the strength of a DNS record is a disclosure most large receivers will not make.
The recipient did not consent. The domain owner requested the report; the person whose message is in it did not, and is frequently not a customer of the requesting domain at all.
Volume. At scale, failure reports are a substantial outbound mail stream of their own, generated on behalf of someone else.
It is an amplification vector. An attacker who triggers failures for a domain causes reports to be sent to whatever address that domain nominated.

The result is that the largest mailbox providers send none at all. What arrives comes from a small number of smaller operators and some security vendors, in volumes that are useful as samples and useless as measurement.

Whether to publish one

The argument for is that a handful of real failing messages, with headers, resolves questions aggregate reports cannot — which sending system produced this, what did the message look like, was it yours at all. When one arrives it is often decisive.

The argument against is that you are asking for personal data to be sent to you, and you then hold it.

Use an address that goes to a controlled mailbox, not a ticketing queue or a shared inbox.
Have a retention period, and apply it.
Know that the volume will be small enough that no automation is warranted.
If your organisation has a data-protection process, this is squarely within it.

Do not send ruf to a processor without asking what they do with it

Aggregate reports contain no personal data and can be handed to a vendor freely. Failure reports are a different category of thing, and pointing ruf at the same processor out of symmetry is a decision worth making deliberately rather than by copying the rua line.

Knowledge check

You publish ruf and receive almost nothing. What is the most likely explanation?

Large receivers decline to send failure reports at all, because the reports contain correspondence they were not given permission to disclose.
fo is unset, so no conditions have been requested.
Your mail is passing DMARC, so there is nothing to report.
The external destination authorisation is missing.

Correct — Large receivers decline to send failure reports at all, because the reports contain correspondence they were not given permission to disclose. This is the normal state, not a misconfiguration. Aggregate reports carry no personal data and arrive reliably; failure reports carry headers and content and mostly do not arrive.

Not this — fo is unset, so no conditions have been requested. Worth checking, and fo defaults to 0, which requests reports on DMARC failure. An unset fo reduces the range of conditions, not the number of receivers willing to report.

Not this — Your mail is passing DMARC, so there is nothing to report. Possible for a small well-run domain, and unlikely — some spoofing and some misconfigured sender almost always fails somewhere.

Not this — The external destination authorisation is missing. A real cause of missing reports and it would suppress aggregate reports too. Near-zero ruf alongside healthy rua points at receiver policy instead.

Last reviewed 2026-09-15

Why almost nobody sends them

Why receivers do not send them

Whether to publish one

Try it on a real domain