可重複的入職流程從客戶邊界開始。在收集報告或提出DNS更改建議之前，確定哪些法律實體、網域、應用程式和管理員在範圍內。共享服務不應從銷售電子表格或公共DNS查找中出現的網域推斷客戶權限。
建立服務邊界
列出客戶發起人、技術所有者、 DNS託管人、MSP 分析師、變更批准人和事件聯絡人的名稱。記錄他們的職責和後備覆蓋範圍。透過商定的入職流程驗證權限，並僅授予目前階段所需的範圍存取權限。讀取報告和更改身份驗證記錄是不同的權限。
建立一個寄件者註冊表，其中包括業務目的、應用程式擁有者、可見寄件者網域、信封網域、簽章網域和預期活動週期。包括定期服務和小批量服務。短觀察窗口內的缺席並不能證明服務未被使用。 RFC 9990 總結報告 描述報告的訊息活動；它們不是權威的應用程式清單。
透過階段性驗收
首先接受清點、取證。接下來評估已知的發送路徑並解釋故障。然後提出具有精確差異、批准和回滾條件的變更。最後使用來自實際應用程式的訊息和接收方結果來驗證預期的流程。 DMARC 依賴於 結盟 也 SPF 或者 DKIM 認證下 RFC 9989，所以通用的 pass 標籤是不夠的。
不要因為範本顯示加入已完成而將每個網域移至強制策略。記錄異常、未解決的寄件者、轉送者和郵件清單路徑。定義誰接受殘餘風險以及何時審查證據。策略決策必須遵循客戶的郵件依賴性和授權。
將兩個入職保留分開
假設客戶的計費應用程式具有當前授權的對齊通過樣本，而其季度通知程序尚未運行且其備用DNS審批程序未確認。接受其測試範圍的計費證據，將通知者保留為未經測試，並在依賴它之前解決批准回退問題。完整的接收清單無法將這些差距轉化為操作驗收。
這些是假設的入職決策，而不是提供的客戶操作手冊或執行的完整性檢查。對於每個階段，記錄負責人、準確的驗收證據和未解決的情況。在退出計劃時，需要透過負責的系統確認存取撤銷，而不是承諾未來的腳本將刪除它。此處不聲明任何客戶批准、 DNS寫入或報告攝取。
移交營運並規劃退出
為客戶提供當前的網域註冊、批准的配置、開放的例外情況和升級路線。指定報告的可用性、監控範圍和保留責任。解釋 MSP 可以測量什麼以及什麼取決於客戶、 DNS主機和接收者。成功的身份驗證並不保證收件匣的放置。
退出計畫應確定匯出格式、授權接收者、存取撤銷、保留稽核證據和刪除責任。在下線期間不要自動刪除有用的身份驗證記錄：客戶可能仍然依賴它們。轉移技術責任，測試持續的郵件流並根據批准的計劃取消存取權限。每當所有權、應用程式或關鍵業務流程發生變化時，請檢查服務。