确定发送域和活动范围
在安排身份验证之前选择批准的发件人域。记录 WordFly 帐户、活动所有者、 DNS管理员以及即将举行的活动将使用的确切发件人地址。在库存中包括自动化活动和测试发送。预览消息或提供商拥有的发件人地址不足以证明使用组织域的活动。
WordFly 专用 DKIM 本文介绍了使用wordfly.com和客户的发送域进行双重签名，并需要发布提供的自定义DKIM记录和 DMARC记录 在安全发送之前。其更广泛的发送指南对于自定义签名的具体语言较少。使用专用的身份验证工作流程并验证实际的客户域签名，而不是依赖旧的一般措辞。 自定义DKIM, 发送指南.
与 WordFly 协调发布
向已批准域的 WordFly 支持请求自定义DKIM公共记录。发布提供的 TXT记录 在权威DNS处，然后告诉支持人员已准备好进行验证。该文档建议留出两到三天的时间进行设置和测试。不要假设仅DNS发布即可完成提供商激活，从而安排最后一刻的完整活动。 WordFly DKIM设置.
将支持说明、所有者姓名、记录类型和完整的公共值与更改请求一起保存。检查DNS编辑器是否附加了域后缀以及其他记录是否占用了建议的名称。使用当前提供的支持 选择器 而不是将公共文章的示例视为不可变的帐户设置。切勿发布私人签名密钥。
保持SPF和DMARC决策的区别
WordFly 的发送指南称已发布 SPF 为其发送域并验证 返回路径 或者 退回地址。这确定了提供商的SPF角色；它不证明客户的自定义信封域或客户域SPF 结盟。不要添加猜测的顶点包含来创建对齐的错误外观。检查测试消息上的实际信封域。 WordFly 发送指南.
与其所有者一起查看组织的现有DMARC记录。在启动竞选路线时保留已批准的政策和报告安排。传递的客户域 DKIM签名 即使提供商拥有的SPF未对齐，也可以提供对齐的路径。使用域的实际对齐模式将观察到的 d= 值与可见的 From 进行匹配。 DMARC.
在真实工作流程中检查两个签名
仅在提供商验证后才将受控活动发送给授权测试接收者。保留原始消息和接收系统的身份验证结果。不要停在第一个dkim=pass结果：确定哪个签名通过以及其域是否对齐。
- 合成签名案例： d=wordfly.com通行证；含义：提供者签名验证；下一步决定：单独检查客户签名
- 合成签名案例： d=example.com通过 From news@example.com ；含义：本例中的精确域对齐；下一步决定：确认接收者 DMARC 并保留证据
- 合成签名案例：客户签名失败，提供商签名通过；含义：仅提供者身份验证不足以满足该 From 的要求；下一个决定：调查客户选择器和签名消息的完整性
这些是合成案例，不是观察到的 WordFly 交付。记录每对 d= 和 s=，以便第二个通过的签名无法隐藏失败的客户签名。测试最终的活动内容路径，包括对目标受众重要的任何链接处理或转发路线。收件箱放置是与身份验证接受分开的观察。
启动活动前进行修复
如果DNS正确但缺少客户签名，请确认提供商端激活和活动选择的“来自域”。如果签名失败，则比较选择器查找并保留接收者的失败原因。向支持人员提供适合其安全支持渠道的经过编辑的原始或诊断详细信息。不要生成不相关的替换密钥或删除提供者签名。
当身份验证证据不完整时，保留受影响的活动。当计划轮换时，按照提供商的转换说明，让旧的选择器可用于排队的邮件。修复后，重复原始测试并在发布前获得活动所有者的认可。归档已验证的记录集，支持确认并收到原件。广告系列停用后，查看休眠帐户和选择器。该草稿不包含真实账户访问、 DNS更改或发送的活动证据。
确认提供商边界
详细指南显示wordfly02。 _domainkey作为其公共示例；比较确切的当前支持指令，而不是猜测或覆盖占用的选择器。它还需要一个邮政局长邮箱。保持启动检查订阅者权限、有效的取消订阅链接和合适的 热身 计划与DNS验证分开。这些是发送指南的要求和建议，并不能证明此活动合规或已交付。
完成一个虚构的诊断案例
仅虚构的书面案例：WFL-01 假设来自news@theatre.example ，通过的d=wordfly.com签名和失败的d=theatre.example签名。信封和SPF结果未知。提供商签名未对齐，但证据并未证明DMARC完全失败，因为SPF仍然未知。邮件所有者必须与支持人员一起检查客户选择器和失败原因，然后重复批准的最终内容测试。不要删除提供者签名以使结果看起来更简单。此案例没有测试任何帐户、 DNS 、CRM、发票、活动或交付。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。