范围和特定于提供商的配置
StatusHub 有不同邮件提供商路由的文档。本指南遵循其电子邮件发件人 - Postmark - 新文章；保留的旧Mailgun文章不得混入该设置中。发布前请确认您的 Hub 显示匹配的路由。迁移或较旧的租户可能需要不同的记录。
打开集线器配置、通知设置、电子邮件发件人。记录的默认值是do-not-reply@statushub.io 。输入预期的自定义发件人，然后刷新页面以显示其DNS说明。 Postmark路线需要 DKIM TXT记录 和返回路径 CNAME。直接从控制面板复制名称和值，而不是使用帮助文章中的示例公钥。
这 返回路径 所有者通常是 pm-bounces 子域，但由实际请求的名称控制。切勿仅仅因为这是可见发件人地址中的域而将此CNAME放在域顶端。 StatusHub 特别警告说，apex CNAME可能会与其他记录发生冲突，并损害不相关的系统，包括传入的邮件。保留邮箱 MX记录 与此返回路径委托分开。
发布这两条记录后，请使用 StatusHub 中的重新检查DNS记录。经过完全验证的自定义发送域允许指定的发件人地址。当自定义发件人仍未经过验证时，StatusHub 会在发件人中将回退记录为do-not-reply@statushub.io ，同时将自定义地址放在回复中。这种区别在诊断过程中很有用：到达您团队的回复并不能证明客户看到了您的品牌发件人。
帮助文章讨论了DKIM TXT值的转义和非转义分号。应用DNS编辑器所需的语法，然后检查发布的值；不要将反斜杠插入键中作为一揽子修复。新记录可能会很快得到验证，但文章指出了提供商和 TTL 的差异。在将所有失败归因于传播之前，诊断确切的所有者、类型和值。
重要的决定
确认活动邮件提供商路由以及回退是否已将自定义身份移至回复。
验证发布记录和真实发送路径
在编辑之前记录变更所有者、发送产品、域、批准的维护时段和先前的DNS答案。从指定帐户或记录的提供商工作流程获取当前记录值。将提供商提供的值与您的组织控制的选择分开，例如 DMARC 政策和报告接收者。现有邮箱MX 、不相关的验证TXT记录和活动DKIM选择器不会仅仅因为添加新服务而成为清理候选者。
发布后查询每个确切所有者和记录类型的权威名称服务器。记录查询时间、响应服务器和完整答案。将TXT字符串作为一个逻辑值进行比较，其中DNS响应将它们拆分为字符串。检查CNAME目标以及起始别名。然后比较递归解析器答案以识别缓存差异。成功的提供者验证是配置的有用证据，但它并不能确定实际接收者收到的内容。
使用预期产品路线仅将授权测试发送给受控收件人。保留原始消息和可信接收系统的 Authentication-Results。记录可见的发件人域、 SMTP 邮件来自 或观察到的Return-Path域，每个DKIM d= 和 s= 值， SPF 和DKIM结果，以及接收者的DMARC结果。仅当其经过身份验证的域与适用策略下的可见发件人域一致时，通过SPF或DKIM检查才支持DMARC 。回复和品牌显示名称不是 结盟 身份。 RFC 7208 、 RFC 6376和 RFC 9989 为这些区别提供协议基础。
验收工作表、恢复和证据限制
这是原始验收工作表，而不是现场测试报告。将每个门标记为待处理，直到证据存在：账户范围已确认；先前捕获的DNS ；发布确切的新所有者/类型/值；提供商验证完成；预定的行使路线；收到记录的身份信息；已确认一致的身份验证；其他发件人不受影响。为每个门分配一个人和证据文件。即使提供商仪表板为绿色，红色门也会阻止推出。
如果测试失败，首先区分丢失的发布、过时的缓存数据、不活动的提供程序配置、错误的出站路由和未对齐的身份验证。纠正所显示的最小缺陷并再次测试。不要仅仅为了通过一项测试而削弱DMARC或删除其他发件人的记录。如果更改损害了现有邮件，请使用批准的恢复计划和捕获的更改前配置，协调任何提供商端发件人更改以及DNS 。当排队的消息或批准的重叠仍然需要旧密钥时，请保留旧密钥。
此稿件没有可用的客户租户、更改前后的权威信息或真实收到的消息。保留的资源支持文件工作流程；他们不满足委托的现场证据门。独立检查员审查和人类中小企业批准仍有待确定。请勿将本指南描述为经过现场验证或将其发布为已通过这些门槛。
将后备解释为不同的身份结果
书面案例 SH-01 假定预期发件人是status@example.com ，但邮戳路由域仍未验证。因此，说明性通知使用记录的默认值 From do-not-reply@statushub.io和 Reply-To status@example.com 。所有SPF / DKIM结果未知。到达自定义地址的回复不会为example.com建立自定义的使用或对齐的身份验证。中心所有者必须验证活动提供商路由、更正精确生成的DKIM和Return-Path所有者、重新检查状态并检查受控通知。请勿将Return-Path CNAME移至根目录或导入旧的Mailgun指令。没有发生任何事件、订户通知、 DNS查询或配置更改。
保留执行边界
RFC 9989第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。