按服务器和应用程序列出域清单
应检查实际发送消息的服务器或子帐户的 SocketLabs 身份验证。 Start with a list of applications, visible From domains and the SocketLabs configuration each application uses.包括不同的子域、客户品牌和后备路线。 One working brand is insufficient evidence for a server that sends on behalf of several organizations.
提供商要求验证发送域，并在不允许地址时记录错误。它通过地址确认过程或合格的DNS身份验证功能支持所有权验证，同时注意到帐户配置和计划会影响发送域控制的应用。 SocketLabs 发送域，添加和验证发送域.
将提交权限与接收者的身份验证分开。可以允许在没有所需客户域的情况下发送域 DKIM 或正在使用的信封标识。将这些记录为独立检查，并在授权客户或合作伙伴身份之前获得域所有者的许可。
与密钥所有者一起选择DKIM方法
SocketLabs 记录了三种方法：客户提供的TXT密钥、提供商生成的TXT密钥和提供商管理的 TXT 密钥 CNAME。这种选择会改变谁管理密钥以及如何跨服务器维护密钥。目前的概述表明签名需要与发件人身份匹配。 SocketLabs DKIM overview, the three signing methods.
在DNS工作开始之前记录决定。对于提供商管理的方法，确定谁可以更改签名配置。对于客户控制的方法，请确定私钥托管人和批准的轮换流程。充满密钥的电子表格不是可接受的所有权记录。工作表应包含证据参考和负责人，而不是秘密材料。
不要自动选择最复杂的方法，因为它公开了更多的控件。首选满足组织要求并可由其实际操作员维护的受支持方法。如果策略需要特定的密钥管理安排或不寻常的签名身份，请在提供支持的配置之前获得提供商确认。
配置所选的签名方法
对于CNAME签名，官方指南描述了启用该功能之前的一个委托DNS记录和帐户端验证。 CNAME指南列出了 dkim。发送域下的_domainkey指向dkim._domainkey.email-od.com 。将公开记录的货币对与经常账户指令进行比较；不要覆盖已占用的 选择器 只是因为该示例与其名称相匹配。如果DNS主机无法支持CNAME所有者所需的下划线，则指南会引导用户使用TXT方法，而不是发明的拼写。 SocketLabs CNAME签名指南.
Check whether the intended selector owner is already used by another service. A CNAME cannot safely be pasted over an unrelated selector. Request a supported alternative or an approved migration instead.在实施票证中保留现有记录、其依赖服务和变更决策。
TXT指南区分了在平台中生成密钥和携带密钥对。它需要DNS中的公钥并在保存相关设置之前验证该密钥。 The generated-key flow keeps its private component in the account. SocketLabs TXT签名指南.
如果所选方法涉及导入私人材料，请使用经批准的秘密处理工作流程。仅发布公钥。 Record the exact domain and selector and inspect the resulting logical TXT value after any DNS-editor string splitting. The generated-key guide says the public key is no longer available in the portal after successful DNS publication and saving.在关闭设置票证之前保留公共记录及其来源，而不在审核包中保留私钥。
将退回域配置为单独的映射
SocketLabs 实现客户域 SPF 通过其自定义弹跳域模型，无需添加现有的可见来源 SPF记录。其指南指定从所选跳出子域到tracking.socketlabs.com CNAME 。可配置多个退回条目；不匹配的邮件使用选定的默认值或提供商后备。 SocketLabs 自定义弹跳指南、设置和多个自定义弹跳域.
与DNS管理员一起选择一个未使用的名称，并确认实际服务器中支持的映射。保持域的普通入站邮件配置不变。退回主机名是应用程序交付身份，不应与用户的回复邮箱或网站的跟踪端点混淆。
记录每个 From 域的预期匹配，然后记录默认行为。默认值值得在多品牌服务器上进行明确的业务审查：成功的交付仍然可能暴露意外的品牌或提供商身份。不要仅从配置中的名称推断活动映射。发射的 Return-Path 是以后比较的证据。
发布并比较公共记录
在进行批准的更改之前导出相关的DNS记录。 Confirm the authoritative service and the DNS editor's handling of relative names.独立检查每个已发布的所有者，包括其CNAME链或TXT答案。正确的DKIM记录并不能证明退回名称已配置，正确的退回记录也不能证明DKIM签名处于活动状态。
SPF is evaluated using the SMTP envelope identity, not simply the visible From.如果其他服务仍需要根域的SPF策略，请保留它。 At any owner where an SPF policy is required, maintain one policy and check the protocol's DNS-querying term limit. RFC 7208 ，第 2.4、4.5 和 4.6.4 节.
等待涉及缓存的一致权威和递归答案。如果提供商无法验证 一个记录，保存发布的值和定时DNS观察以获取支持，而不是重复更改名称。 DNS 主机限制应通过记录的支持方法来处理。
测试每个精确的来自域和跳出匹配
Send harmless content through each material application and server to controlled external recipients. Preserve time, Message-ID and the provider or application event reference. Test From subdomains separately rather than assuming an entry for the parent domain covers them.
旧的CNAME页面在其适用性描述中提到了 PRA 和发件人，而当前的概述和TXT页面则描述了精确的“发件人”匹配。 If the application uses a separate Sender header or other unusual identity, obtain clarification and test that exact form.不要默默地将这些不同的陈述转化为普遍规则。
在收件人处，记录可见的 From、 Return-Path 、可信SPF身份和结果、每个DKIM d 和 s，以及 DMARC 结果。 DKIM验证使用实际签名中的域和选择器来定位公钥。 RFC 6376 ，第 3.5 和 6.1 节.
将每个通过的身份与适用的可见 From 进行比较 结盟 模式。自定义跳出子域可能满足宽松的SPF对齐，而不满足严格的平等。整齐划一的传球 DKIM签名 可以独立满足DMARC 。成功的域验证和提供商域身份验证都不足以推断整个结果。 RFC 9989 ，标识符对齐解释和DMARC评估.
诊断故障层
对于发件人不允许的错误，请在更改DNS密钥之前检查验证和正确的服务器域控制。对于意外的签名域，请将确切的发件人与配置的DKIM条目进行比较。对于意外的Return-Path ，请检查反弹匹配和默认值。将这些检查分开进行，这样对一项的修复就不会掩盖另一项的问题。
如果尽管DNS正确，加密验证仍失败，请调查路径上签名内容或标头的更改。如果身份验证和对齐通过，但收件箱位置不佳，请调查收件人的过滤、声誉和邮件的目的。身份验证并不承诺交付或使授权帐户的每次使用都合法。
发布前记录恢复情况
完成 SocketLabs 域和服务器工作表（使用此处描述的字段创建单独的审核记录）。保留逐条路由的权限矩阵、签名方法、反弹映射和收到的证据。确定谁可以在测试失败时暂停应用程序或恢复之前批准的服务器配置。
当排队的消息或其他服务器依赖旧的公钥或退回记录时，请勿删除它们。与应用程序所有者一起计划停用，并在更改发件人域、服务器、密钥方法、退回默认值或DNS提供商后重新测试。
涉及默认退回条目的虚构诊断案例
仅虚构的书面案例：SOCK-01 假设一台服务器发送来自news@alpha.example邮件，其中包含信封bounces.alpha.example和通过的SPF结果。第二条路线使用 From news@beta.example但回退到bounces.alpha.example ，也使用SPF pass。在宽松对齐下，第一个规定的包络线对齐；第二个没有。两个DKIM结果都是未知的，因此既没有声称第二条消息完全失败，也没有声称修复成功。服务器所有者必须批准并验证 beta 的映射，然后检查其发出的Return-Path和DKIM 。未执行服务器、 DNS或消息测试。
仍在等待接受
当目标服务器允许该域时，接受路由，所选签名方法进行验证，每个弹跳映射都表现为已批准的行为，并且接收者证据建立了所需的对齐通行证。对于这份未发布的草案，原始范围验收、实时租户和DNS检查、独立技术审查、目视审查和 SME 人工批准仍有待完成。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。