选择当前产品和交付方式
本指南涵盖了 2026 年 10 月记录的 HappyFox 帮助台管理的外发电子邮件工作流程。它不会替代旧的帮助台或服务台说明，并且不会将这些记录应用于自定义SMTP路由。在打开DNS之前记录帐户、电子邮件通道、托管区域、预期发件人域和实际的传出方式。
目前的 SPF 和 DKIM 指南列出了除基本计划之外的所有计划。确认您的帐户有相关的工作流程。在“频道”>“电子邮件”>“电子邮件地址”下，打开频道，选择“配置 HappyFox 托管”并使用DNS验证。 SPF面板提供一个 TXT记录 和一个 结盟 CNAME; DKIM面板提供五个CNAME对。 SPF设置 · DKIM设置
发布整个显示的记录集
复制帐户的准确值并区分更改工作表上的SPF和DKIM面板。对于现有根SPF策略，将批准的 HappyFox 包含合并到该策略中，保留其他发件人。不要创建第二个SPF策略。选择适合帐户的授权，而不是无缘无故地结合美国和欧盟的示例。发布对齐CNAME和每个DKIM对；在Cloudflare上，提供商指示仅 DNS 记录。 当前发布说明
验证每个预期的完整所有者姓名。如果DNS主机附加域，请使用生成正确所有者的相对名称，而不是重复区域后缀。添加CNAME之前检查任何现有数据。在替换记录或删除旧选择器之前，保留先前批准的答案并确定依赖关系。
运行验证 SPF记录，然后在适用的面板中验证并启用DKIM 。该文档最多允许 72 小时进行验证。它还警告，如果没有完成DKIM验证，此托管工作流会从通用 HappyFox 地址而不是自定义域发送。 当前DKIM验证
区分验证和消息身份
原验收方案：为实际渠道创建一个无害的受控支持交换。捕获正常回复和发布中包含的任何自动响应。对于每个域，记录显示的发件人域、 SMTP信封域、 DKIM d= 和 s= 值以及可信接收者添加的身份验证结果。记录观察到的发件人是预期的自定义身份还是后备身份。
DMARC 当至少一个通过的SPF或DKIM身份与适用策略下的可见发件人域一致时，通过。通用后备可能会以其自己的域身份进行身份验证，而无需证明您的自定义域部署已完成。同样，成功的DNS面板本身并不能证明该消息使用了预期的通道或传递方法。
示例性失败：管理员关注较旧的两个 CNAME 文章，而当前面板请求 5 条记录。有用的纠正是协调完整的当前帐户记录集，而不是重复测试部分旧配置。如果帐户确实具有不同的界面，请在混合工作流程之前获取特定于产品的支持指南。
以受控恢复计划结束
与域所有者单独审查现有的DMARC政策；不要复制政策模式的遗留描述或削弱执行以隐藏不完整的设置。如果测试失败，则暂停受影响的自定义域推出。保留最后批准的通道设置和DNS记录，并仅更改经证明有错误的层。保留旧的有效选择器，直到考虑相关路由和排队邮件为止。
文档于 2026 年 11 月 8 日审核。未测试 HappyFox 帐户、 DNS记录或真实支持消息。示例和验收计划是原始的说明性指导，而不是已完成激活的声明。
不要在部分验证时关闭通道
书面案例 HF-01 假设非基本托管频道旨在support@example.com 。其SPF面板已通过，但当前五个DKIM CNAME对中仅发布了两个； DKIM激活仍未完成。可以应用已记录的通用发件人回退，但其确切地址和消息结果在此未知。渠道所有者应保持自定义域接受待定状态，同时DNS管理员协调所有五个生成的所有者和目标，然后运行验证并启用DKIM并检查无害的支持交换。不要推断DKIM失败 一个记录 单独计数或要求任何收到的消息判决。未执行支持票证、 DNS修改或通道激活。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。