提供商可以如实报告其邮件已通过 DKIM 使用与您的可见发件人地址无关的域进行签名时。如果目标是验证您组织的作者域 DMARC，请求支持的一致DKIM身份并定义如何对其进行验证。启用DKIM一般请求过于模糊。
从来自实际服务和路线的受控消息开始。保留其原始接收形式和可信接收者结果。这为提供商提供了具体的身份不匹配来进行调查，而无需假设产品在每个计划或传输上都提供自定义域签名。
分别说明身份
记录可见的From域， 信封发件人 身份， SPF 结果，每个DKIM d 域， 选择器 和验证结果。放 结盟 在一个单独的字段中。 RFC 9989 §4.4 将身份验证成功和标识符对齐视为不同的要求；不相关的传递DKIM域不会对齐，因为它属于发送提供商。
严格的DKIM对齐需要精确的域匹配 RFC 9989 §3.2.10。宽松对齐比较下的组织域 RFC 9989 §4.10.2。询问提供商实际上可以发出哪个 d 域，然后将其与您预期的 From 域和策略进行比较。在提供商确认支持的身份和帐户配置之前，请勿请求特定的DNS值。
清楚地显示误导性通行证
说明性身份工作表：
- 仅提供者身份：From= brand.example ； d=provider.example;假定DKIM通行证；不对齐，假设这些是不相关的组织域。
- 客户身份：From= brand.example ； d=brand.example;假定DKIM通行证；精确的域匹配。
假设出于本示例的目的而显示结果。它们不是收到消息测试的证据。在第一种情况下， DMARC仍可能通过对齐的SPF ，因此在未检查信封身份和SPF结果的情况下，请勿声明整体DMARC失败。该工作表隔离所请求的DKIM属性。
发送精确的技术请求
询问提供商指定的产品、帐户计划和发送路线是否支持与预期发件人地址一致的客户控制的签名域。包括 API、 SMTP 、活动或事务路由详细信息（如果适用）。询问别名、子域和委派用户的行为是否有所不同。
请求准确的选择器名称、 DNS记录类型和值、激活步骤和验证程序。询问谁控制私钥、如何执行轮换以及下线后验证记录会发生什么情况。如果一个 CNAME 是必需的，确认其目标和范围，而不是用猜测来替换它 TXT记录.
共享经过编辑的身份工作表或受控测试消息，而不是包含不必要的个人内容的客户消息。提供商支持请求不需要私人签名密钥或邮箱密码。将敏感凭证与普通票据分开。
更改DNS之前同意接受标准
有用的验收测试需要来自实际生产等效路线的新消息，即通过的预期消息 DKIM签名 在受信任的接收者处并根据相关政策进行调整。分别测试重要的消息格式和路由。仅仅发布DNS记录或查看经过验证的徽章并不是完整的证据。
如果提供商也添加了自己的签名，请检查两者。允许多个签名 RFC 6376 §4.2，并且传递的对齐签名提供了下面的DKIM路径 RFC 9989 §4.4.1。记录实际观察到的选择器和 d 域，而不是依赖标头工具显示的第一个签名。
诚实地处理不支持的能力
如果自定义对齐的DKIM不可用，请询问支持的替代方案及其限制。通过对齐的SPF路径可能满足适用直接路由的DMARC ，但它不会创建对齐的DKIM或通过转发保证弹性； RFC 7208 §10.3 讨论SPF介体的局限性。组织的要求可能需要不同的受支持的发送身份或服务。
使用商定的身份、路由、 DNS所有权、密钥保管人和收到的消息证据来关闭请求。如果某个功能仍然不受支持，请明确记录它。结果应该是可验证的发送设计，而不是承诺任何DKIM通行证都可以证明您的品牌身份。
记录下一个决定
在联系支持之前准备好这些字段：产品和路线；意图来自；观察到的 d/s 和可信结果；所需的对齐方式；能力问题；请求生成的DNS指令；关键保管人；轮换和退出问题；和验收标准。编辑不必要的个人数据。这是技术请求清单，而不是发送的票证、批准的DNS更改或配置服务的证明。