招標通知可能是真實的，但在帳戶洩露後包含未經授權的銀行詳細資訊變更。身份驗證有助於評估網域身份。採購權力來自核准的流程和負責人。設計這兩項檢查以相互加強，不允許其中一項替代另一項。
將通知對應到採購記錄
對於招標發布、供應商通知和委託採購，記錄記錄系統、通知識別碼、批准的發送者和責任承包角色。該通知應可協助供應商透過已知管道找到權威的採購記錄。避免將意外訊息中的連結視為同一訊息的獨立驗證。
記錄應用程式租戶、來自網域、信封網域、 DKIM 域和 選擇器 對於每條路線。外包採購入口網站可能具有與當局工作人員郵件分開的發送基礎設施。品牌頁尾或回覆地址不會建立一致的身份驗證路徑。將回覆處理保留在路由圖中，因為真正的通知可以將回覆導向到不同的操作信箱。
將相應的變更保留在他們自己的批准之後
根據通知要求收件人執行的操作對通知進行分類。開標公告、截止日期修改、授標通知和付款詳細資訊請求具有不同的操作後果。本指南建議使用已建立的聯絡記錄（而不是有爭議的電子郵件中提供的電話號碼）對敏感供應商或銀行變更進行單獨的採購和財務驗證。
DMARC 不檢查投標條款或確定誰批准了中標。傳遞簽名也不能證明銀行帳戶屬於目標供應商。在採購系統中保留變更權限、核准記錄和獨立審核結果。這些是工作流程建議，而不是任何司法管轄區採購法的聲明。
在截止日期之前測試委託寄件人
運行經批准的樣本以進行初步通知、修改和取消，並附有虛構的招標詳細資訊。確認預期From身份、簽名結果、適用 結盟，回覆目的地並成功取得官方記錄。簽名測試無法確定通知是否在法定截止日期之前送達。相關交付、公佈證據單獨保存。
如果承包商在活躍招標期間更換平台，請保留舊路線，直到了解批准的切換和隊列處理。設定失敗通知的擁有者和記錄的備用通知流程。不要因為整合失敗而透過新身分默默地重新提交通知。此類變更可能會讓供應商感到困惑，必須在採購團隊批准的溝通流程下處理。
重新評估面向供應商的邊界
按採購部門審查報告，而不僅僅是整個部門的郵件總量。表面上健康的聚合可能會隱藏少量的修改發送者。升級意外的簽章網域、新的回覆目的地和無主供應商帳號。在停用網域或選擇器之前，確定哪些招標記錄和定期通知仍依賴它。認證證據屬於採購審核記錄，而非取代採購審核記錄。
完成三份書面路線記錄
這些保留的範例域、選擇器、角色和傳遞的DKIM前提都是虛構的。對於這些情況，不提供或執行任何簽署訊息、金鑰、加密驗證、 DNS查找、 SMTP交易或即時服務測試。不需要測試程式碼或外部樣本來檢查以下推理。
- 招標發布：從域名tenders.civic.example可見； DKIM d=tenders.civic.example;選擇器演示1；假設DKIM僅針對此書面案例通過。 SPF 郵件來自 身份和結果未知；其他簽名未知；實際的政策發現和交付未知。擬議所有者：採購主管。下一步操作：取得該租戶的授權樣本和可信任接收器結果。
- 供應商通知：可見來自域名suppliers.civic.example ； DKIM d=suppliers.civic.example;選擇器演示2；假設DKIM僅針對此書面案例通過。 SPF MAIL FROM 身分和結果未知；其他簽名未知；實際的政策發現和交付未知。建議所有者：供應商通訊所有者。下一步操作：確認此單獨的路由及其業務事件，而不是繼承第一個路由的結果。
- 委託採購：可見來自域名contracts.civic.example ； DKIM d=provider.example.net;選擇器演示3；假設DKIM僅針對此書面案例通過。 SPF MAIL FROM 身分和結果未知；其他簽名未知；實際的政策發現和交付未知。擬議所有者：訂約機關。下一步行動：向經過驗證的供應商詢問該租用戶支援的一致簽章路徑；不要將授權擴大到整個網路。
對於前兩個規定的簽名，d= 恰好等於 From 域，因此標識符滿足嚴格對齊和寬鬆對齊。鑑於規定的成功DKIM結果，這些假設訊息存在一致的身份驗證路徑。第三個簽名者故意與作者域無關，並且無法提供一致的路徑。不要將第三條訊息稱為DMARC失敗：對齊SPF或其他對齊傳遞 DKIM簽名 仍然可以滿足該機制，並且這些輸入是未知的。不要從任何行推斷真實的部署或收件匣位置。
加密簽章驗證簽章域的責任，而不是每個指令的真實性或授權。覆蓋的規範化位元組的更改可能會使簽名無效；並非每個可見的編輯都必然會更改簽名的輸入。身份驗證和應用程式級接受仍然是分開的。
使用通知專用的受理卡
對於虛構投標T-01修訂版本2，需要核准的記錄版本、授權承包角色、寄件者身分、回覆目的地、發佈時間和收件人通知證據。如果認證通過但正式記錄仍為版本1，則停止修改並與採購進行核對；不要將其標記為已批准。如果記錄正確但通知失敗，則呼叫已核准的替代通知流程並保留時間證據。無論結果如何，變更的受益者都會觸發單獨的財務驗證流程。這些是擬議的決定，而不是採購法要求或已完成的測試。
應用標準而不聲明合規
RFC 9989第 4.4 節及 5.3.5 節 支援對齊和機制區分。它的第 7.4 節警告了間接郵件互通性：使用網域 p=reject 必須使用有效的DKIM ，而不僅僅是SPF ，且通用郵件清單的使用需要特別小心。路由清單本身並不具有強制拒絕的權限。 RFC 6376第 3.4–3.7 節和 6.1 節 描述簽名的輸入和驗證。 RFC 9990第 3.1 節 提供報告背景，而不是每個收件人的到達證明。 RFC 5321第 4.2.5 節 將伺服器接受責任與後來的交付結果區分開來。這裡的部門工作流程選擇是編輯建議；法律範圍、因素適用性和地方授權需要進行自己負責任的審查。