范围和先决条件
本指南涵盖连接到 Yandex 360 for Business 的自定义域。消费者 Yandex 地址和仅使用 Yandex 收件箱的独立应用程序是不同的路由。从组织的域管理员和控制其权威DNS人员开始。委托给 Yandex 的域有 SPF 和 DKIM 根据 Yandex 当前文档自动配置；外部DNS需要执行以下手动步骤。自动配置仍然需要接收消息测试。
配置记录的路由
- 步骤 1. 打开组织的域页面并确认确切的发送域已连接并经过验证。在更改SPF策略之前清查其他合法发件人。
- 步骤 2. 对于专门的 Yandex 发送域，记录的SPF TXT值为
v=spf1 redirect=_spf.yandex.net。如果其他服务也发送，请使用记录的文件构建一项组合策略include:_spf.yandex.net以及其他授权机制。不要附加全部旨在依赖重定向的策略机制：评估全部阻止到达重定向。 - 步骤 3. 在域上，选择为域添加DKIM 。从配置中复制其公钥 DKIM签名，而不是文档中的简短示例。
- 步骤 4. 将该密钥发布为 TXT记录 在
邮件。 _domainkey相对于发送域。某些DNS控制台需要全名。检查保存的完全限定名称以避免两次添加域。需要时记录的 TTL 为 21600 秒。 - 步骤 5. 返回到域，选择验证您的域并检查。 Yandex 警告DNS更新可能需要长达 72 小时的时间。首先诊断权威答案，而不是将该最大值视为强制等待。
产品特定风险
仅重定向SPF策略对于同时向其他地方发送发票或营销邮件的域来说是一个糟糕的盲目替代方案。将这些发件人保留在单一策略中。如果DKIM仍未验证，请比较完整的公钥、 TXT所有者和活动密钥 名称服务器。切勿粘贴示例截断密钥。绿色域屏幕并不能证明应用程序实际上是通过预期的 Yandex 路由提交的。
证明接收端的路由
使用批准的外部邮箱并保存完整的原始消息及其时间戳和消息标识符。本指南中没有声称进行现场租户测试。以下是实施期间需要完成的验收工作表，而不是 一个记录 观察到的结果。
- 证据字段：Visible From；记录内容：实际地址和域名；接受问题：这是预期的发件人身份吗？
- 证据领域：信封；记录什么： Return-Path 和接收者报告的SPF域；验收问题： SPF实际验证了哪个域？
- 证据领域： SPF ；记录内容：可信接收者结果和评估的身份；验收问题：它通过了吗？该身份是否一致？
- 证据领域： DKIM ；记录内容：每个 d= 域，s= 选择器 和接收结果；验收问题：至少有一个通过的签名是否对齐？
- 证据领域： DMARC;记录内容：接收结果和适用的政策；验收问题：是否存在对齐的通过路径？
- 证据字段：路线；记录内容：产品、账户、消息类型；验收问题：测试是否使用生产路径？
DMARC需要至少一条对齐的、通过的SPF或DKIM路径。仅传递来自不相关服务域的签名是不够的。严格的 结盟 需要精确的域相等；宽松的对齐使用适用的组织域关系。在宣布成功之前检查域的实际对齐设置。子域不是自动严格匹配。 SPF使用SMTP身份，而不是显示名称或回复。咨询 对齐术语表 记录决定时。
使用 Authentication-Results 来自您信任的接收系统，而不是任意发送者提供的标头。捕获所有签名，而不是在第一次失败时停止。对于转发的邮件，将直接测试与转发的副本进行比较：转发可能会更改SPF评估或更改签名的内容。不要通过将货运代理的地址添加到您的提供商授权中来诊断这些影响。
在不扩大访问范围的情况下诊断故障
首先将权威DNS与准确配置的记录名称进行比较，然后检查递归可见性和服务验证。名称错误、密钥被截断或冲突 CNAME 不是通过等待缓存来修复的。所有者仅保留一个SPF策略，并在合并另一个发件人之前检查评估的包含和重定向中的 10 个 DNS 查找术语限制。 DKIM选择器属于单独的签名配置；不要覆盖其他应用程序的记录来强制验证结果。
如果身份验证通过但传送效果不佳，请分别检查收件人响应、信誉、内容和发送权限。 DMARC通行证不承诺接受或收件箱放置。如果两条路径均不一致，请停止扩展并更正实际的发送器配置。不要削弱整个域的DMARC策略来隐藏单个产品故障。
移交和恢复
与指定所有者一起保存批准的DNS差异、公共查找结果、服务状态和经过编辑的接收消息工作表。将凭据和私钥保留在票证之外。出现故障时，暂停受影响的发送作业或使用服务所有者控制下的先前测试的路由。仅恢复属于此集成的已更改记录；保留飞行消息所需的公钥。回滚、密钥轮换、域迁移或出站中继更改后重新测试。仅当产品所有者和邮件管理员可以解释观察到的身份链时才关闭更改。
确认提供商边界
使用组织管理员已连接并经过验证的域，而不是消费者邮箱身份。当需要该字段时，记录的 21600 秒 TTL 是六个小时，而不是任何查询已刷新的证据。对于丢失的域或已占用的邮件选择器，请在替换记录之前确认帐户和DNS所有权。自动设置不保证收件人接受。
完成一个虚构的诊断案例
仅虚构的书面案例：YA-01 假设域通过 Yandex 和单独的发票服务发送。运营商建议用仅限 Yandex 的重定向替换合并的SPF策略。未提供评估的SPF身份或DKIM结果。 DNS所有者必须在一项经过审查的策略中保留发票服务的批准授权并测试这两条路由。未断言发票故障或成功修复。在这种情况下，没有执行任何租户、 DNS 、服务器命令或消息。
将传递的消息与执行准备情况分开
RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。