公民可以在一次申请期间收到来自中央部门、机构门户网站和签约提醒服务的邮件。成功的邮箱迁移并不能证明后两者的情况。在更改身份验证策略之前映射服务旅程，并在公民依赖消息的点上拥有所有权。
遵循服务而不是组织结构图
选择一项公共服务旅程，例如申请许可证。列出提交收据、更多信息请求、预约通知和最终决定通知。记录触发每条消息的应用程序、服务提供者、其租户、可见的From地址、 信封发件人, DKIM 域和 选择器，以及负责的企业主。部门地址簿不会透露所有这些系统。
单独的域注册控制、委托DNS控制和应用程序管理。机构可以拥有其申请，而上级部门则发布其记录；承包商可以配置签名，但双方都不能批准对方的更改。指定接受用户影响的服务所有者和可以执行更改的技术所有者。请勿将熟悉的看似政府的显示名称视为任一权威机构的证据。
建立委托域边界
对于每个委托机构域，检查其实际DNS和适用的 DMARC 策略而不是假设中央域设置按预期覆盖它。记录它是否发送、接收或仅作为网址存在。记录承包商授权的发送范围及其结束日期。自定义DKIM设置和信封身份应针对特定租户进行验证，而不是从其他机构的配置复制。
下面的路线图特意包含了一个承包商，该承包商假定在提供商的域下具有传递签名，但与代理机构的 From 域并不完全一致。纠正任务是调查批准的对齐路径，而不是授权该提供商拥有的每个地址。从经过验证的服务中获取新的值，进行狭窄的更改并在更广泛的实施之前测试真实的路线。
在变更期间保护服务连续性
围绕低频但重要的流程安排测试，包括拒绝申请或请求丢失文件。每月的大量新闻通讯并不能充分替代。与服务运营商就如何升级失败的测试、公民如何独立检查其应用程序状态以及谁可以停止推出达成一致。不要将真实的公民记录发送给测试收件人。
使用带有日期的变更记录以及之前的状态证据、预期身份、审批者、操作员和回滚操作。在确认排队和重复消息已移动后，通过协调的离职计划取消承包商的访问和签名权限。每当机构被委派新的DNS控制、门户更改供应商或中央邮箱迁移开始时，请查看路线图。任何政府授权或保留义务都需要特定司法管辖区的法律验证；本指南没有提出普遍的监管要求。
完成三份书面路线记录
这些保留的示例域、选择器、角色和传递的DKIM前提都是虚构的。对于这些情况，不提供或执行任何签名消息、密钥、加密验证、 DNS查找、 SMTP事务或实时服务测试。不需要测试代码或外部样本来检查以下推理。
- 公民门户：从域portal.civic.example可见； DKIM d=portal.civic.example;选择器演示1；假设DKIM仅针对此书面案例通过。 SPF 身份和结果未知的邮件；其他签名未知；实际的政策发现和交付未知。提议的所有者：数字服务所有者。下一步操作：获取该租户的授权样本和可信接收器结果。
- 委托代理机构：来自域名agency.civic.example可见； DKIM d=agency.civic.example;选择器演示2；假设DKIM仅针对此书面案例通过。 SPF MAIL FROM 身份和结果未知；其他签名未知；实际的政策发现和交付未知。提议的所有者：代理通讯所有者。下一步操作：确认此单独的路由及其业务事件，而不是继承第一个路由的结果。
- 承包商提醒：可从域notices.civic.example可见； DKIM d=provider.example.net;选择器演示3；假设DKIM仅针对此书面案例通过。 SPF MAIL FROM 身份和结果未知；其他签名未知；实际的政策发现和交付未知。拟议业主：合同经理。下一步行动：向经过验证的供应商询问该租户支持的一致签名路径；不要将授权扩大到整个网络。
对于前两个规定的签名，d=恰好等于From域，因此标识符满足严格和宽松 结盟。鉴于规定的成功DKIM结果，这些假设消息存在一致的身份验证路径。第三个签名者故意与作者域无关，并且无法提供一致的路径。不要将第三条消息称为DMARC失败：对齐SPF或其他对齐传递 DKIM签名 仍然可以满足该机制，并且这些输入是未知的。不要从任何行推断真实的部署或收件箱位置。
加密签名验证签名域的责任，而不是每条指令的真实性或授权。对覆盖的规范化字节的更改可能会使签名无效；并非每个可见的编辑都必然会更改签名的输入。身份验证和应用程序级接受仍然是分开的。
分配具体的发布决策
对于虚构的许可旅程 P-01，数字服务所有者接受收据覆盖范围，机构所有者接受决策通知覆盖范围，合同经理获取提醒租户配置。 DNS运营商仅实施经过批准的精确差异；仅应用程序访问并不授权该差异。如果承包商无法展示一致的路线，请保持该路线悬而未决，并暂停受影响的政策变更，而不是宣布整个旅程已准备就绪。在承诺连续性之前记录已批准的替代状态检查路径及其人员配置。这些所有者或文物均未在此处得到验证。
应用标准而不声明合规
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 节 将服务器接受责任与后来的交付结果区分开来。这里的部门工作流程选择是编辑建议；法律范围、因素适用性和当地授权需要进行自己负责任的审查。