一個 SPF pass 可以是完全正確的，而不執行任何操作來驗證您的客戶看到的地址。發送伺服器可能被授權使用供應商的信封網域，而可見的寄件者則使用您的業務網域。 DMARC 詢問通過的身份驗證身份是否與該作者域一致。
這是身分問題，不一定是 IP 缺失問題。在擴展SPF權限之前，從實際收到的郵件中的網域開始。
比較三個單獨的觀察結果
記錄可見的寄件者域、評估的域SPF以及每次經過的域 DKIM簽名'sd= 欄位。分別記錄每個機制的接收器結果。不要推斷 結盟 來自綠色SPF或 DKIM 隱藏其評估的網域的徽章。
RFC 9989第 4.4.2 節 定義SPF對齊。嚴格對齊要求SPF和作者域在下面完全匹配 RFC 9989 §3.2.10.2。寬鬆對齊使用組織域發現 RFC 9989 §4.10.2。它不允許與您簽訂合約的供應商擁有任何網域名稱。
工作範例：未對齊的正確傳球
以下是假設適用DMARC策略的綜合診斷裝置。將顯示一則訊息「寄件者： accounts@example.com 。它是 郵件來自 是delivery@vendor.example.net 。連接 IP 為192.0.2.17 。供應商信封策略是 v=spf1 ip4:192.0.2.17 -all，所以SPF通過。
Assume the organisational domains are example.com and example.net .它們不同，因此SPF路徑在寬鬆或嚴格模式下不對齊。如果DKIM也僅透過d=vendor.example.net,則傳遞的身份都不會對齊。因此DMARC缺乏一條通過的對齊路徑 RFC 9989 §5.3.5。將該 IP 新增到example.com的 SPF記錄 不會改變此交易使用了vendor.example.net的事實。
現在考慮一個受支援的自訂信封return@bounce.example.com 。如果bounce.example.com的SPF通過且它和example.com都有相同的發現 組織域，寬鬆的SPF排列就可以通過。嚴格對齊仍然不行，因為名稱不同。或者，帶有d=example.com的傳遞DKIM簽章可以提供對齊的DKIM路徑。
選擇支持的修正
詢問服務文件或管理員是否支援自訂 MAIL FROM 網域、對齊的DKIM或兩者。從服務取得準確產生的DNS值。通用SPF包含本身不會配置自訂信封，且手動偽造提供者的返回地址可能會中斷退回郵件處理。
選擇適合工作流程和您的策略的更正。一致的DKIM部署通常透過轉發提供有用的彈性，儘管對所覆蓋內容的更改可能會破壞簽名 RFC 6376 §3.7。如果您使用自訂 MAIL FROM，請在提供者報告設定完成後測試實際信封。必須針對正在使用的產品和帳戶驗證產品可用性和設定步驟。
不要僅僅為了刪除警告而放鬆對齊而不了解它所創建的邊界。相反，如果合法子網域寄件者有意設計為寬鬆對齊，則不要選擇嚴格對齊作為安全標誌。記錄為什麼所選的身份關係是可以接受的。
重新測試路徑，而不僅僅是DNS
將代表訊息傳送到郵箱，您可以在其中檢查可信任接收者結果。測試失敗的通知類型，因為提供者的行銷和交易產品可能使用不同的身分。擷取新信封、 SPF結果、 DKIM簽名域和DMARC結果。
如果直郵有效但轉送郵件無效，請單獨調查該路由。不要因為不相關的內容過濾器仍將郵件放入垃圾郵件中而認為DNS更正不成功。身份驗證結果和郵箱放置是不同的結果。
實用的外賣
有用的診斷可以命名傳遞域並顯示其對齊或不對齊的原因。修復支援的發送身份，然後驗證真實訊息。對錯誤域的更廣泛SPF權限無法彌補對齊差距。
保持決策的可重複性
每個傳遞的標識及其對齊模式使用一行。僅透過vendor.example.net傳遞 From= example.com ，將兩個原始傳遞標記為未對齊，而不是將一個結果連接到另一個網域。如果d=example.com也進行了驗證，請記錄單獨對齊的DKIM路徑。即使整體DMARC已經通過，也可以獨立測試自訂 MAIL FROM 行為。