來源 IP 可以識別傳輸路徑，而無需識別授權使用特定網域的客戶。共享服務將不相關的租戶置於公共基礎設施後方。將運輸來源、租戶授權、簽名身分和人員責任分開。有效的網域簽署是重要的證據，但上游授權錯誤可能會導致錯誤的請求到達簽署者。
陳述威脅模型和歷史證據
這裡考慮的風險是中繼信任廣泛的提供者來源，而不將該來源綁定到允許使用其簽章路由的客戶。模型中的攻擊者控制同一共享服務上的不同租戶，而不是品牌的私鑰。受影響的資產是授權網域使用和後期歸屬的準確性。這是一個歷史故障類別，而不是聲稱指定服務目前容易受到攻擊。
Guardio Labs 的原始 EchoSpoofing 報告由 Nati Tal 於 2024 年 7 月 29 日發布，描述了透過Microsoft 365和Proofpoint路由進行的濫用行為，其中未經授權的消息獲得了合法身份驗證。其揭露部分將特定於租戶的過濾描述為緩解措施，並討論了租戶元資料的來源。 原創研究。下面的書面比較說明了這一界限；它既不重現漏洞，也不評估當前供應商的實現。
將歸因欄位分開
SMTP觀察描述了訊息處理，而 DKIM 將訊息與簽章域相關聯。兩者都不能單獨確定撰寫或批准業務請求的人員。 RFC 5321 和 RFC 6376。保留受信任的接收時間、連線來源、可用的租用戶證據、來自網域和經過驗證的簽章網域作為不同的欄位。
租戶證據必須來自已建立的可信邊界。聲明允許的租戶的任意訊息標頭並不等同於經過驗證的傳輸上下文。 Authentication-Results 字段同樣需要可信來源。 RFC 8601。部署審查必須確定服務如何驗證和保護該上下文，而不僅僅是檢查欄位是否存在。
比較五個假設的授權案例
假設故意寬泛的規則允許來自來源系列共享 A 的任何請求。擬議的更窄的規則還要求獨立可信的租戶上下文等於租戶良好。這些是書面規則假設，而不是運行程式碼或供應商配置。
- Case1：共享-A；值得信賴的租戶租戶-良好；訊息聲稱租戶良好。兩項提議的規則都接受了該請求。
- 情況2：共享-A；可信任租戶租戶-其他；訊息聲明租戶-其他。廣泛的規則承認；租戶約束規則否認。
- Case3：分享-A；可信任租戶租戶-其他；訊息聲稱租戶良好。廣泛的規則承認；儘管索賠不受信任，但受租戶約束的規則仍予以否認。
- Case4：分享-A；可信任租戶不可用；訊息聲稱租戶良好。廣泛的規則承認；租戶約束規則否認證據缺失。
- 案例5：家庭外；值得信賴的租戶租戶-良好；消息聲稱租戶良好。兩條規則都拒絕，因為不符合來源家庭條件。
在思想實驗中，被承認的請求可以到達下游簽署者。沒有為此教學修訂產生金鑰、簽署訊息、執行加密檢查或發送SMTP請求。錄取決定不是 DMARC 判決或交付證明。
驗證可信上下文而不是其標籤
上面的trusted-tenant欄位是一個前提，而不是一個演示的安全機制。真正的部署必須確定如何對上下文進行身份驗證並防止訊息控制的覆蓋，包括如何處理遺失的上下文。歷史報告並不能證明今天的配置已經被揭露。使用當前的供應商指南和批准的路線證據來評估實際的簽名授權；永遠不要僅僅因為任意標頭的名稱類似於供應商字段而將其視為可信標頭。
在指定責任方之前進行關聯
對於事件，將原始訊息與授權的特定時間路線和帳戶日誌結合。共享中繼地址和有效簽名可能與授權缺陷、帳戶濫用或合法寄件者共存；這些解釋需要不同的證據。將遏制決定與指控分開。當需要租戶級歸因時，請求提供者透過批准的管道進行調查，僅共享相關的識別碼和時間。
結論包括觀察到的事實、信心、缺失的帳戶證據以及下一步的負責任行動。合理的發現可能會識別經過身份驗證的網域和共用路由，但無法解決參與者的問題。這比僅僅因為一家公司的郵件使用相同的基礎設施而將責任分配給該公司更有用。
將調查結果保留在證據範圍內
這些例子是防禦性決策輔助工具，而不是針對真實的人或目前提供者的觀察到的指控。分別保留認證證據、業務驗證和歸屬。目前協議來源描述了網域驗證和可信結果邊界；他們不提供缺失的帳戶證據或授權發布指控。