确定 Rocketseed 更改消息的位置
Rocketseed 在商业电子邮件中添加品牌和签名，因此在处理完成后必须检查身份验证。从实际的出站路由开始：员工的邮箱平台、使用的 Rocketseed 服务、任何后续安全网关以及接收邮箱。直接从邮箱平台发送的成功测试可能会错过客户接收的路线。本指南涵盖了路由边界、提供商协助的 DKIM 激活和区域 SPF 审查。它并不声称任何客户的域或连接器已经过验证。
创建其消息通过 Rocketseed 传递的域和应用程序的清单。包括共享邮箱、委派发件人和自动消息（如果它们使用此路径）。将 Rocketseed 云与 Rocketmailer 以及在外部投递之前将邮件返回到其他服务的任何部署区分开来。请服务所有者根据当前配置确认此清单。不要仅从签名的外观推断最终的发送基础设施。
在发布记录之前与 Rocketseed 同意更改
火箭种子公司 配置DKIM指令 描述一个协调的过程：通过 Rocketseed 联系人请求签名，接收TXT值，发布它，然后在 Rocketseed 验证记录后安排激活。因此，发布记录只是设置的一个阶段，而不是签名已经开始的证据。获取确切的DNS所有者及其值，并将约定的激活时间保留在更改记录中。
对于多域组织，询问请求涵盖哪些域以及不同的路由是否需要单独配置。将答案与已部署的帐户相关联。本文不提供通用的 选择器, 公钥, 自定义 Return-Path 程序或自助激活按钮。如果支持人员提供的说明与公共指南不同，请保留这些特定于帐户的说明并在更改生产之前解决差异。
指定一位可以查看生成的外部消息的管理员和一位可以暂停受影响的发送的企业主。根据支持的路由定义恢复，而不仅仅是删除DNS记录。禁用品牌、绕过中继或更改连接器可能会产生身份验证之外的后果，应作为单独批准的路由更改进行处理。
查看正确的区域SPF授权
火箭种子公司 SPF页面 将其指令应用于 Rocketseed 云和 Rocketmailer。它列出了欧洲、美洲和非洲的区域性内容。通过 Rocketseed 确认实际服务区域，而不是从进行更改的人员的办公地点中选择值。特定于区域的说明是与提供商对话的证据，而不是向组织策略添加所有区域的权限。
将该页面上的示例视为片段，以便在完整的SPF策略中进行审查。请勿复制“的页面描述”PTR记录” 作为创建反向DNS的指令。SPF SPF以TXT形式发布在 RFC 7208，协议评估SMTP 邮件来自 身份，单独处理 HELO。在决定策略更改所属的位置之前，确定最终出站路由实际使用的信封域。
导出该所有者的现有SPF策略。保留对其他活动发件人的授权，检查完整的查找成本并避免第二个SPF策略。 DNS 查询机制和修改器在评估期间共享协议限制为 10。添加一个明显较短的包含可能会带来嵌套查找。如果策略已经接近限制，请停止并与邮件管理员一起设计支持的更改，而不是删除不熟悉的服务。
发布已颁发的DKIM记录而不打扰其他发件人
记录 Rocketseed 提供的完整所有者、类型、值和 TTL。检查DNS编辑器是否自动附加区域名称。保存后，验证完整的公共所有者，而不是信任表单的显示。重复的后缀可能会在错误的位置留下令人信服的记录，而接收者使用的选择器仍然不存在。
检查提议所有者处的任何现有记录。与其他服务或早期密钥的冲突需要协调的答案。请勿覆盖活动选择器、发明替代选择器或复制其他客户的密钥。只有公开的验证材料才属于DNS ；私人签名密钥和服务凭据不得出现在工作表或支持包中。
一旦DNS答案与发布的值匹配，请要求 Rocketseed 完成其记录的验证和激活。捕获响应以及应签署新消息的时间。保持旧基线可用，但不要仅仅因为提供者尚未达到计划的激活窗口而删除新发布的密钥。
品牌化后和最终网关后进行测试
通过普通品牌路由将无害的邮件发送到受控的外部邮箱。对每个明显不同的发件人域和路由路径重复此操作。测试不应包含真实的客户信息。保留消息 ID 和 UTC 时间，以便邮件管理员和 Rocketseed 可以关联同一投递，而无需交换整个邮箱历史记录。
读取接收者可信的身份验证结果。捕获可见的 From 域、 Return-Path 、每个DKIM d= 签名域和 s= 选择器，以及最终的发送源（如果可用）。 RFC 6376 定义签名域和选择器如何查找验证密钥。如果稍后处理更改签名内容，邮箱平台的签名可能会失败。在完整的路线之后检查幸存的结果，而不是假设最早的签名仍然有效。
申请 RFC 9989 到观察到的身份： DMARC 需要与发件人域一致的通过SPF或DKIM结果。不相关服务域下的传递签名本身并不提供以下内容 结盟。记录哪个机构提供对齐路径和有效的对齐模式。成功的收件箱放置、 TLS传输或品牌页脚不能替代该证据。
一次诊断一个边界
如果DKIM不存在，请首先确认提供程序激活以及测试是否遍历了预期的 Rocketseed 路径。如果签名存在但失败，请将其选择器与公共DNS进行比较，并在签名后调查更改。当路线本身不确定时，避免重复请求新密钥。新密钥无法修复应用相关签名后修改的消息。
如果SPF通过但DMARC失败，请将经过身份验证的信封域与可见的发件人进行比较。当评估另一个域时，向 From 域添加授权可能不会起任何作用。如果两种机制都失败，请在一次更改多个控件之前保留拒绝或接收结果。将DNS查找问题、未经批准的发送源和内容签名问题分开记录在事件记录中。
保留组织现有的DMARC策略，除非其所有者批准更广泛的更改。 Rocketseed 的推出并不授权削弱对每个发件人的保护。同样，不要用白名单代替外部检查：本地绕过可以使测试看起来成功，而客户仍然收到未对齐的邮件。
Rocketseed 路线工作表
每个不同的域和路由完成一份工作表：
- 企业主和批准的发送用途：____。
- 邮箱平台、Rocketseed 服务和区域：____。
- 包括任何后续网关的完整路线：____。
- 预期来源和观察到的信封域：____。
- 现有SPF所有者、完整的政策和查找审核：____。
- 发行的DKIM所有者、公开价值和 TTL：____。
- DNS观察时间和 Rocketseed 激活确认：____。
- 测试消息 ID、UTC 时间和受控接收器：____。
- DKIM d= 和s=, SPF结果和对齐的DMARC机制：____。
- 恢复所有者、未解决的异常和重新测试日期：____。
将缺少的激活确认或接收结果视为未清项目。诚实地记录失败的测试而不是对待发布 一个记录 作为闭包。
签名路由故障的虚构示例
仅虚构的书面案例：RS-01 假设来自staff@example.org ，早期邮箱平台签名失败，品牌化后带有d=example.org ，已发布的提供商颁发的公钥，并且 Rocketseed 激活仍待处理。 SPF和更高版本的签名未知，因此无法断言完整的DMARC判决。路线所有者应确认计划的激活，然后在所有处理后获取新的外部样本，而不是重新生成密钥或绕过品牌。没有检查任何帐户或消息。
在验证之前保持部署审查开放
更改品牌、连接器、发送域或下游网关后重新测试。保留提供者的指示和接受者的证据以及批准的变更。实时租户检查、当前帐户发布的记录、实时DNS和标头检查、目视审查和 SME 人工批准仍然悬而未决。这是未发布的实施草案，而不是完整的身份验证部署。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。