fo 標籤詢問接收器哪些故障條件應產生報告。它不會更改身份驗證規則或強制接收者發送報告。理解這種差異可以避免一個常見的錯誤：讀取fo=1請求的報告作為訊息失敗的證據 DMARC 全面的。
RFC 9989第 4.7 節 定義了四個值：0、1、d 和 s。預設值為 0。當 ruf 不存在時，該標籤將被忽略，接收者可以選擇是否接受請求的選項。在擴大請求之前檢查隱私和報告處理準備。
從對齊角度理解 0 和 1
當fo=0,請求的DMARC失敗報告條件是所有底層身份驗證機制無法產生對齊的通過。當fo=1,條件是任何底層機制都無法產生對齊的傳遞。差異涉及報告觸發因素，而不是DMARC成功的新定義。
訊息可以透過對齊方式傳遞DMARC DKIM 儘管 SPF 失敗或未對齊。即使訊息透過DMARC ，該條件也可以滿足fo=1報告請求。將此類報告稱為矛盾的DMARC結果會混淆報告選項與評估結果。
區分特定於機制的選項
d 值請求DKIM 故障報告 當簽名評估失敗時，無論 結盟。當SPF評估失敗時，s 值請求SPF失敗報告，無論對齊如何。這些是特定於機制的報告請求，而不是 0 和 1 的對齊傳遞條件的同義詞。
例如，通過但未對齊的SPF身份不會僅僅因為未對齊而成為SPF評估失敗。如果在此基礎上不滿足 s，它可能會對fo=1對齊通過條件產生影響。 RFC 9991第 3 節 討論DMARC和特定機制故障報告之間的關係；實際發電仍然取決於接收者的支持和政策。
有意使用有效的組合
當請求多個選項時，用冒號分隔值，例如fo=0:d.值 0 和 1 是互斥的。不要發布fo=0:1作為請求一切的方式。在審查提議的記錄變更時，保持現有版本、策略和報告目標的一致性。
說明片段： ruf=mailto:diagnostics@example.com; fo=1.它顯示請求的目的地和觸發器，而不是完整的 DMARC記錄 或已為您的組織授權的目的地。不要將範例位址貼到生產環境中。確認支援的接收安排並 RFC 9991第 5 節下的外部授權 適用時。
過一遍兩個案例
合成案例 A 已對齊DKIM通過， SPF失敗。 DMARC透過DKIM ； fo=1觸發條件可以滿足，而fo=0's全機制條件則不滿足。 s 選項描述了這種情況下的SPF失敗報告條件，具體取決於接收器的行為。
綜合案例 B 具有不相關域下的DKIM通行證和不相關域下的SPF通行證。這兩種機制都不提供對齊通道，因此DMARC失敗並且滿足fo=0條件。 d 或 s 評估失敗條件都不是僅由這些未對齊的通道得出的。這些範例解釋了協議條件，而不是從真實提供者觀察到的報告。
驗證請求而不承諾輸出
審查已發布的記錄、目的地所有權、授權和報告消費者的隱私控制。如果有可用的合作接收器，請使用受控測試，然後準確記錄其產生的內容。缺少報告並不能證明標籤無效或測試通過。
將匯總報告和執行決定分開。更改 fo 不會更改 p、建立新的SPF授權或修復 a DKIM簽名。其目的是請求一組不同的潛在敏感診斷報告。
閱讀機制故障範例
合成案例 C 具有失敗的DKIM簽章和對齊的SPF通過。 DMARC透過SPF 。可以滿足fo=1條件，因為DKIM未提供對齊通道，且 d 描述了失敗簽章報告條件。不滿足fo=0條件，因為SPF提供了對齊通道； s 不是來自SPF pass。諸如fo=1:d之類的請求表達了兩個相關條件，但並未強制接收者產生任一報告。僅當診斷目的和報告處理控制滿足更廣泛的要求時才選擇它。
保留緊湊的調查記錄
使用此建議的工作表來查看正在審查的路線。它是一種規劃輔助工具，而不是已執行測試的證據。
- 需求：診斷問題和解決該問題的最窄觸發因素。
- 記錄：目前的 ruf 和 fo 值，確保 0 和 1 不組合。
- 目的地：所有權、需要時的外部授權、存取和保留決策。
- 觀察：接收者支持和收到的實際報告；沉默是沒有定論的。