錯誤的組織可能會成功進行身份驗證
攻擊者不需要冒充受信任組織的確切網域來傳送欺騙性訊息。他們可以操作不同的網域，正確配置其電子郵件並使用它來做出誤導性聲明。接收者可能觀察到成功 SPF, DKIM 和 DMARC 對於該網域，而郵件仍然嘗試詐欺。認證結果描述域使用；它並不能證明該域屬於讀者所想到的組織，也不能證明所要求的操作是合法的。
RFC 9989 明確限制DMARC的目標。網域以外的實體的內容分析和身分驗證超出了其範圍，顯示名稱攻擊也是如此。該邊界解釋了經過身份驗證的 網路釣魚 而不表明身份驗證在技術上失敗了。適當的回應結合了網域身分、訊息上下文和獨立的業務驗證。本文為防禦性指南，不包含網路釣魚範本、交付說明或即時域測試。
區分身份驗證和從屬關係
記下實際寄件者地址中的網域以及收件者期望的網域。如果它們不同，請不要折疊它們，因為顯示名稱、徽標或主題看起來很熟悉。網域所有者通常可以為自己的郵件安排身份驗證，但這並不能說明他們與其他企業的關係。即使是真實的網站和工作回覆地址也無法建立這種關係。問題在於隸屬關係和權威，而不僅僅是技術一致性。
RFC 5322，第 3.4 節，將顯示名稱與位址分開。熟悉的標籤可以位於郵件用戶端中不相關的網域之上。根據上下文，標籤可能是良性的、模稜兩可的或欺騙性的；不要僅從標籤上聲明意圖。將地址與受信任的組織記錄進行比較，並透過可疑訊息以外的已建立管道驗證特定業務操作。
檢查通過結果的含義
獨立的SPF pass 可能涉及 信封寄件人 域，而DKIM標識簽章域。 DMARC新增了一個 結盟 與可見 From 域的關係。確定哪條路徑支持報告的結果。如果所有這些身分都屬於陌生網域，則結果可以在內部保持一致，而無需驗證訊息中指定的熟悉品牌或個人。這是一個重要的發現，而不是一個需要解釋的矛盾。
使用受信任的接收者證據，而不是接受發送者提供的斷言。 RFC 8601 描述原因 Authentication-Results 消費者需要一個信任邊界。包含“pass”一詞的螢幕截圖可能無法顯示誰評估了該訊息或哪個域通過了。記錄來源、時間和相關身分欄位。如果證據不足，則保留不確定性，而不是斷言訊息最終通過或失敗。
單獨評估請求的操作
確定寄件者希望收件者做什麼。風險可能是支付目的地的改變、機密資訊的洩漏、軟體的安裝、在不熟悉的位置登入或對已建立的工作流程的變更。網域身份驗證不批准任何這些操作。技術上有效的訊息仍然可能包含錯誤的前提、未經授權的請求或與所聲稱的業務無關的目的地。
不要透過登入或輸入資訊來檢查可疑連結。當需要進行更深入的檢查時，請使用組織已建立的分析和報告流程，並配備合格的人員和適當的工具。該草案並沒有聲稱對 URL 進行目視檢查可以證明安全，也沒有聲稱每個不熟悉的網域都是惡意的。合法的新供應商和攻擊者擁有的網域可能都不熟悉；業務驗證是解決關係的方法。
使用接球手防守但不要誇大其作用
Microsoft 的電子郵件驗證概述 將複合身份驗證描述為更廣泛評估的一部分，而不是SPF 、 DKIM和DMARC的簡單替代方案。這支援分層方法：接收系統在決定如何處理郵件時可以將身分訊號與其他資訊結合。它不保證檢測到每個經過身份驗證的網路釣魚訊息或定義其他提供者的當前過濾行為。
接收者可以根據自己的控制和策略接受、隔離、垃圾郵件或拒絕郵件。不要從收件匣的放置情況推斷安全性，也不要從單一過濾結果推斷惡意性。同樣，一個公共 黑名單 結果並不是一個普遍的聲譽判決。使用提供者診斷作為具有已知範圍和時間的證據。保留機器分類和企業主批准所要求操作的權限之間的差異。
隸屬關係與行動工作表
建立一個工作表，其中包含聲明的組織、預期受信任網域、實際寄件者網域、顯示名稱、經過驗證的一個或多個網域、受信任接收者結果和請求的操作。添加預期領域的證據源，而不僅僅是觀察到的領域。記錄企業是否與寄件者建立了關係，以及特定操作是否符合該關係。保留未解決的選項，而不是強迫每個不熟悉的寄件者進入攻擊者類別。
工作表的後半部記錄了獨立驗證者、先前已知的聯繫路線、提出的問題、回應和決策負責人。避免使用僅由可疑訊息引入的電話號碼或替代地址。編輯共享副本中不必要的個人信息，同時保留域平等和差異。以相同佔位符取代每個位址的工作表無法證明身份驗證無法建立從屬關係的原因。
虛構診斷：經過正確身份驗證的新網域
想像一下，一個虛構的營運團隊收到了一個聲稱來自熟悉的設備供應商的請求。寄件者使用不在團隊批准的供應商記錄中的不同網域。假設可信接收者證據顯示該不同域的DKIM和DMARC通行證一致。接收者看到熟悉的顯示名稱，並假設身分驗證結果確認了供應商身分。事實並非如此：觀察涉及不同的領域。
建議的回應是暫停請求的更改，並透過先前建立的聯繫與供應商進行驗證。如果供應商拒絕請求，組織可以透過其批准的事件流程傳遞證據，而無需將不熟悉的網域新增至白名單。如果供應商確認合法的網域名稱更改，則該確認應進入正常的供應商維護工作流程，而不是根據一封電子郵件默默地更改信任。這個虛構的範例中不涉及真正的供應商、網域名稱註冊、訊息傳遞或驗證呼叫。
保留有用的控制並需要原始證據
這 IC3 BEC 諮詢於2020年發布，支援異常業務請求和帳戶保護的獨立驗證。它是針對這些防禦原則而引用的，而不是針對當前的攻擊統計數據或有關指定組織的聲明。身份驗證、接收者保護和業務流程控制應該相輔相成。不要因為身份驗證無法確定意圖而刪除身份驗證，也不要僅僅因為身份驗證通過而授予信任。
目錄需要經過編輯的濫用場景，包括身份證據、控制邊界和獨立的業務驗證。原始證據仍然存在；虛構的場景並不能取代。沒有存取可疑端點，沒有收集憑證，也沒有聯絡第三方。人類專家審查、當前來源適用性、生產路線、視覺可訪問性和所有者發布也保持開放。可發布的版本需要授權證據來證明驗證網域和信任其聲稱代表的組織或操作之間的確切區別。