確定訊息聲稱的內容
訊息可以透過多種不同的方式模仿業務。 It may put the business's exact domain in the visible From address, use a familiar person's display name with an unrelated address, or send from a different domain chosen to resemble the business.這些不是可以互換的機制。它們需要不同的證據並暴露不同的控制邊界。將這三種情況稱為 DMARC 失敗會鼓勵錯誤的修復，並可能隱藏需要業務驗證而不是DNS編輯的事件。
RFC 9989 將DMARC範圍限制為 RFC5322 .來自 網域和一致的身份驗證。它明確排除顯示名稱攻擊、內容分析和網域以外實體的身份驗證。接收者仍然可以應用額外的保護，但這些保護不應歸因於DMARC本身。本文提供了一種防禦性分類的分類方法，沒有對指定寄件者進行真正的郵件檢查或指控。
精確域使用需要精確比較
從解析的寄件者地址中的實際網域開始，而不是郵件應用程式顯示的顯示文字。將其與與請求相關的業務領域進行比較。在有限的調查記錄中保留準確的拼字和證據來源。 If the domains are identical, the next question is whether trusted receiver evidence shows aligned authentication, failure, absence of policy or an indeterminate result.僅憑精確的域外觀並不能告訴您發生了什麼。
使用確切網域的未經授權的寄件者可能會失敗 結盟，但受損的授權帳戶或服務可能會產生一致的郵件。因此，相同的可見域可能出現在非常不同的事件中。 DMARC通行證並不能證明該郵件已被某人批准，且失敗本身也不能證明存在惡意意圖。轉發、配置錯誤和不完整的證據可能會使解釋變得複雜。在指定原因之前先陳述狹隘觀察到的事實。
顯示名稱是一個單獨的身份表面
RFC 5322，第 3.4 節，區分郵箱的可選顯示名稱及其位址。顯示名稱可以向讀者識別人員或角色，而無需成為DMARC評估的域。例如，一則虛構的訊息可能會顯示“Accounts Team”，而其位址屬於不相關的範例網域。熟悉的標籤並不是組織所有權的證明。
小螢幕或折疊視圖可能無法乍一看顯示每個身分欄位。 The defensive action is to inspect the full address using the receiving application's trusted interface and then evaluate the business request independently.不要發明通用的 UI 規則或承諾每個客戶都會突出顯示不匹配的情況。標準對標籤和地址的區分是穩定的；呈現和保護警告取決於客戶和接收者。
相似域名可以成功驗證
由於拼字、標點符號或字元選擇，不同的領域可能在視覺上與受信任的域相似。如果其運營商合法地控制其發送設置，則來自該網域的郵件可以透過 SPF, DKIM 以及該域的DMARC 。身份驗證不一定發生故障。接收者對預期組織的辨識失敗或在不同層面被操縱。
將實際網域與從可疑訊息外部取得的可信任業務記錄進行比較。請勿僅為了確定所有權而造訪所提供的網站或回覆有問題的地址。將熟悉的品牌詞嵌入較長的名稱中是不夠的。仔細保留國際化名稱解釋，如果顯示形式和底層形式不同，請尋求合格的分析；該草案沒有提供完整的 Unicode 或公共後綴分類演算法。
使用可信的身份驗證證據
一個 Authentication-Results 此欄位僅在接收者的信任邊界內有用。 RFC 8601 解釋了為什麼消費者必須區分受信任的身份驗證斷言和訊息中攜帶的任意欄位。從轉發的訊息或螢幕截圖複製一行表示「通過」的行並不能證明相關接收者產生了該行。記錄哪個接收者評估了該訊息以及調查員如何獲得結果。
保持可見的 From 域， 信封寄件人 域、 DKIM签名域和回复身份不同。他們的差異可能有合理的解釋，不應自動歸結為詐欺調查結果。對於DMARC ，確定對齊的身份驗證路徑，而不是將每個SPF或DKIM通行證視為足夠。對於業務請求，請檢查所要求的操作以及據稱執行該操作的人員的權限。
身份比較工作表
Prepare a row containing the trusted business domain, visible display label, parsed From address, Reply-To address if present, authenticated domains, receiver result, evidence provenance and proposed classification.添加未知內容請求的列獨立渠道可以驗證哪個獨立渠道可以驗證哪個內容請求的列獨立渠道。最大限度地減少任何共享版本中的個人標識符，同時保留兩個域是否相同或不同。將所有值變更為一個佔位符會破壞工作表應顯示的關係。
使用三個臨時類別：精確域使用、顯示名稱模仿和不同域相似性。允許組合和未解決的類別。訊息可以使用誤導性的顯示名稱和 相似域名。當一致的郵件似乎來自真實組織時，工作表也應該允許授權帳戶妥協作為假設。分類是進行調查的一種方式，而不是意圖或責任的最終確定。
三個訊息的虛構比較
想像一下，一個虛構的財務團隊收到與北橋範例相關的三個異常請求。第一個具有北橋的確切域，但受信任的接收器證據表明沒有對齊的傳遞。第二個使用財務長的顯示名稱和一個不相關的地址，該地址針對其自己的網域進行身份驗證。第三個使用看起來相似但不同的網域，並且還對該網域進行身份驗證。這些是發明的觀察結果，而不是在這項工作中收集的資訊。
第一個案例導致身份驗證和發送路徑調查。第二個導致顯示名稱和業務權限驗證。第三個導致域比較和模擬處理。沒有一個僅僅因為出現熟悉的名字就保證付款，並且沒有一個應該通過將不相關的發件人添加到北橋的來“修復” SPF記錄。 If a fourth message passes alignment using Northbridge's actual domain, account or service compromise remains possible and requires its own evidence.
驗證訊息之外的請求
這 IC3雲端電子郵件BEC諮詢於 2020 年發布，建議透過已知的聯絡方式對可疑業務請求進行驗證。它的年齡是明確的：它支援一般控制，而不是關於當前事件或特定接收器的當前介面的聲明。 Use a number or workflow already recorded independently, and verify the specific change requested rather than merely asking whether someone sent an email.
所需的經過編輯的濫用場景（包括身份證據、控制邊界和獨立業務驗證）仍未實現。這篇手稿的虛構比較並不能滿足它。沒有查詢任何帳戶，沒有存取可疑網域，也沒有聯絡任何一方。 Before release, retain authorized real evidence, have a qualified reviewer validate the classification, confirm source applicability and production routes, complete accessibility review, and obtain owner approval。