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=), whichfogoverns, 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.comand setfo=1. If that address is on a different domain than the policy, you (or your provider) must also publish the_report._dmarcauthorization 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
Reading your first DMARC report
The aggregate report walkthrough, the stream you actually receive and use.
Run a free DMARC audit
See your published DMARC record, including its reporting tags, in plain English.
Envelope-from vs header-from
The two sender addresses behind every pass and fail in your reports.
Why forwarded mail fails DMARC
The forwarding case failure reports were meant to illuminate, explained.
Last verified 2026-06-23 against RFC 7489, the DMARC specification.
Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.