识别前端发送路由
Front 可以在使用不同的出站传输时呈现类似的收件箱。首先记录频道类型、地址、域和帐户所有者。区分Gmail或Office 365同步、使用前端提供的身份验证的SMTP转发以及自定义SMTP 。不要仅仅因为邮箱出现在前面就授权第二次投递服务。
Front 的送达能力文档称，本机Gmail和Office 365同步使用提供商的 API，不需要 Front 的额外功能 SPF/ DKIM记录。 SMTP 转发渠道（包括以这种方式配置的 Google 网上论坛）需要单独评估。自定义SMTP使用所选服务器；遵循该服务器的身份验证要求。这种路线区分是改变最重要的前提。
实际的边界是运输，而不是品牌。在 Front 中撰写并由连接的邮箱发送的消息必须根据该邮箱提供商的域设置进行检查。使用 Front 发送基础设施的 SMTP 转发通道必须根据 Front 提供的DNS记录进行检查。如果组织同时使用两个验收记录，则保留两个验收记录。
收集帐户特定的DNS要求
对于共享SMTP通道，公司管理员打开公司设置、安全性和送达率。该选项卡取决于是否具有共享SMTP通道。选择域名并获取其显示的记录。对于单个SMTP通道，请使用队友的通道设置和通道的提高传送率 - SPF / DKIM 部分。发布提供的记录并运行检查DNS设置；记录的成功状态已验证。
这些步骤描述了文档设置，而不是我们访问的租户。要求授权管理员从实际帐户中导出记录名称、类型、值和任何优先级字段。将完整的预期所有者名称保留在DNS编辑器的输入标签旁边。这可以防止相对名称字段两次追加域。
请勿继承其他前端客户的选择器或用通用服务示例替换根SPF策略。账户显示的值为配置权限。如果 UI 与旧文档冲突，请在写入DNS之前停止并解析确切的通道和服务。
保持入站路由独立
Front 记录了专用的前端邮件MX所有者的身份验证设置，与根域不同 MX记录 用于接收普通邮件。不要替换现有的根MX记录以使身份验证警告消失。在MX编辑器中，优先级是与目标主机名分开的数字字段。
发布之前，请检查每个请求的所有者名称是否存在现有用途。提供商添加记录的指令并不允许销毁不同服务的记录。记录任何冲突并获取受支持的替代方案，而不是默默地覆盖它。验证权威区域是否是您正在编辑的区域，尤其是在注册商和DNS主机不同的情况下。
通道设置页面提供自定义SMTP和SPF / DKIM记录之间的选择。如果您的DNS服务无法支持所需的配置，请与邮件管理员一起调查记录的自定义 SMTP 路由。不要临时将记录放置在附近未使用的标签上：签名和信封路由需要准确的预期名称。
独立接受DNS和邮件
产品验证和权威DNS回答不同的问题。在每个权威服务器上查询预期的所有者和类型。将答案与批准的账户价值进行比较。如果权威答案不同意，请先修复区域状态。如果他们同意，但 Front 仍然看到旧答案，请考虑之前的缓存生命周期并重复检查，而无需重复重写工作记录。
然后通过实际的前端通道将受控消息发送到原始接收消息可用的邮箱。记录可见的发件人域、信封身份、所有DKIM d= 和 s= 值以及可信接收者的身份验证结果。 SPF通行证涉及信封身份。 DKIM通行证涉及签名域。 DMARC 需要至少一条与可见的 From 域对齐的传递路径。收到回复或在“已发送”中查看消息并不能确定该结果。
综合示例，不是观察到的 Front 默认值：支持消息包含 From help@example.com 、信封bounce@front-mail.example.com和有效的 DKIM签名 与d=example.com. DKIM域完全对齐。信封是子域而不是精确的域匹配，因此它的SPF 结盟 取决于适用模式。如果签名失败并且需要严格的SPF对齐，则该子域的SPF通行证不会挽救该示例。
诊断特定的故障层
缺少“交付能力”选项卡是访问或渠道范围问题，并不能证明DKIM不受支持。更改后的DNS警告可能表明区域错误、后缀重复、记录类型错误或缓存数据。通过未签名消息的DNS检查指向选定的出站传输或激活状态。如果传递的一致消息落入垃圾邮件，则需要对声誉、内容和收件人策略进行单独调查；身份验证不保证收件箱的放置。
在进行更改之前保留旧的DNS记录集和最后的工作通道配置。与出站签名分开测试普通入站邮件，并测试预期回复。如果需要恢复，仅恢复经批准的更改下受影响的配置；避免替换不相关的根记录或禁用域范围 DMARC执行 作为捷径。
如实记录完成情况
接受数据包应命名 Front 通道、企业所有者、 DNS所有者、提供的记录、权威答案、Front 验证结果和接收消息身份证据。标记每条测试的路线。本指南仅包含书面证据和综合示例：未收集租户设置、实时DNS观察或已传递消息结果。经过这些检查后，生产验收仍由授权管理员负责。
将两个通道保留在单独的证据行中
书面案例 FR-01 假设help@example.com是本机Microsoft 365同步通道，而group@example.com是使用前端发送的 SMTP 转发组。第一个具有规定的可信DKIM通行证，其中d=example.com, s=demo1;第二个没有收到消息的证据。第一个对齐的路径不会验证第二个路由或授权第一个路由的新DNS更改。要求通道所有者确认组传输并获取其生成的值，保留根MX和所有邮箱提供商记录。如果该组稍后使用自定义SMTP ，请重新评估该服务器。此示例中未访问任何通道、 DNS查找或消息。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。