可重复的入职流程从客户边界开始。在收集报告或提出DNS更改建议之前，确定哪些法律实体、域、应用程序和管理员在范围内。共享服务不应从销售电子表格或公共DNS查找中出现的域推断客户权限。
建立服务边界
列出客户发起人、技术所有者、 DNS托管人、MSP 分析师、变更批准人和事件联系人的名称。记录他们的职责和后备覆盖范围。通过商定的入职流程验证权限，并仅授予当前阶段所需的范围访问权限。读取报告和更改身份验证记录是不同的权限。
创建一个发件人注册表，其中包括业务目的、应用程序所有者、可见发件人域、信封域、签名域和预期活动周期。包括定期服务和小批量服务。短观察窗口内的缺席并不能证明服务未被使用。 RFC 9990 汇总报告 描述报告的消息活动；它们不是权威的应用程序清单。
通过阶段性验收
首先接受清点、取证。接下来评估已知的发送路径并解释故障。然后提出具有精确差异、批准和回滚条件的更改。最后使用来自实际应用程序的消息和接收方结果验证预期的流程。 DMARC 依赖于 结盟 也 SPF 或者 DKIM 认证下 RFC 9989，所以通用的 pass 标签是不够的。
不要仅仅因为模板显示加入已完成而将每个域移至强制策略。记录异常、未解决的发件人、转发者和邮件列表路径。定义谁接受残余风险以及何时审查证据。策略决策必须遵循客户的邮件依赖性和授权。
将两个入职保留分开
假设客户的计费应用程序具有当前授权的对齐通过样本，而其季度通知程序尚未运行且其备用DNS审批程序未确认。接受其测试范围的计费证据，将通知者保留为未经测试，并在依赖它之前解决批准回退问题。完整的接收清单无法将这些差距转化为操作验收。
这些是假设的入职决策，而不是提供的客户操作手册或执行的完整性检查。对于每个阶段，记录负责人、准确的验收证据和未解决的情况。在退出计划时，需要通过负责的系统确认访问撤销，而不是承诺未来的脚本将删除它。此处不声明任何客户批准、 DNS写入或报告摄取。
移交运营并规划退出
为客户提供当前的域名注册、批准的配置、开放的例外情况和升级路线。指定报告的可用性、监控范围和保留责任。解释 MSP 可以测量什么以及什么取决于客户、 DNS主机和接收者。成功的身份验证并不保证收件箱的放置。
退出计划应确定导出格式、授权接收者、访问撤销、保留审计证据和删除责任。在下线期间不要自动删除有用的身份验证记录：客户可能仍然依赖它们。转移技术责任，测试持续的邮件流并根据批准的计划取消访问权限。每当所有权、应用程序或关键业务流程发生变化时，请检查服务。