首先选择功能和传输
Zuora 的电子邮件送达指南于 2026 年 6 月 29 日更新，将电子邮件通知与工作流程分开。对于电子邮件通知，它描述了 Advanced SMTP 、外部SMTP服务器和 Zuora 默认服务器。工作流可以使用Amazon SES或外部SMTP服务器。这些替代方案不得合并到一个通用设置过程中。
从为该类别选择的组织、环境、消息类别和传输开始。计费通知和工作流生成的消息可能具有不同的配置所有者，即使它们的可见发件人地址看起来很相似。确定请求的更改是否涉及新路线、现有自定义域或传输之间的迁移。
公共指南建立了记录在案的选项，而不是特定租户的状态。账户资格、环境适用性和操作接受度仍然开放。本稿件未执行任何租户登录、凭证创建、支持请求、 DNS编辑或电子邮件传输。 Zuora 交付配置
将高级SMTP视为自己的域身份工作流程
该指南将高级SMTP描述为 Amazon SES 支持的服务，使用 DKIM。其单独的域身份说明于 2026 年 11 月 2 日更新，指示管理员在“身份”表的DKIM状态”列中选择“查看”，并发布三个 CNAME 显示记录。这些账户发出的记录是配置输入；不发明 选择器 或借用另一个环境的价值观。
同一页面区分 TXT记录 通过“验证状态”列可见：它表示在此工作流程中不需要TXT记录来验证域身份。这是一个有用的示例，说明了为什么可见的DNS值不应自动成为更改请求。记录哪个列和对话框提供了建议的记录。
为了成功验证，记录的验证状态和DKIM状态值将从待处理更改为成功。保留观察结果及其时间戳。 DNS中存在的公钥依赖性和报告成功验证的产品是相关但不同的检查点。 验证域身份
安全地审查姓名处理和不成功的验证
Zuora 的域标识说明解释说，以_domainkey结尾的名称可能需要附加域，除非DNS提供商已经添加了该域。接受目标是完整的预期名称，而不是始终添加或始终删除后缀的通用指令。在出版前将发布的名称与实际编辑的约定进行比较。
该指南描述了验证需要长达 72 小时的时间，并为未解决的状态提供重试或身份重新创建说明。将这些视为产品指南，而不是保证错误记录会因等待而变得有效。在活动环境中重新创建身份是一个随之而来的配置更改，需要进行依赖性审查和授权；它不应该是一种自动的故障排除反射。
首先比较三个预期的别名、它们的目标、权威区域和当前状态。在进行任何更改之前保留差异的证据。不要仅仅因为来自另一个路由的消息失败而删除工作身份。 验证结果和故障排除
单独的默认服务器、工作流程和外部服务器要求
对于 Zuora 默认电子邮件服务器，送达指南提供了 SPF 使用 mx 和a:zgateway.zuora.com.它只是该传输的一个示例，不能安全地替代组织的完整SPF策略。在提出策略更改之前，保留其他授权发件人并识别实际评估的身份。
对于 Workflow 的 SES 路由，指南workflow@zuora.com描述为其预先验证的默认发件人地址。使用组织自己的域需要记录SPF授权以及向 Zuora 全球支持请求三个DKIM CNAME记录。支持辅助值不能与猜测的高级SMTP身份互换。
外部SMTP有不同的所有者：组织或选定的提供商提供相关的服务器和身份验证配置。该指南还描述了工作流的外部SMTP选项，但本手稿不会创建凭据、注册应用程序或配置 OAuth。这些操作需要他们自己的授权和当前提供商的特定说明。 运输特定部分
在邮件级别解释SPF和DMARC
Zuora 指南名称include:amazonses.com ，其描述的基于 SES 的配置。该指令仍需要与实际路线和完整政策保持一致。包含并不能保证 Zuora 生成的每条消息都使用其发布的域。 SPF评估其指定的SMTP身份，并选择多个 SPF记录 导致错误而不是自动组合。
在接受合并策略之前，请查看 DNS 相关评估条款和现有授权。然后评估授权代表收到的消息：记录可见的作者域、签名域和选择器、相关信封身份和可信接收者结果。 DMARC 需要通过对齐的身份验证身份；产品的广泛合规性描述并不能证明特定信息是一致的。
身份验证不保证收件箱放置、客户收到帐单通知或付款指令的合法性。将这些业务成果与技术验收声明分开。 RFC 7208 ，第 2.4 节; RFC 7208 ，第 3.2 节; RFC 7208 ，第 4.6.4 节; RFC 9989 ，第 4.4 节
计费平台移交验收工作表
对于本质上不同的通知和工作流程路线，单独使用此原始建议的工作表。
- 范围：租户、环境、功能、消息类别和选定的传输。
- 发件人：预期作者域、默认身份与自定义身份以及负责任的企业主。
- 提供商请求：准确生成或支持发布的记录、其发布接口及其所属帐户。
- DNS审核：完成受影响的SPF策略、适用的三 CNAME 比较以及现有依赖项。
- 产品状态：相关状态列、值和时间戳，而不是一个通用的就绪标签。
- 消息接受：最小化授权样本，包含作者、信封和签名身份以及可信验证。
- 变更控制：批准、回滚所有者以及预定计费通信的处理。
- 发布：明确记录当前适用性、生产、视觉和所有者审查差距。
该空白验收设计不是已执行的测试，并且不包含计费数据、凭证或客户消息。
虚构的诊断：来自默认工作流程发送者的证据
虚构的订阅企业验证其生产通知路由的高级SMTP身份。然后，审阅者使用默认提供商发件人接收工作流示例，并将其通过的身份验证视为自定义域计费通知已准备就绪的证据。样本与声称的路线不匹配。
建议的修正是在收集额外证据之前绘制每个特征和传输的地图。该团队保留成功的域身份状态，但要求从预期的通知类别中获得经过适当授权的样本。它不会替换共享SPF策略或删除身份来强制不相关的邮件看起来相似。该报告将未解决的工作流程自定义分开。此场景是虚构的，没有描述任何真实的租户活动或已验证的 Zuora 故障。