确定路线
TOPdesk 可以使用其 SaaS 邮件服务器或组织的邮件服务器。这个过程涵盖了SaaS路线；如果您的组织通过自己的服务器进行中继，请改为获取该服务器的身份验证说明。在编辑DNS之前记录发送工作流程和预期的发件人域。本指南未执行任何帐户配置或实时测试。
授权 SaaS 发送
TOPdesk 的当前源指示管理员将include:spf.topdesk.net合并到现有的 SPF 而不是列出各个服务器。请求特定于域的 DKIM 以及通过 My TOPdesk 申请表进行的域限制。域限制将域的使用限制在 TOPdesk 环境中。获取用于DNS和激活的帐户说明；此公共页面不提供通用的 选择器 或钥匙。不要根据较旧的第三方配方即兴上传私钥。请参阅下面的 TOPdesk 源代码。
原创服务台验收设计
使用一份手动触发的票证通知和一份自动工作流程通知，每个通知仅发送至受控测试邮箱。记录发送每条消息的路由。将实际的起始值与批准的列表进行比较；不要假设操作员通知和后台自动化共享一个发送者。将返回的DKIM设置说明与DNS证据一起保留，而不暴露凭据。
票证中包含单独的安全检查：在请求限制之前识别必须使用该域的每个合法 TOPdesk 环境。不完整的环境清单可能会破坏真正的服务台工作流程。验收设计要求提供该清单和请求结果，但不声明已应用或测试了限制。
确定失败意味着什么
提供商域的SPF通行证本身并不建立 结盟 与服务台的发件人。如果DKIM通过不相关的签名域，则收集原始标头并将其与特定于域的配置请求进行比较。如果两个经过身份验证的标识符与预期的 From 不同，请停止发布并要求服务所有者解析路由。不要使用整个域 DMARC 豁免作为首次维修。
如果测试通过组织的中继成功，但通过 SaaS 失败，则这是关于两条不同路径的证据，而不是间歇性DNS证据。保留特定于路由的结果和回滚指令。仅当所有者确认其支持所需的工作流程后，受控切换回已验证的继电器才能成为恢复选项。
在接收方证明身份
使用受控的外部邮箱并通过生产工作流程发送，内容无害且无客户数据。保存原始消息、时间戳和接收系统的 Authentication-Results。忽略由不受信任的发件人插入的身份验证断言。记录可见的From域， Return-Path 或经过身份验证的信封身份，以及每个DKIM d= 和 s= 对。显示名称或回复地址不是DMARC身份。
SPF pass 授权连接服务器使用评估后的信封身份。 DKIM通行证验证其签名域的签名。 DMARC需要一个其域与可见From对齐的传递方法：严格对齐需要相同的域；宽松的对齐允许适用的组织域关系。提供商拥有的签名可以通过，无需验证您的可见发件人。一传对齐 DKIM签名 即使另一个签名失败也能满足DMARC 。这些协议规则来自RFC 7208 、 RFC 6376和 RFC 9989，如下所列。
在诊断缓存之前检查权威DNS 。向权威服务器询问确切的名称和类型，然后在其缓存生命周期后比较递归解析器。对于DKIM ，请遵循任何 CNAME 其公钥TXT响应。切勿发布私钥。对每个评估的名称保留一项SPF策略，并检查嵌套包含中的十个 DNS 查找导致术语限制。不要用提供商示例替换共享SPF策略。
恢复与验收
如果测试显示新的回归，请暂停受影响的工作流程。将更改的记录与保存的版本进行比较，并在检查其他发件人后仅撤消该更改。重新检查DNS并恢复后重新发送；恢复值不会立即刷新每个解析器。保持旧的DKIM验证记录可用，同时先前签名的邮件可能仍在传输中，除非安全事件需要撤销。
仅当DNS 、应用程序状态和实际收到的消息一致时才接受更改。记录流程所有者、证据时间戳和下一次审核触发器。收件箱放置本身并不能证明身份验证，并且成功的身份验证并不能保证收件箱放置。不要根据一个提供商的测试来收紧共享域的DMARC策略。首先盘点其他合法来源。
清点域限制前的环境
书面案例 TD-01 假设support@example.org由两个合法的 SaaS 环境（生产环境和培训环境）使用。拟议的限制请求仅列出了生产；尚未观察到这两种环境所产生的限制状态。在请求预期边界之前，服务所有者必须与安全所有者协调这两个环境，并为每个环境计划无害的手动和自动通知检查。 DNS管理员仍然需要特定于域的DKIM响应；这里没有发明选择器或键。所有消息验证结果仍然未知。未执行任何请求、限制、密钥上传或票证通知。
保留执行边界
RFC 9989第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。