The DMARC fo tag and failure (ruf) reports

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, carried unchanged into RFC 9989).

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, along with pct; you do not need them.)

The honest part: you probably will not receive failure reports

Here is what most guides leave out. The largest mailbox providers do not send DMARC failure reports, primarily because a failure report can contain personal data from the message. Google says Gmail does not support the ruf tag; Microsoft says Microsoft 365 sends no failure reports even when a valid ruf= address is published; Yahoo's sender guidance mentions only rua. The current standard says so plainly: the DMARCbis failure-reporting document (RFC 9991, May 2026) 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 record that tells receivers the other domain accepts reports for yours. 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 reads off your aggregate data: each source shows as passing, reported forwarding, an identified sender with an alignment problem, or an unknown source, with no personal data involved.

Frequently asked