区分托管、 DNS和出站邮件
本指南涵盖的域的邮件实际上是通过 xneelo 的托管邮件服务发送的。那里托管的网站或域可能会通过外部邮箱、会计系统或营销服务发送。记录邮箱和SMTP路由，xneelo包和控制面板，权威 名称服务器，以及预期的 From 域。在编辑任何内容之前保存现有的DNS和基线原始消息。
xneelo 控制面板 DKIM 文章指出，新的托管包默认包含DKIM ，而外部托管的DNS需要在DNS提供商处添加或修改其相关记录。这不会建立旧帐户、自我管理服务器或不相关SMTP服务的状态。获取当前特定于包的记录和签名状态，而不是将默认声明扩展到所有 xneelo 产品。 xneelo DKIM.
审查现有SPF政策
西尼洛的 SPF 本文给出了一个使用 a、mx 和include:spf.host-h.net,以软失败限定符结尾。它指示拥有外部DNS的客户修改该提供商的策略，并针对多个 DNS 发出警告。 SPF记录。将完整示例视为要评估的配置，而不是覆盖每个现有策略的命令。 SPF.
识别直接测试消息使用的实际信封域。在合并任何内容之前，清点在该域授权的其他系统。保留每个必要的权限并检查广泛的 a 或 mx 机制是否属于您自己的策略。确认语法和完整的查找预算。策略可以在语法上存在，但会产生中性、 softfail 、失败或 permerror 而不是通过；不要将存在与成功等同起来。 SPF协议.
在仅身份验证更改期间保持入站MX路由稳定。不要仅仅因为第三方文章列出了类似托管品牌的不相关提供商包含内容而添加不相关的提供商包含内容。名称和历史品牌并不能确定当前哪个服务提交您的消息。
确认实际的DKIM记录和签名者
获取公钥并 选择器 从其当前配置或支持获取包和域。在外部DNS处，验证确切的所有者名称和记录类型，注意不要两次附加域。不要创建猜测的默认选择器或复制其他客户的密钥。在测试发送工作流程之前确认最终的权威答案。
正确的DNS密钥对于验证是必要的，但并不表明传出服务使用匹配的私钥。通过普通客户端发送受控消息并检查实际情况 DKIM-Signature。查询d=域下的选择器，然后比较可信接收者的验证结果。 DKIM.
比较直邮、网站邮件和转发
对表现不同的路径使用单独的证据行。以下是综合测试计划，而不是一组观察到的 xneelo 交付。
- 路径：托管邮箱直接发送；证据： SMTP目标、原始标头和接收结果；决策：建立托管邮件基线
- 路径：网站通知；证据：应用程序传输和观察到的身份；决策：确定是 xneelo 邮件还是其他服务发送它
- Path：转发的消息；证据：转发结果和保留的签名；决定：将转发与原始发送分开进行诊断
对于每个样本，记录可见的 From、包络域、每个 d= 和 s= 值以及接收器的SPF 、 DKIM和 DMARC 结果。对于user@example.com的合成发件人，传递的d=example.com签名是精确的 结盟 案件。提供商拥有的签名域不会仅仅因为 xneelo 托管网站而变得一致。将有效的对齐策略应用于实际身份。 DMARC.
使用特定于包的计划进行维修
如果记录仅在非权威面板中可见，请通过实际的DNS所有者发布它们。如果DKIM丢失，请确认此包和路由是否已启用签名，而不是假设新包默认覆盖它们。如果SPF失败，请在编辑可见的发件人域之前检查评估的域和服务。如果只是转发失败，保留通过的直发基线，单独排查中继。
如果合并中断了其他发件人，则恢复之前已知良好的DNS值，并重复直接发送和受影响的服务测试。与提供者协调密钥更改，而不是删除排队消息所需的选择器。保留DNS快照、包标识、测试时间戳和收到的原件。包迁移、 DNS移动或SMTP更改后重新检查。本手稿仅使用文档，不要求现场租户或交付验证。
确认提供商边界
SPF文章的 2019 年中立策略历史记录并不能证明任何当前域的策略或通过结果。其简化的交付描述并非接收者的保证。公共DKIM页面建立了新包默认值，但不提供通用选择器或激活程序；获取特定于包的详细信息并保留该边界，而不是发明面板步骤。
完成一个虚构的诊断案例
仅虚构的书面案例：XN-01 假设来自help@shop.example的直接托管邮件已传递d=shop.example,而来自同一可见地址的网站通知使用外部SMTP服务。其信封和签名未知。邮件所有者保留通过的直接基线，并指派网站所有者验证外部服务。 xneelo DNS密钥或新包默认值无法建立该外部路由的签名状态。此案例没有测试任何帐户、 DNS 、CRM、发票、活动或交付。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。