将计划限制为记录的漂移发送域
官方的“Drift - 设置电子邮件发送域（DKIM)”页面的日期为 2026 年 10 月 6 日，出现在 Legacy Drift 下。它描述了从 Premium 开始的付费计划、管理员受众和每个实例一个发送域。所示路线包括后备电子邮件和会议提醒。其路径为“设置”、“应用程序设置”、“聊天机器人”、“通信”，然后是“编辑发送域”。添加域开始设置；查看和验证DNS设置公开所需的帐户特定条目。通过授权DNS运营商发布这些条目并完成验证。其 SPF FAQ 提供了特定路线的发送地址，而不是每个相关产品的通用配方。 漂移发送域指南
本手稿仅适用于该有限的工作流程。它不会验证连接的个人邮箱、每个漂移电子邮件机器人路由、具有相似名称的其他供应商或暗示的后续产品。实际的订阅、接口、发送身份和生成的记录尚未检查。因此，尽管记录的工作流程可以为有用的变更计划提供信息，但更广泛的目录实施要求仍然开放。
在发布前解决单域决策
实例级发送身份是组织决策。在任何人请求记录之前，列出共享实例的团队、范围内的消息类别以及每个团队预期的可见发件人地址。如果涉及多个品牌或客户组织，请确定谁有权选择域以及谁可以批准使用该身份。不要假设单个完成的域设置会自动授权每个不相关的品牌地址。
实用的规划记录应确定当前域、建议域、任何更改的原因以及可能受影响的消息类别。将预期的回复行为保留为单独的字段。收件人可以看到一个作者地址，而回复则定向到其他地方，并且这两个字段都不能单独识别用于SPF SMTP信封。记录应明确这些区别，而无需收集不必要的私人信件。
如果可用的产品配置无法满足预期的身份要求，请保留产品适合的决策，而不是构建猜测的DNS记录。 DNS管理员无法通过向区域添加更多选择器或域来增强应用程序功能。同样，当现有路由、批准和收件人期望依赖于应用程序中的域时，更改应用程序中的域并不是无害的显示编辑。这是提议的治理，而不是声称任何特定帐户都具有这些依赖性。
将生成的记录视为受控切换
当授权管理员获取已批准的更改记录时，捕获实际帐户指令。将记录所有者、类型和完整值以及发送域和帐户上下文保留为单独的字段。避免从屏幕截图手动重建公钥或复制 选择器 来自另一个组织。公共DNS数据可以与负责的DNS运营商共享；私钥和账户凭证不属于本次交接。
A DKIM签名 包含一个选择器和签名域，告诉接收者在哪里找到验证材料。这种协议关系就是为什么确切的所有者名称很重要。以外观相似但不同的名称发布密钥并不会使该密钥可供实际引用另一个选择器的签名使用。发布密钥也不能证明应用程序使用其相应的私有材料签署了消息。 RFC 6376 ，第 3.5 节和3.6.2.2节
输入记录之前检查 DNS 编辑器的行为。预期的完全限定名称应独立于编辑器的主机或名称字段编写。一些接口将区域后缀附加到相关输入；运营商必须遵循实际DNS主机的规则，而不是通用的快捷方式。 DNS主文件约定和提供商的图形编辑器不是可互换的指令。保留源值并将生成的已发布所有者与其进行比较。 RFC 1035 ，第 5.1 节
将TXT格式与关键策略分开
TXT资源记录可以包含多个字符串。因此，长逻辑值可能会在DNS接口中出现分割，而不会成为多个独立记录。区分字符串边界 一个记录 来自同一所有者的单独资源记录值。确认验证者期望的逻辑内容，而不是将换行或表示引用视为新密钥的证据。 RFC 1035 ，第 3.3.14 节
密钥长度选择也与DNS格式化分开。应用当前支持的实施要求和组织的安全策略；不要将旧的接口默认值转换为通用加密建议。如果支持的选择与组织要求相冲突，请让负责的管理员做出决定。本文不会生成密钥、提供私人材料或声明特定密钥选择已在租户中得到验证。
公共记录只是接受的一部分。变更所有者需要应用程序预期签名配置的证据，并且在单独安排授权测试后，实际收到的签名。绿色域状态可以是有用的操作信息，但不应取代消息级审核。将配置状态和观察到的身份验证结果保留在不同的工作表字段中。
协调SPF而不替换不相关的发件人
任何建议的SPF授权必须与当前路由和实际使用的SMTP身份匹配。不要假设为一项应用程序功能记录的值适用于同一公司系列中的所有产品。在提出策略更改之前获取当前适用的出口详细信息，并保留现有的合法发件人，而不是用简短的示例替换整个策略。
SPF评估相关 邮件来自 身份，与 HELO 在适用的情况下使用。其策略发布为TXT ，并且多个适用的SPF策略不会组合成更大的权限集。 DNS 查询评估限制涉及评估的术语，包括嵌套依赖项，而不仅仅是明显列出的顶级包含的数量。无论应用程序的帐户状态如何，这些协议规则都适用。 RFC 7208 ，第 2.3–2.4、3.1–3.3 和 4.6.4 节
通过的SPF结果仍然可能与可见的 From 域不对齐。同样，有效的DKIM签名可以识别不满足要求的不同域 结盟 关系。 DMARC 接受符合资格的SPF或DKIM结果，但它不会将每个不相关的通过都转化为成功。在得出结论之前记录实际身份和结果。 RFC 9989 ，第 4.4 节
虚构的诊断：错误的证据回答了问题
想象一下一个虚构的企业 Fernline Services，其运营团队正在准备发送域更改。 DNS运营商确认公共 TXT记录 存在。然后，另一个团队从普通员工邮箱中发出一条成功消息，并宣布申请已准备就绪。这两种观察本身都无法确定预期应用程序路由如何对其消息进行签名。这是一个虚构的复习练习；没有测试任何帐户或消息。
审查员将证据分开。 DNS记录与帐户的实际指令进行比较，而员工邮箱消息则被分类为不同路由的证据。在获得来自预期类别的授权样本之前，计划的应用消息仍处于未经验证状态。该团队不会削弱DMARC 、覆盖其他发件人的SPF授权或仅仅为了关闭清单而推断广泛的产品支持。
空白路线验收工作表
- 适用的 Drift 产品、计划、实例和当前文档检查：____。
- 批准的发送域名和企业主：____。
- 范围内的消息类别和排除的路由：____。
- 预期可见的发件人、回复地址和信封标识：____。
- 实际生成的DNS所有者、类型、值和来源参考：____。
- 权威DNS运营商和完全合格的所有者审核：____。
- 现有SPF发件人和建议的路由授权：____。
- 应用程序验证状态、时间戳和未解决的错误：____。
- 授权接收消息选择器、签名域和对齐结果：____。
- 回滚条件、关键策略决策和发布批准人：____。
工作表故意未填写。原始证据、人工/中小企业审查、来源适用性、生产路线、视觉/可访问性审查和所有者发布仍然开放。未执行任何租户操作、 DNS更改、密钥创建或消息。即使成功的身份验证也不能保证收件箱的放置或确定业务请求是安全的。 RFC 9989 ，第 2.4 节