范围和先决条件
使用本指南从外部自定义域支持地址发送Zendesk支持。在配置域授权之前，将该地址添加到Zendesk 。公共邮箱域上的地址无法使用客户控制的DNS ，并且Gmail连接器路由需要单独验证。到支持地址的传入转发并不能证明已配置出站身份验证。
配置记录的路由
- 步骤 1. 清点支持地址使用的每个外部域。保存当前 SPF 政策和 选择器 更改之前记录。
- 步骤 2. 添加
include:mail.zendesk.com域的单一SPF TXT策略，同时保留其他授权发件人。 Zendesk的服务示例是v=spf1 include:mail.zendesk.com -all。其当前指令要求包含在第一查找层中；验证生成的策略，而不是将其无形地嵌套在另一个包含中。 - 步骤 3. 为每个外部域发布两个 CNAME：
禅台1。 _domainkey指向zendesk1._domainkey.zendesk.com， 和禅台2。 _domainkey指向zendesk2._domainkey.zendesk.com。主机标签是相对于外部域的，除非您的DNS控制台需要完整名称。 - 步骤 4. 确认两者 CNAME 答案可通过权威DNS以及用于验证的解析器获得。保留这两项记录； Zendesk记录的方法可适应其密钥轮换，无需手动更换密钥。
- 步骤 5. 仅在DNS准备就绪后，打开管理中心、频道、对话和电子邮件、电子邮件。在电子邮件设置下启用自定义域 DKIM 并保存。 Zendesk警告说，在 CNAME 存在之前启用该选项可能会导致传送失败。
- 步骤 6. 从每个相关支持身份生成普通票证响应。保存原始传递的消息并检查接收者的身份验证结果，而不仅仅是代理界面警告。
产品特定风险
风险最高的排序错误是在发布两个 CNAME 之前打开自定义域签名。如果发生这种情况，请修复记录并与支持所有者一起评估排队的邮件。避免域范围内的 DMARC 放松作为一条路线的解决方法。当同一策略中的另一个包含项无效时， SPF验证也可能会失败；再次添加Zendesk并不能解决这个问题。请勿授权第三方系统从 Zendesk 拥有的子域发送。
证明接收端的路由
使用批准的外部邮箱并保存完整的原始消息及其时间戳和消息标识符。本指南中没有声称进行现场租户测试。以下是实施期间需要完成的验收工作表，而不是 一个记录 观察到的结果。
- 证据字段：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差异、公共查找结果、服务状态和经过编辑的接收消息工作表。将凭据和私钥保留在票证之外。出现故障时，暂停受影响的发送作业或使用服务所有者控制下的先前测试的路由。仅恢复属于此集成的已更改记录；保留飞行消息所需的公钥。回滚、密钥轮换、域迁移或出站中继更改后重新测试。仅当产品所有者和邮件管理员可以解释观察到的身份链时才关闭更改。
确认提供商边界
SPF页面将include:smtp.zendesk.com和include:support.zendesk.com标识为较旧的替代方案。与DNS所有者一起审查任何迁移，而不是无限期地保留重复的授权。 Gmail连接器有自己的SPF建议；不要默默地将其视为同一个外域票务路由。规定的季度密钥轮换取决于保留两个托管 CNAME。
完成一个虚构的诊断案例
仅虚构的书面案例：ZD-01 假设票证回复使用 From help@studio.example在选择器 zendesk1 处带有失败的d=studio.example签名，并且权威DNS缺少该CNAME 。 SPF和其他特征未知；未建立完整DMARC故障。支持所有者必须停止扩展、恢复记录的DNS先决条件并重新测试票证路由，而不是放松整个域策略。即将到来的工作前锋并不是相反的证据。在这种情况下，没有执行任何租户、 DNS 、服务器命令或消息。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。