人力資源系統可以發送看似內部郵件但源自於招聘平台、薪資供應商和員工服務應用程式的訊息。第一個任務是確定組織每條路線的實際帳戶和所有者。知名的供應商品牌並不能證明特定候選人的電子郵件或薪資通知已獲得雇主授權。
更改政策之前分割所有權
將招聘通知分配給招聘操作所有者，將工資通知分配給工資服務所有者，將員工更新分配給人員操作所有者。記錄供應商租戶、目的、來自身分、信封網域、 DKIM 簽名域名和 選擇器、回覆路由和核准的支援聯絡人。如果提供者為多個子公司提供服務，請記錄每個帳戶要使用的法人實體和網域，而不是將該群組視為一個無差別的寄件者。
庫存應包含營運元數據，而不是候選人簡歷、薪資詳細資料或員工識別碼。在適當的存取和保留控制下儲存任何必要的受限證據。身份驗證偵錯是不允許將人員資料複製到一般郵件故障排除票中的。
理解結果意味著什麼
RFC 9989 評估經過身份驗證的網域使用。它並不能證明錄用通知有效、薪資調整正確或招聘人員有權做出承諾。將僱用決定和銀行詳細資料變更保留在自己的驗證流程中。受到威脅的批准帳戶仍然可以發送經過身份驗證的誤導性內容。
使用受信任的接收系統結果和標頭將可見的寄件者身分與經過驗證的身分進行比較。不要依賴包含供應商徽標或寄件者插入的不受信任標頭的螢幕截圖。向供應商詢問其當前的、特定於帳戶的自訂網域程序，並保留配置證據而不暴露憑證。
無需借用工資憑證即可查看員工通知
假設候選人和薪資通知使用與其各自的發件人域匹配的簽名域，而employees.hr.example出現在員工通知的發件人中， provider.example.net是其DKIM d= 域。即使假設簽名已驗證，它也無法通過嚴格的DKIM 結盟。這些是假設的身份，而不是簽名的樣本或實際的密碼檢查。薪資結果無法消除單獨的員工通知不符問題。
RFC 9989第 4.4 節及 5.3.5 節 需要考慮其他相關的對齊路徑以獲得完整的 DMARC 結果。為了 p=reject 部署，第 7.4 節和第 8 節需要有效的DKIM ，而不是 SPF 獨自的。另外，儘管傳遞了出站訊息，但候選人回覆可能會到達錯誤的招募隊列。使用虛構記錄和受控帳戶（而不是真實的申請人或人員詳細資料）驗證核准的回覆目的地。
測試實際員工和候選人的旅程
在支援的測試環境中使用經批准的虛構申請人和員工帳戶。透過真實的應用程式工作流程觸發應用程式確認、無害的薪資通知和員工更新。確認受控接收、身份驗證和回復路由。檢查應徵者的回覆是否已到達預期的招募佇列，而不會洩露其他應徵者的詳細資料。將文件存取和內容正確性視為單獨的驗收標準。
如果供應商僅提供自己的寄件者身份，則企業主應決定明確提供的支援地址是否符合工作流程需求。請勿透過不受支援的配置偽造雇主的身份，或添加廣泛的繞過規則只是為了使測試看起來成功。重新測試支援的變更並記錄任何剩餘的限制。
保持離板與寄件者治理的聯繫
當代理合約終止、工資提供者發生變化或人力資源管理員離職時，審查授權。在廢棄密鑰或DNS相依性之前確認後續工作流程。為時間敏感的候選人和工資訊息保留指定的恢復所有者。僅當服務所有者認可當前測試證據時才標記接受的路線； DNS記錄和身份驗證通行證都不是就業、隱私或法規合規性認證。