定義轉發器的職責
經過驗證的重郵服務接收訊息並向前發送另一個SMTP事務。該描述涵蓋了不同的服務：地址轉發器、討論清單、安全網關或重新分發郵件的應用程式。 「經過身份驗證」是不完整的，除非它指定了身分、機制和接收躍點。服務可以驗證其自己的出站連接，而無需保留原始作者的身份驗證。因此，責任邊界應該遵循整個路線的消息，而不是遵循產品標籤。
從郵件流的書面服務合約開始。確定誰接受原始訊息、更改信封、修改簽名內容、處理傳送失敗並向最終接收者提供證據。以下建議的責任圖是一個規劃輔助工具，而不是對已部署服務的觀察。每個操作員應該能夠解釋自己的更改，而無需聲稱控制其他操作員的過濾決策。
將三個身分問題分開
連線IP和SMTP 信封寄件人 重要的是 SPF。簽名域和受保護的訊息資料很重要 DKIM. DMARC 詢問合格的經過驗證的識別碼是否與訊息的「寄件者」欄位中的「作者域」一致。重郵者對其自己的信封域的成功SPF結果不會自動成為不相關的原始作者的對齊結果。即使使用者介面顯示一個令人放心的「經過身份驗證」的標籤，這些也是單獨的問題。 RFC 7208 ，第 2.4 節 和 RFC 9989 ，第 4.4 節 定義相關邊界。
信封重寫可以使轉發器負責新的返迴路徑，並允許SPF描述其出站基礎架構。它本身並不能修復原作者 結盟。同樣，一個新鮮的 DKIM簽名 來自轉發器的資訊證明了有關該簽名域的一些信息，而不一定是原始作者。記錄新舊身份，以便後來的分析人員可以看到哪些關係被保留、替換或遺失。
自己的修改可能會破壞簽名
附加頁尾、更改簽名主題欄位或重新編碼受保護內容的服務需要了解相關的DKIM簽名和 規範化。有些轉換在選定的規範化後仍然存在；其他人則不然。不要假設每個標頭變更都會破壞DKIM ，或「寬鬆」的規範化允許任意編輯。保留原始副本並在診斷故障時比較實際簽名的標頭和正文。 RFC 6376 ，第 3.4 和 5.4 節 提供機制，而不是對特定轉發器的承諾。
Google 的轉寄指南建議保護 DKIM 覆蓋的內容，並指出Gmail會自行評估轉寄的郵件。這是 Gmail 特定的操作建議，而不是普遍接受協議。重郵者仍然對其所做的更改負責，包括某些清單設計使用的有意的寄件者重寫。此類重寫會更改提供給收件人的身份，並且需要有關回覆和歸屬的明確產品決策。 Google 轉址指南.
將ARC視為具有信任邊界的證據
ARC 可以承載中介機構的認證評估和可驗證的處理鏈。它的驗證並不證明良性內容或確定每個密封域都是值得信賴的。最終接收者必須決定如何（如果有的話）使用該資訊。分別保存鏈、密封域、接收者的評估和本地配置。 ARC通行證不是對齊的DKIM通行證的替代條目。 RFC 8617 ，第 7 節和第 9 節.
標準狀態也需要一個日期。 2026 年 11 月 8 日， RFC 8617仍處於實驗階段。活躍的draft-ietf-dmarc-arc-to-historic-01建議結束實驗並將RFC移至Historic；這是一項正在進行的工作，而不是已頒布的重新分類。服務評估應揭露該提案，但不提供通用ARC部署或已完成退役的事實。 當前草案狀態.
跟著一則虛構的訊息穿過邊界
考慮一則來自notices@sender.example的虛構訊息，透過校友轉發器路由到最終信箱。假設原始流具有對齊的DKIM簽章。轉發器將信封寄件者變更為自己的網域，但保留受保護的訊息不變。最終接收者的預期問題是原始簽名是否仍然有效和對齊。新信封的SPF結果回答了不同的身分問題。這個範例是一個推理練習；未收集任何訊息、 DNS回應或接收器結果。
現在假設同一服務添加了正文免責聲明。分析人員必須比較該步驟之前和之後的簽名覆蓋內容。服務自己的簽名或 ARC密封 可以提供額外的證據，但兩者都不應該被默默地描述為原始簽名的恢復。修正工作首先屬於引入相關轉換的參與者，而原始發送者仍然擁有其簽名配置，接收者擁有其接受策略。
承擔責任但不承諾交付
當接收伺服器在訊息資料後給予肯定的完成回應時， SMTP責任就會轉移。然後，該伺服器負責交付或適當的後續故障處理。這種傳輸責任不同於收件匣放置或在以後的每個躍點繼續進行身份驗證的承諾。重郵者應保留足以解釋該傳輸的佇列識別碼、時間戳記和有界診斷記錄。 RFC 5321 ，第 4.2.5 節.
RFC 9989 明確討論了間接流互通性，並警告不要將域策略視為接收者的唯一處置輸入。在規劃寄件者策略時審查清單參與和合法轉發，而不是要求轉發器保證每個收件者的行為。 RFC 9989 ，第 7.4 節.
仍需證據
直接和間接傳遞樣本與路線、信封、簽名和可信結果進行比較。此要求仍然開放。收集授權的配對樣本，標記可信任接收者新增的結果，並比較躍點身分和修改。文獻標準研究和虛構路線並未建立實際轉發服務的行為。