The DMARC fo tag and failure (ruf) reports

The DMARC fo tag controls when a receiver should send you a failure (forensic) report. Here is what each value means, why you probably are not getting these reports anyway, and what to rely on instead.

What the fo tag does

The fo tag (failure reporting options) is part of your DMARC record. It tells receivers when to generate a per-message failure report (also called a forensic report), a copy of an individual message that failed DMARC. Two things to know up front: it is only a request (receivers may honor it), and it does nothing at all unless you also publish a ruf= address (RFC 7489).

The four values

fo=0   (default) report only if ALL mechanisms fail to produce an aligned pass
fo=1   report if ANY mechanism produced something other than an aligned pass
fo=d   report if a DKIM signature failed, regardless of alignment
fo=s   report if SPF failed, regardless of alignment

You can combine them with colons, for example fo=1:d:s. In practice, fo=1 is the broadest (report whenever anything is off), while the default fo=0 only reports when a message fails completely.

Failure reports vs aggregate reports

DMARC has two separate reporting streams, and it is easy to confuse them:

  • Aggregate reports (rua=) are periodic XML summaries: counts of messages per sending IP, with their SPF, DKIM, and DMARC results. They contain no message content and no personal data, and every major receiver sends them. This is the stream you actually use to reach enforcement.
  • Failure reports (ruf=), which fo governs, are one report per failing message, including its headers and sometimes its full body. Rich for debugging a single message, but they can carry personal data.

(The rf format tag and ri interval tag you may see in older records were removed in DMARCbis; you do not need them.)

The honest part: you probably will not receive failure reports

Here is what most guides leave out. The major mailbox providers, Google, Microsoft, and Yahoo, do not send DMARC failure reports, primarily because a failure report can contain personal data from the message. The current standard says so plainly: DMARCbis (RFC 9991) notes that “many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports.”

So you can set fo perfectly and still receive almost none. It is not deprecated, it just is not honored by the receivers that carry most of your mail.

What to do instead

  • Lean on aggregate reports. They tell you, per sending source, what passed and what failed, which is everything you need to find a misconfigured sender and move to enforcement, without any privacy risk.
  • If you still want failure reports, publish ruf=mailto:you@example.com and set fo=1. If that address is on a different domain than the policy, you (or your provider) must also publish the _report._dmarc authorization record so receivers are allowed to send there. Just keep your expectations low.
  • Get the per-message picture from your monitoring. The insight failure reports were meant to give, which sender failed and why, trustyourinbox derives from your aggregate data: it classifies each source as blocked spoof, forwarding, or a misconfigured sender of your own, with no personal data involved.

Frequently asked

What is the difference between rua and ruf?

rua is the aggregate stream: anonymized daily counts, sent by every major receiver, and the one you use to reach enforcement. ruf is the failure stream: per-message copies, governed by fo, and rarely sent anymore.

What should I set fo to?

If you publish a ruf= address and want maximum visibility, fo=1. If you do not publish ruf=, the value is ignored, so it does not matter. Either way, do not expect many reports from the big providers.

Is the fo tag or ruf deprecated?

No. Both are retained in the current DMARC standard (DMARCbis). They are simply not honored by Google, Microsoft, and Yahoo in practice, for privacy reasons.

Why am I not getting any forensic reports?

Because the largest receivers disable them to avoid forwarding personal data. This is expected. Use your aggregate reports instead.

Keep reading

Last verified 2026-06-23 against RFC 7489, the DMARC specification.

Stop guessing. Start monitoring.

Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.