将发送域视为协调的 Sailthru 启动
在生产邮件准备就绪之前，Sailthru 发送域需要的不仅仅是可见的DNS记录。此次发布应结合域身份验证、提供商支持、有效的发件人邮箱和受控传递测试。从目标发件人地址中的 at 符号后的确切域开始。记录哪些帐户和业务消息将使用它，并将营销活动与配置不同的任何交易路线分开。
赛尔特鲁的 新发送域指导 要求进行DNS设置并与其团队一起审查斜坡计划。它还将此审核应用于帐户中已存在但未积极使用的域。具有记录的休眠域不应被视为具有已建立的发送信誉。认证准备情况和量产准备情况是单独的决定。
本指南涵盖身份验证设置和证据收集，而不是收件箱放置或通用发送量计划的承诺。使用当前帐户的批准设置和提供商联系人来解决任何不匹配问题。在组织完成下面的工作表和测试之前，真实帐户、 DNS和标头验证仍处于待处理状态。
进行更改之前检查严格对齐
阅读现有的 DMARC 政策并记录其 结盟 注册域之前的模式。赛尔特鲁的 配置DNS记录指南 明确指出不支持严格的 adkim 或 aspf。如果组织所需的策略使用任一严格模式，请将兼容性视为与 Sailthru 和安全所有者的开放设计决策。不要默默地删除这些标签或削弱策略来完成设置清单。
将目标发件人域和更广泛的组织的合法邮件路由一起考虑。对共享域策略的单独调整可能会影响员工邮件、财务应用程序和其他服务。如果建议使用不同的发送域，请在使用之前评估其策略上下文和业务影响。子域并不是自动成为每个继承策略或发件人声誉问题的安全例外。
在下面 RFC 9989, DMARC pass 需要成功 SPF 或者 DKIM 使用与 From 域一致的身份进行身份验证。宽松和严格的比较有所不同，因此验收工作表必须说明适用哪种模式。不要仅仅因为提供商已识别DNS 记录而将身份验证通过报告为对齐通过。
准备记录集并检查依赖关系
获取域的当前 Sailthru 说明并保留所有受影响的DNS所有者的基线。已发布的设置包括SPF包含、两个DKIM CNAME 和一个反弹域 CNAME。根据实际发件人域检查其完整名称和目标。子域发件人需要相应的全名；省略标签可以配置与活动使用的身份不同的身份。
对于SPF ，请在相关所有者处查看整个政策 RFC 7208。保留一项SPF策略，保留其他所需的发件人并考虑嵌套的 DNS 查询术语。提供者包含是一种持续的授权，而不是无害的评论。未经批准，请勿插入不同指南中的所有历史示例或替换现有的终端限定符。
按用途区分DNS任务。 DKIM验证签名。反弹域配置支持信封标识。所有权或反馈环验证记录有其自身的功能。链接域和跟踪域是独立的操作依赖项。成功的链接重定向并不能证明DKIM处于活动状态，经过身份验证的消息也不能证明每个旧的营销活动链接仍然可用。
发布DKIM委托和完整的提供商支持
当前的 Sailthru 指南指定了两个DKIM CNAME，并要求提供商在它们激活发送之前完成设置。使用“发件人”域的确切当前所有者和目标，并在发布后检查这两条记录。不要假设创建一个明显有效的 选择器 就足够了，或者DNS存在会自动触发激活。
保存前检查建议名称处的现有记录。 CNAME冲突需要依赖服务的管理员解决。不要在同一所有者处合并不兼容的数据，或者在没有提供商支持的情况下发明不同的选择器。检查DNS编辑器的自动后缀处理，并将最终完全合格的答案与说明进行比较。
保留提供商的激活确认的清晰记录。询问新消息应在什么时间开始使用该配置，然后在该时间点之后发送新的测试。重复使用旧消息可能会显示早期配置并误导审核。等待期间重复进行DNS编辑可能会产生多个重叠的缓存状态，并使诊断变得更加困难。
分别验证退回邮件身份和发件人邮箱
确认账户设置说明中的退回域名CNAME和实际情况 Return-Path 激活后观察。已发布的别名并不能证明特定发送路由使用它。如果收到的信封标识不同，则保留结果并询问 Sailthru 哪个设置或配置步骤控制该路由。不要重复更改根SPF策略来补偿无法解释的信封身份。
启用提供商后，通过设置和验证电子邮件进行记录的发件人地址验证。发件人邮箱必须能够接收验证邮件。使用由组织控制的邮箱并确定负责回复客户回复的人员。即使身份验证成功，如果收件箱没有正常运行，显示名称或营销别名也会造成操作问题。
在安排 Google Postmaster 或反馈循环访问时，请将技术记录与访问批准分开。设置指南包括提供商协作步骤，但共享监控访问权限仍然是组织决策。仅向经过验证的收件人授予批准的访问权限。不要仅仅为了加快启动速度而将凭据或不相关的域信息放入启动工作表中。
使用真实的竞选路线证明一致性
通过与预期活动相同的帐户、发件人选择和处理路径发送无害的测试。使用完整标头可用的受控外部收件人。对任何实质上不同的交易或品牌路线重复上述步骤。记录消息 ID、UTC 时间以及相关活动或测试参考，而不保留不必要的收件人内容。
捕获可见的 From、 Return-Path 、每个DKIM d= 和 s= 值以及可信接收者结果。 RFC 6376 将DKIM签名域和选择器连接到DNS验证密钥。检查传递的签名是否属于对齐的域，而不是依赖于通用的绿色结果。如果存在多个签名，请确定哪一个签名提供相关通行证。
将观察到的包络域与预期的反射配置和 From 域进行比较。记录SPF是否通过、是否对齐以及DKIM是否独立提供对齐。将它们保留为单独的字段，以便以后对一种机制的更改不会删除另一种机制的知识。认证成功是必要的证据，但内容、接收者的期望和 发件人信誉 还是会影响发货的。
保留工作联系并进行狭义诊断
如果部署还更改了链接域，请在删除任何以前的设置之前清点旧的营销活动依赖项。 Sailthru 的DNS指南警告说，删除旧链接域可能会破坏旧邮件中的链接。因此，身份验证清理应仅限于已批准停用的记录，而不是广泛清除每个不熟悉的 Sailthru 相关名称。
对于缺少DKIM情况，请首先检查提供商启用情况和所选的发件人域。对于失败的签名，请检查实际选择器、 DNS应答以及任何后续消息修改。对于传递机制的DMARC失败，请检查对齐和严格模式兼容性保持。对于从未发送过的邮件，请先检查帐户和活动证据，然后再假定问题是由DNS引起的。
与交付能力所有者一起保留斜坡决定。经过技术验证的新发送者仍然需要商定的数量和节奏计划。不要因为一项测试成功到达而释放整个观众。保存测试证据、开放的例外情况和供应商信件，以便可以审查生产决策。
Sailthru 启动工作表
- 帐户、品牌、工作流程和预期来源域：____。
- 企业主、 DNS管理员和提供商联系人：____。
- 现有DMARC策略和严格模式兼容性决策：____。
- SPF政策审查和嵌套查找评估：____。
- 两者都发布了DKIM CNAME 和公共查找结果：____。
- 反弹域配置和观察到的Return-Path ：____。
- 提供商激活和发件人地址验证：____。
- 监控访问批准和任何单独的链接域更改：____。
- 测试消息 ID、可信结果和一致机制：____。
- 斜坡计划、未解决的例外情况和发布批准者：____。
过早启动决定的虚构示例
仅虚构的书面案例：ST-01 假设来自offers@news.example.org ，现有策略要求adkim=s,以及休眠发件人上的DNS记录。不存在提供商兼容性异常、当前的斜坡计划或接收到的消息结果。启动所有者必须在批量调度之前解决记录的与安全所有者和提供商之间的严格模式不兼容问题，而无需默默更改策略。 DNS存在不会关闭任何一扇门。未检查任何域名、帐户或活动。
保持不受支持的范围和发布门可见
除非 Sailthru 提供当前支持的解决方案，否则严格对齐部署仍不属于本指南支持的配置范围。实时租户审查、帐户发布记录、 DNS和标头验证、目视审查和 SME 人工批准仍待完成。这是未发布的实施草案，而不是已完成的域启动。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。