將複合身份驗證讀取為 Microsoft 結果
Microsoft 的 compauth 欄位不是另一個拼寫 DMARC。它是使用身份驗證和其他訊息訊號的綜合評估，其解釋屬於 Microsoft 的記錄處理。因此，訊息可以包含外觀不同的DMARC和複合結果，而標頭不會存在本質上的矛盾。正確的任務是在決定結果建立之前讀取每個欄位、其身分上下文和關聯的原因代碼。
本文使用 2026 年 11 月 8 日保留的 Microsoft 主要文件。反垃圾郵件標題頁標示了 2026 年 7 月 27 日的更新。未提供原始訊息或租戶跟踪，並且下面的示例明顯是虛構的，而不是經過編輯的標頭。該目錄需要真實的原始訊息範例才能發布操作結論。
保持身分可見
Microsoft 將 header.from 定義為可見的寄件者域，將 smtp.mailfrom 定義為信封 郵件來自 域和 header.d 作為 DKIM 簽章域（如果存在）。這些字段可能不同。在閱讀結果時保持他們的關係： SPF 一個網域的通行證不會自動建立 結盟 與可見的寄件人，且DKIM通行證必須與其描述的簽章和網域相關聯。 Microsoft 驗證標頭字段
DMARC的協定決策涉及與其規則下的可見 From 域的對齊。 Microsoft 複合式驗證以 From 網域為基礎，同時結合SPF 、 DKIM 、 DMARC等資訊。請勿在合規性聲明或DNS故障排除結論中將單獨的DMARC結果替換為 compauth。他們回答相關但不相同的問題。 RFC 9989 Microsoft 複合字段
一起解讀結果和原因
Microsoft 記錄了 compauth 值通過、失敗、軟通過和無，並帶有三位數的原因。保留完整的一對。原因代碼不是SMTP回覆代碼，即使其數字類似於另一個診斷也是如此。請勿使用通用SMTP表對reason=130進行解碼，也不要從一封郵件的值推斷租戶範圍內的條件。使用目前的 Microsoft 表來取得觀察到的上下文。 Microsoft 複合身份驗證
標頭引用將原因 000 描述為具有DMARC失敗和隔離或拒絕策略的明確身份驗證失敗，而 001 涉及已記錄的弱或缺少策略情況下的隱式身份驗證失敗。它將 109 描述為沒有 DMARC記錄 存在，但訊息否則會傳遞。這些是範圍內的供應商定義，而不是製造標頭的說明或此處觀察到此類訊息的證據。 微軟原因程式碼
了解 bestguesspass，無需聲明已發布的政策
微軟的dmarc=bestguesspass標籤表示沒有DMARC TXT記錄 存在，但如果該網域有一個訊息就會傳遞。不得將其報告為域發布了有效DMARC策略或實際標準DMARC評估返回通過的證據。逐字保留供應商標籤並解釋其有限含義。 Microsoft DMARC欄位值
查看此類結果的寄件者仍應驗證實際的公開策略和預期的身份驗證配置。不要假設複合成功消除了對明確域策略的需求或保證其他接收者將做出相同的評估。特定於接收者的啟發式或推理不是域已發布控制項的便攜式替代品。
ARC和隱式訊號不會重寫底層事實
Microsoft 將原因 130 記錄為值得信賴的 ARC sealer 的結果覆蓋DMARC失敗。這可以解釋轉發或中介路徑中的複合結果，但這並不意味著應從證據記錄中刪除潛在的DMARC故障。保持原始結果、 ARC上下文、原因和最終處理可區分。不要聲稱任何任意ARC標頭就足夠了；記錄的案例涉及一個值得信賴的密封者。 微軟原因130
同樣，微軟描述了其他隱式訊號，並指出複合故障不會直接導致阻塞。儘管出現故障，整體評估仍然可以允許郵件發送，而其他保護技術可以識別經過身份驗證的郵件中的風險。因此， compauth=pass 並不能保證收件匣放置或內容安全，且 compauth=fail 本身也不能證明拒絕。 微軟處理說明
建立標頭信任邊界
從相關接收者取得經過授權的原始訊息，並確定哪個受信任的系統產生了結果。 RFC 8601解釋了原因 Authentication-Results 斷言需要信任邊界。訊息路徑中可以出現多個標頭，不受信任的寄件者可以插入看起來權威的文字。在沒有追蹤出處的情況下，不要選擇最符合所需結論的事件。 RFC 8601
保留一份未動過的原件以供內部驗證，並保留一份單獨的經過編輯的解釋性副本。更改地址或簽名內容可能會阻止獨立的加密重新驗證，因此請相應地標記副本。註釋可以保留身份關係以供討論，但它不是新近可驗證的原始訊息。如果接收者需要更有力的證據，請使用經過核准的安全傳輸流程，而不是默默擴大揭露範圍。
原始綜合結果工作表
以下建議的工作表使現場解釋可重複。它沒有填充真實的訊息，因此不應將其視為完整的身份驗證分析。
- 證據來源：接收訊息參考、接收者、時間戳記和可信驗證者。
- 可見身分： header.from 及其與業務發送者的關係。
- SPF ：準確的結果、smtp.mailfrom 和觀察到的來源上下文。
- DKIM ：每個相關簽章和對應 header.d 的結果。
- DMARC ：準確的供應商欄位值和單獨驗證的策略情境。
- Composite：compauth 值、三位數原因並引用 Microsoft 定義。
- 中介：轉送、可信賴ARC或其他實際可用的路由證據。
- 結果：觀察到的處理、無支持的結論和需要的下一個證據。
不要組合不同訊息的結果來建立綜合全通記錄。成功的直接傳遞樣本和轉發的失敗樣本可以揭示路由差異，但每個樣本都需要自己的身份和時間戳。當欄位或原始訊息不可用時保留未知數。
虛構範例：推斷的成功被誤認為是政策部署
虛構的 Seabright Desk 看到一份假設報告，其中包含dmarc=bestguesspass和 compauth=pass reason=109.擬議的審查解釋說，記錄的含義並未建立已發布的DMARC記錄。郵件所有者仍會檢查實際策略並確認預期部署，而不是僅根據複合結果將網域標記為完整。
此工作中不存在 Seabright Desk 標頭、 DNS答案或租戶結果。這些值僅用於說明 Microsoft 記錄的解釋，而不是作為捏造的驗證證據。真正的分析需要原始訊息和可信來源上下文。
該目錄需要當前的 Microsoft 欄位定義和經過編輯的原始訊息範例。這些定義是基於來源的，但缺乏原始訊息證據。原始證據、人類 SME、來源適用性、生產路線、視覺可及性和所有者發布仍然開放。本草案是一份解釋指南，而非經過驗證的租戶評估。