市場可以在沒有被授權驗證商家網域的情況下傳遞商家的話語。區分業務內容的編寫者、寄件者中顯示的網域以及郵件流由哪個服務執行。這些角色可能屬於三個不同的團體。熟悉的商家顯示名稱並不能解決網域名稱身分問題。
選擇預期的作者身份
對於平台發起的訂單通知，應使用平台認可的身份，並在內容中明確商家關係。對於商家品牌路由，請在啟用之前驗證商家網域的控制權以及身分驗證所需的特定委託。請勿接受商家輸入的網域名稱作為控制權證明，或將其他賣家的配置複製到新租戶。
工作地圖將平台訂單通知、商家回應和支援更新分開。將每個項目分配給指定的整合或服務所有者。記錄寄件者是平台所有還是商家所有，哪個租戶可以觸發郵件以及誰可以輪換或撤銷簽名配置。回覆位址可以直接與商家對話，而無需將該位址設為 DMARC 作者身份。
測試允許的和未對齊的情況
虛構的商人案例在 From 中顯示了 seller.test，同時簽名為 market.test。即使假設簽名已驗證，它也無法嚴格通過 DKIM 結盟 與賣家.測試。路線圖中的平台順序和支援標識與其各自的From域相符；這些是假設的配置，而不是觀察到的測試。這說明了為什麼平台成功簽名本身並不授權使用賣家的身份。
選擇誠實支援的設計：具有明確商家屬性的平台擁有的寄件人，或經過正確驗證的商家網域配置。後者需要記錄的權限和範圍內的存取權限。記錄批准的租戶、域名、 選擇器、 DNS證明和撤銷所有者。這些是評估系統的建議，而不是聲稱特定市場或EmailAuth實現了它們。
在驗收測試中保持租戶的權威
加密通行證無法揭示是否允許錯誤的賣家帳戶選擇網域名稱。新增負面應用測試：第二個商家不得作為第一個商家發送，過期的委託不得保持可用，刪除商家必須關閉相關發送路徑。僅在授權的測試環境中執行此類測試，並將實際系統結果與這些假設身分分開保存。
將共享 IP 盤點為基礎設施證據，而不是商家身分。一個平台系列可以承載許多租戶，包括受損的租戶。不要因為一個訂單通知是合法的就將該範圍內的所有訊息列入白名單。
規劃關係的結束
定義當商家離開時如何處理排隊訊息、回覆和公開支援對話。撤銷確切的授權而不干擾無關商家。僅保留平台有權保留的報告和審計證據。消費者資訊揭露、商家合約、資料共享條款和支付責任需要經過合格審查； DKIM和此路線圖都不會裁定它們。
虛構的路線圖
以下顯式身分是說明性輸入，而不是真實的客戶配置。這些網域和負責的角色是假設的，而不是客戶批准或提供的簽署訊息。未執行任何加密測試或交付。
- 平台訂單通知：平台訊息引導；來自訂單.市場.測試；信封和DKIM簽署者 order.market.test。
- 商家留言：商家整合引領；來自賣家.測試；信封和DKIM簽署者 market.test。
- 平台支援：客戶支援主導；來自支援.市場.測試；信封和DKIM簽署者 support.market.test。
簽署結果前檢查補助金
假設商家 A 已批准範圍域配置，但商家 B 可以透過平台的寄件者選擇器選擇它。產生的郵件上正確對齊的簽名不會修復該應用程式授權失敗。保持路線，保留允許的診斷證據，並使用授權的測試帳戶測試實際的租戶/物件邊界。不要僅僅為了演示問題而發送即時冒充訊息。
OWASP 的多租戶指南，第 1、3 和 5 節，支援受信任的租戶上下文和資源授權，包括延遲工作。 RFC 9989第 4.4 節及 5.3.5 節 將DKIM對齊與完整訊息判決區分開來：必須評估其他對齊的身份驗證路徑。第 7.4 節和第 8 節要求有效的DKIM p=reject 部署而不是依賴 SPF 獨自的。未執行商戶授予、選拔測試或簽約操作。