将工作范围确定为 Gainsight NXT
本指南涵盖了客户成功文档中描述的 Gainsight NXT 电子邮件服务工作流程。在未检查 Gainsight PX、Community 或其他产品的范围之前，请勿重复使用该过程。共同的企业品牌并不建立共同的邮件传输。
在开始之前记录生产租户、发件人域、可见发件人地址、Journey Orchestrator 程序和DNS所有者。确定当前传输是SendGrid还是Mailgun 。 Gainsight 记录了这两种情况，并警告称，更换现有组织的电子邮件提供商可能会影响电子邮件分析。传输切换不是常规DNS故障排除步骤。
目的不仅仅是去除品牌标签。它将特定的业务消息连接到授权的发送身份，并保留足够的证据来诊断未来的故障。审查拟议名称和组织的现有使用情况 DMARC 结盟 请求新记录之前的设置。
请求支持的配置
Gainsight 的 NXT 过程从安装 Gainsight 并启用 MDA 开始。管理员向支持人员提供请求的发件人域和生产租户 ID（可在“管理”>“应用程序设置”下找到）。支持返回相关 CNAME 记录。 DNS团队发布它们，然后支持和运营验证域。
使用返回的集作为更改请求，而不是作为从屏幕截图复制值的建议。与票证所有者确认确切的租户、域和提供商。将域身份验证记录与品牌电子邮件链接记录分开。跟踪链接在操作上可能是必要的，但有效的品牌链接并不能证明 SPF, DKIM 或DMARC对齐。
在发布之前，为每个请求的记录编写一个小清单：完整的所有者名称、类型、目标、用途、现有使用和回收价值。 DNS接口的不同之处在于它们接受相对标签还是完整名称。在保存之前解决该差异。不要改变现有的 选择器 仅仅因为新值出现在支持响应中，该值就属于另一个发件人。
不要发明SPF或选择器快捷方式
NXT 源描述了 SendGrid 管理的SPF的自动安全路由，并允许请求最多三个字符的自定义DKIM选择器。这些事实并不能确定每个租户或Mailgun的记录。通过支持的过程获取准确的值，而不是添加通用的根SPF包含。
SPF根据SMTP信封标识进行评估。如果服务使用不同的退回域，则新的根域权限可能无关紧要。相反，删除现有的 root 权限可能会破坏另一个合法发件人的权限。当确实有必要时，将整个SPF策略及其依赖项视为单独的域级别更改。同一所有者的多个候选SPF策略不是组合服务的有效方法。
选择器冲突需要明确的解决方案。在发布之前请求适当的支持选择器，并保留旧服务的记录，直到其使用结束。仅DNS发布并不能证明 Gainsight 已激活新的签名配置。
验证支持移交和真实程序
首先确认权威DNS具有准确返回的 CNAME，并且目标按预期进行解析。然后获取提供商的验证结果。支持确认会结束设置交接，但接受还需要向授权测试接收者发送真实的 Journey Orchestrator 消息。
Gainsight 建议在身份验证检查中检查测试邮件的邮寄域并记录 gsemail 或 gsnemail 子域。将该显示视为有用的线索，而不是完整的DMARC证明。保留原始消息和可信接收系统的身份验证结果。捕获自、信封域、每个DKIM签名域和选择器以及与每个身份关联的结果。
综合诊断案例：发件人域是example.com ， SPF传递gsemail.example.com ， DKIM传递example.com 。 DKIM提供精确对齐。在严格的SPF对齐下，子域并不完全匹配example.com ，尽管它可以在宽松模式下对齐。如果后面的示例使用提供商拥有的信封并且缺少对齐的DKIM ，则一般SPF通行证不会证明品牌邮件通过DMARC 。
对每个实质上不同的工作流程重复验收。来自一个程序的成功的隔离测试并不能证明另一个配置的发件人、区域或传输使用相同的身份。让企业主参与决定哪些工作流程需要单独的样本。
无需过早更换提供者即可进行诊断
如果权威DNS错误，请修复名称、类型或值并重复验证。如果DNS正确但缺少签名，请将准确的租户和消息证据返回给支持所有者以进行激活或路由审查。如果身份验证有效，但应用程序显示“已发送”但没有发送事件，请调查该事件和接收系统，而不是将“已发送”视为收件箱接收的证明。
不要削弱域范围的DMARC策略来隐藏一个失败的程序。根据批准的恢复决策暂停或重新路由受影响的工作流程。保留以前的记录集和更改前的传输配置。由于可能存在客户内容和收件人地址，因此要对保留的消息证据进行访问控制。
完成和证据限制
完成意味着协调的支持请求、批准的DNS更改、提供商验证以及观察到的预期计划的接收者身份验证。记录每个步骤的不同状态。本手稿使用当前保留的第一方文档和协议推理；身份示例是综合的。没有访问或执行 Gainsight 租户、支持票证、 DNS更改或传递的消息。在将路线视为经过生产验证之前，人类所有者必须提供并审查现场证据。
将支持结果与实际计划进行比较
书面案例 GS-01 假设支持部门验证了已批准的example.com配置，但尚未对第二个 Journey Orchestrator 程序进行采样。其预期发件人是success@example.com ；包络域、 DKIM d=/s=和接收器结果均未知。该计划的有效品牌链接无法填补这些空白。程序所有者必须确认其发送者和传输，然后在扩展部署之前收集授权的受控消息。不要仅仅为了排除未观察到的结果而切换SendGrid和Mailgun 。未执行票证、租户设置、消息或DNS操作。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。