从 信封发件人 以及可见的发件人地址。 TurboSMTP 参考将其 SPF 信封地址域上的授权。成功的SMTP登录证明有权向中继提交邮件；它并不证明收件人将验证您选择的发件人域。
发布适用的中继认证记录
官方示例授权include:spf.turbo-smtp.com.如果适用，将该机制合并到单个现有SPF策略中，位于其终端所有机制之前。在未确定这些授权和失败语义是否是预期的情况下，请勿将示例的 a、mx 或?all复制到已建立的策略中。
该参考提供了 Turbo-smtp 的TXT公钥。 _domainkey 。从官方参考或提供商确认的配置中复制当前的完整密钥，而不是从 选择器 姓名。确认实际的传出签名使用该选择器和您预期的签名域。该页面包含不一致的句子 DMARC 部分： DMARC属于_dmarc .<domain>，如其自己的表所示，而不是DKIM选择器。遵循该所有者名称的DMARC标准。 TurboSMTP 配置参考
请勿将现有的强制策略替换为页面的强制策略 p=none 示例仅用于完成设置。供应商的交付语言并不是收件箱保证。如果您的帐户公开不同的身份验证值，请在更改DNS之前与支持人员解决差异并保留帐户特定的说明。
验证DNS和真实的接收结果
在更改SMTP中继发件人配置之前，导出现有DNS值、记录批准的差异并指定回滚所有者。确认DNS编辑器需要相对标签还是完全限定名称；加倍域名后缀会创建 一个记录 没有预期的验证者会发现。保存后查询实际所有者名称，包括任何 CNAME 目标，而不是依靠编辑的成功旗帜。
SPF必须在相关域中保留一项策略，并保持在 DNS 查询术语限制内 RFC 7208。添加包含本身并不建立 结盟。在下面 RFC 9989，当至少有一个成功SPF DMARC DKIM 结果与适用模式下可见的 From 域对齐。不需要将两种机制对齐作为标准强加的条件，并且不要将提供商域通行证误认为是对齐的客户域通行证。
将通过生产中使用的相同SMTP凭据和应用程序提交的消息发送到您控制的邮箱。保存接收系统的可信身份验证结果、可见发件人、信封身份、 DKIM d= 和 s= 值、时间戳和提供商状态。 DNS查找仅显示可用的密钥； RFC 6376 验证还评估接收到的消息的签名。使用非敏感内容并避免将完整的客户消息暴露给公共检查人员。
使用有界接受和回滚决策
一个说明性的接受案例是来自alerts@example.com的消息，并使用d=example.com.该精确域匹配支持任一模式下的DKIM对齐。仅使用d=vendor.example.net有效签名与example.com不一致；如果没有对齐SPF ，该样本将无法通过DMARC验收测试。这些是推理示例，不是观察到的 TurboSMTP 结果。
如果测试失败，请在进行另一次更改之前将丢失的DNS 、错误的选择器、不活动的提供商配置、意外的路由和消息修改分开。每次批准的更正后重新测试相同的工作流程。不要削弱整个域的DMARC策略来隐藏单个发件人问题。在需要回滚的情况下，恢复批准的先前路由或发件人配置并保留关键记录，而排队的签名消息仍然需要它们。将测试证据和未解决的异常与域清单一起保存。在准备本指南时未执行租户访问、 DNS更改或实际发送。
将放错位置的策略与工作签名分开
书面案例 TS-01 假设在错误DNS编辑之前收到的消息来自alerts@example.org和受信任的DKIM传递，其中d=example.org, s=turbo-smtp.这提供了精确的DKIM对齐。另外，管理员错误地将DMARC TXT值放置在turbo-smtp._domainkey.example.org ； _dmarc.example.org上的实际政策未知。该错误的值对于所需的发现所有者来说不是可用的DMARC策略，并且将其与关键数据混合需要进行调查。 DNS所有者应保留正确的公钥并在_dmarc.example.org上协调预期策略，而不替换现有的强制措施。假设的签名结果不能验证错误的DNS更改。没有检查或更改任何消息、密钥或区域。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。