The fo tag asks a receiver which failure conditions should generate reports. It does not change the authentication rules or force a receiver to send reports. Understanding that distinction avoids a common mistake: reading a report requested by fo=1 as proof that the message failed DMARC overall.
RFC 9989 section 4.7 defines four values: 0, 1, d and s. The default is 0. The tag is ignored when ruf is absent, and receivers may choose whether to honor the requested options. Review privacy and report-handling readiness before broadening a request.
Understand 0 and 1 in terms of alignment
With fo=0, the requested DMARC failure-report condition is that all underlying authentication mechanisms fail to produce an aligned pass. With fo=1, the condition is that any underlying mechanism fails to produce an aligned pass. The difference concerns the reporting trigger, not a new definition of DMARC success.
A message can pass DMARC through aligned DKIM while SPF fails or is unaligned. That condition can satisfy a fo=1 reporting request even though the message passes DMARC. Calling such a report a contradictory DMARC result confuses the reporting option with the evaluation result.
Distinguish mechanism-specific options
The d value requests a DKIM failure report when a signature fails evaluation, regardless of alignment. The s value requests an SPF failure report when SPF evaluation fails, also regardless of alignment. These are mechanism-specific report requests, not synonyms for the aligned-pass conditions of 0 and 1.
For example, a passing but unaligned SPF identity does not become an SPF evaluation failure solely because it is unaligned. It can matter to the fo=1 aligned-pass condition without satisfying s on that basis. RFC 9991 section 3 discusses the relationship between DMARC and mechanism-specific failure reports; actual generation remains dependent on receiver support and policy.
Use valid combinations deliberately
When requesting more than one option, separate values with colons, such as fo=0:d. Values 0 and 1 are mutually exclusive. Do not publish fo=0:1 as a way to request everything. Keep the existing version, policy and reporting destinations coherent when reviewing a proposed record change.
Illustrative fragment: ruf=mailto:diagnostics@example.com; fo=1. It shows a requested destination and trigger, not a complete DMARC record or a destination that has been authorized for your organization. Do not paste example addresses into production. Confirm supported receiving arrangements and external authorization under RFC 9991 section 5 where applicable.
Walk through two cases
Synthetic case A has aligned DKIM pass and SPF fail. DMARC passes through DKIM; the fo=1 trigger can be met, while fo=0's all-mechanisms condition is not. The s option describes an SPF failure-report condition in this case, subject to receiver behavior.
Synthetic case B has DKIM pass under an unrelated domain and SPF pass under an unrelated domain. Neither mechanism supplies an aligned pass, so DMARC fails and the fo=0 condition is met. Neither the d nor s evaluation-failure condition follows merely from these unaligned passes. These examples explain protocol conditions, not reports observed from a real provider.
Verify the request without promising output
Review the published record, destination ownership, authorization and the report consumer's privacy controls. Use a controlled test with a cooperating receiver if one is available, then record exactly what it generated. An absent report does not prove the tag is invalid or the test passed.
Keep aggregate reporting and enforcement decisions separate. Changing fo does not change p, establish a new SPF authorization or repair a DKIM signature. Its purpose is to request a different set of potentially sensitive diagnostic reports.
Read a mechanism-failure example
Synthetic case C has a failed DKIM signature and an aligned SPF pass. DMARC passes through SPF. The fo=1 condition can be met because DKIM supplied no aligned pass, and d describes the failed-signature reporting condition. The fo=0 condition is not met because SPF provided an aligned pass; s does not follow from an SPF pass. A request such as fo=1:d expresses the two relevant conditions, but does not oblige a receiver to generate either report. Choose it only if the diagnostic purpose and report-handling controls justify the broader request.
Keep a compact investigation record
Use this suggested worksheet for the route under review. It is a planning aid, not evidence of an executed test.
- Need: the diagnostic question and the narrowest trigger that addresses it.
- Record: current ruf and fo values, ensuring 0 and 1 are not combined.
- Destination: ownership, external authorization where needed, access and retention decisions.
- Observation: receiver support and actual reports received; silence is inconclusive.