第三方發送者應透過入職決定進入生產，而不是透過對失敗的活動的第一次投訴。在供應商發送客戶訊息之前開始。確定誰想要該服務、它需要哪個網域權限以及受控測試如何證明預期身份在實際交付路徑中仍然存在。
收集特定於服務的請求
需要業務目的、所有者、供應商帳戶識別碼、受眾、重要性和計劃發布日期。列出來自網域的可見列表， 信封寄件人 域、簽章域和選擇器。確定誰控制DNS以及誰可以配置供應商帳戶。包括回覆、退回郵件和任何修改外寄郵件的網關。提供者的通用設定指南是有用的輸入，但它沒有為您的組織選擇正確的範圍。
將每個請求的DNS條目視為權威決策。一個 SPF include 授權評估路徑並有助於DNS查找處理；它不僅僅是一個驗證標籤。檢查有效記錄及其查找預算，而不是盲目附加供應商說明。 RFC 7208。為了 DKIM，記錄準確的 選擇器 和域，並確定密鑰和委託記錄稍後如何停用。 RFC 6376.
在應用更改之前定義接受
批准準確的建議配置和測試計劃。該計劃應包括代表性範本、預期的寄件者身分、授權收件人、真實的出站路線和要保留的證據。使用您控制並有權測試的收件人。在受信任的接收者確認身份驗證並評估 結盟 與可見的作者域。有效的供應商域簽章不會自動與您的寄件者域對齊。 RFC 9989.
新增對您的威脅模型重要的負面案例：未經批准的寄件者身分、未經批准的服務或對不相關網域進行驗證的配置。如果安全測試無法證明帳戶層級的限制，請記錄供應商控制和剩餘的不確定性。不要試圖以其他組織的身份發送來證明這一點。將核准的測試郵件與開始生產發送的許可分開。
單獨的批准、身份和路線證據
假設一個假設的計費工具被批准用於一個帳戶和來自網域。假定受控樣本具有有效的 DKIM簽名 來自不相關的供應商域。該簽名本身並不能滿足預期的對齊檢查。在斷定訊息是否通過之前檢查實際的SPF身份和每個相關的有效簽名 DMARC;即使此簽章未對齊，對齊的SPF通行證也可能滿足訊息層級規則。
現在假設一個活動工具有一個一致的通過樣本，但沒有業務批准。其技術結果不能授權發射。這兩種情況需要不同的後續步驟：調查計費身分配置並取得活動決策。它們是說明性假設，而不是執行的訊息或真正的批准。對於域名發布 p=reject, RFC 9989 第 7.4 節和第 8 節分別要求有效的DKIM簽章並禁止僅依賴SPF ；傳遞訊息並不放棄該部署義務。
發布並監控第一批生產流程
測試成功後，讓指定審核者對特定服務和身分進行授權。記錄生產開始時間，監控初始報告視窗並保持回滾或暫停路線可用。大量的成功不應掩蓋交易的失敗。在服務暫存器中記錄任何受限的啟動條件，例如一個網域或一個應用程式流程。
透過指派續約、金鑰變更和離職職責來完成入職。供應商關係會持續發展，一次性DNS成功並不能確保持續授權。完整的移交為下一個操作員提供了足夠的信息，以區分正常的更改和無法解釋的新權限。
保持發布決策的範圍
記錄審核涵蓋哪些範本、身分和路線。如果測試發現另一個提供者帳戶或網域，請返回該範圍進行審查，而不是隱式延長啟動時間。下一個所有者應該能夠識別已通過的證據和仍然開放的條件。