解析哪个 Sarbacane 服务正在发送
“Sarbacane”不是一个足够精确的DNS更改请求。检查的第一方文档包括 Campaigns 委托子域程序和单独的 Sendkit 手动记录程序。在此审核期间，外观通用的域配置 URL 重定向到明确标题为 Sendkit 的页面。该差异决定了哪些指令属于变更单。
要求帐户所有者确定产品、帐户以及实际的营销活动或应用途径。将屏幕截图或管理参考私下保存在更改记录中。不要通过复制来验证营销活动 SPF 值或 DKIM 密钥来自 Sendkit 文章，只是因为两者都位于 Sarbacane 帮助中心。本指南以营销活动为主导，解释了 Sendkit 边界，并留下任何不受支持的路线，而不是猜测。
这 个性化发送域活动说明 将共享服务域与组织自身的身份区分开来。在配置任何内容之前确定接收者应该看到哪些身份。品牌显示名称和包含您公司名称的链接不能替代该决定。
在委托之前检查子域
选择一个具有记录的所有者和用途的命名空间。清点其现有记录、依赖项、委派子项、链接和应用程序。在浏览器中看起来未使用的子域仍然可以支持邮件、验证记录或其他服务。在没有经过审查的迁移计划的情况下，请勿对现有生产用途进行新的委派。
记录哪个团队管理父域以及哪一方将代表委派的子域。在工单中明确建议的边界。更改注册商 名称服务器 为整个域添加 NS 记录与为一个子区域添加 NS 记录有本质上的不同。后者一定不会意外地成为前者，因为DNS接口使用类似的标签。
同时记录现有的 DMARC 适用于预期发件人域的策略。身份验证设置并不授权替换该策略或更改报告收件人。如果选择新的发送子域，请要求域所有者查看有效的策略并 结盟 模式而不是假设子域与父域决策隔离。
关注 Campaigns 账户发放的授权
这 活动主办指南“Prérequis”和“Étapes（例如avec OVH）” 要求已在营销活动中创建子域，并且配置授权窗口的配置窗口可用。它指示管理员从该窗口获取值，将所有权TXT放在根域中，并将提供的两个 NS 目标添加到所选子域中。相关的故障排除指南最多允许 48 小时进行验证，并指出托管对委派的支持各不相同。
在打开DNS编辑器之前记录每个颁发的所有者、类型和值。确认接口对相对所有者与完全限定名称的处理。对于所有权令牌，请勿将父域位置与新创建的发送子域混淆。对于 NS 记录，验证两个目标值是否与帐户说明匹配，并且所有者是预期的子域。
保留不相关的 TXT记录，包括现有的SPF和验证值。所有权令牌不是创建或替换SPF策略的指令。保留DNS导出前后以及发布的确切时间。使用权威的DNS答案验证委托，而不仅仅是应用程序的绿色指示器或托管控制面板的保存状态。
不要发明名称服务器目标或复制帮助文章中显示的示例域。如果所选DNS主机无法支持所需的委派，请停止该路由并向 Sarbacane 询问支持的方法。更改托管提供商或购买新域名是一个单独的决定，而不是自动修复。
诊断无效域名，无需盲目删除
这 活动“无效”文章、计时和验证部分 区分普通传播和域创建后 48 小时以上添加的记录。对于延迟设置的情况，它描述了在营销活动中删除并重新添加域以重新启动激活，同时保留DNS记录。它还重申了父TXT和子 NS 位置。
使用这些区别作为诊断序列。首先将实际的DNS所有者和值与帐户进行比较。接下来确定域的创建时间以及记录的公开时间。然后确定是否存在附加到该域的现有营销活动。历史计时补救措施是不允许在不了解其依赖关系的情况下删除生产对象。
如果支持人员建议重新添加活动域，请获取范围变更计划并记录必须恢复的内容。保留当前的战役设置和旧状态的证据。执行任何恢复操作后，重复域验证和接收消息测试；仅更改应用程序状态并不能证明每个计划的活动都使用恢复的身份。
保留Sendkit手动记录在自己的更改中
这 Sendkit 域页面、所需记录和域验证部分 记录该服务的SPF 、 DKIM 、 MX 、 A 和跟踪域配置。它描述了 1024 位和 2048 位 DKIM选项，推荐 2048 位。其验证要求包括SPF 、 DKIM 、 MX和跟踪。这些是特定于产品的说明，而不是 Campaigns NS 授权程序。
对于 Sendkit 部署，启动单独的记录清单并将当前帐户说明与页面进行比较。请勿替换现有的邮件接收MX或网站 一个记录 只是为了满足清单。与产品所有者建立合适的域并支持处理传入回复和退回邮件。如果来源的示例与帐户发布的设置冲突，请在发布之前获取提供商的答案。
跟踪主机名可能与提供商的域验证和链接信誉相关，但它不是DMARC验证的域。将验证、返回路由和发件人身份验证作为单独的接受字段进行跟踪。本次审查并未建立单一的习惯 Return-Path 工作流程在所有 Sarbacane 服务中有效。
发送后验证身份验证
帐户报告域准备就绪后，通过实际产品向受控外部邮箱发送小型无害活动。记录活动标识符和 UTC 时间。包括代表性链接和回复行为，但不包括客户列表或私人客户内容。如果范围内有多个帐户、域或自动化路由，请测试每个有意义的变体。
捕获可见的发件人域、 Return-Path或接收者报告的信封身份、每个DKIM签名域和 选择器，以及接收系统的可信认证结果。 RFC 6376 ，第 3.5 节 定义DKIM d= 和 s= 字段。确认为观察到的签名找到的公钥属于配置的路由。请勿根据DNS权限被委托的事实来推断签名。
RFC 7208 ，第 2.3 节和 4.6.4 节 解释了 邮件来自 身份和SPF查找限制。如果已确认的产品需要手动更改SPF ，请检查整个现有策略和嵌套查找。请勿添加第二个策略或未经其他发件人授权盲目复制完整样本。
申请 RFC 9989 ，第 4.4 节，“标识符对齐解释” 到收到的身份。记录对齐的传递机制，而不仅仅是仪表板中的三个绿色标签。一个路过的 DKIM签名 在不相关的服务域下不会建立您的源域对齐。当涉及父域和子域时，严格和宽松的对齐也可能导致不同的结论。
完成产品和领域工作表
使用以下字段为 Sarbacane 产品和授权工作表创建单独的审核记录。它使活动和 Sendkit 决策保持可见，将所有权验证与身份验证分开，并提供DNS权限、应用程序状态、接收的身份和恢复字段。首先完善产品领域。如果未知，请记录谁将确认该信息，并且不要继续使用最容易找到的文章。
对于委派区域，保留父方 NS 证据和子方生成的身份验证答案。对于手动记录设置，请保留每条预期记录及其实时答案。在这两种情况下，请将接收者证据与同一帐户和活动相关联。这些工件可以让未来的管理员区分提供者端配置问题和父区域错误。
虚构的示例：错误服务的正确记录
仅虚构的书面案例：SC-01 假设所有者请求来自news@updates.example的活动，而DNS票证引用了 Sendkit 密钥。尚未收集帐户发放的活动所有权令牌和子域名服务器； DKIM 、 SPF和接收者身份未知。营销所有者确认产品， DNS所有者持有不匹配的票证，检索正确的委派并检查未使用的子区域。批准仍处于开放状态，等待产品验证和接收消息身份检查。未访问任何帐户、 DNS记录或消息。
设定恢复和维护边界
如果委派破坏了现有依赖性，请暂停新的活动并与DNS所有者和 Sarbacane 协调恢复。仅恢复之前检查过的配置。删除委托还可以删除对其下方的身份验证或跟踪记录的访问权限，因此重置警告图标并不是一种无害的方法。将已缓存的DNS和正在运行的消息保留在恢复计划中。
产品迁移、域更改、委派更改或新引入的自动化后重新检查。当前帐户值、对所选路由的自定义信封支持、实时DNS和标头证据在此仍未得到验证。最初的广泛 Sarbacane 范围将被搁置，直到确切的产品得到确认。这是一份未发布的文件草案，尚待目视审查和 SME 人工批准。
将传递的消息与执行准备情况分开
RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。