将 RMail 身份验证范围限制到正在使用的路由
RMail 可以通过应用程序集成和SMTP路由处理业务消息，因此从您的组织实际使用的路由开始。记录原始应用程序或邮件客户端、RMail 服务路径、发件人域、任何后续网关以及用于测试的受控收件人。将交付证明、加密和域身份验证视为单独的验收问题。收据可以作为有用的操作证据，而无需证明收件人的邮件服务器观察到了一致的 SPF 或者 DKIM 经过。
本指南涵盖了提供商协助的身份验证和验证工作流程。公开的第一方材料表明 RMail 支持SPF和DKIM配置，但检索到的文档并未提供完整的、普遍适用的 SPF记录、帐户特定的DKIM值、 选择器 或自助服务控制序列。在该组织的 RMail 代表提供最新指示之前，这些详细信息仍处于保留范围。不要仅仅为了使清单看起来完整而替换第三方示例。
将发送权限与接收处理分开
RPost的 混合SMTP集成概述 将发送系统和发送者地址的验证与路由、消息格式化和回执处理区分开来。其认证列表包括IP认证、域验证、 SPF和DKIM 。这些是实际集成的配置主题，并不是任何组织已经启用它们的证据。
构建一个小型路由图，将传递给收件人的业务消息与返回给发件人的确认或收据分开。对于每个，确定哪个系统发起它以及哪个邮箱接收它。使用提供商拥有的发件人域的收据不应被误认为是原始组织的消息。同样，成功接收到内部邮箱并不会验证面向外部客户的路由。
询问应用程序所有者在生产中使用哪些模式。当跟踪和证明消息、加密消息和自动化应用程序工作流程的处理不同时，应接受单独的测试。保持测试矩阵成比例：一条代表性消息可以涵盖相同的设置，但一个产品标签不应将真正不同的路线折叠成一个结果。
从RMail获取完整的记录集
请求有关确切发件人域和服务部署的书面说明。该请求应标识预期的发件人域、当前信封行为（如果已知）、负责DNS组织以及网关是否在 RMail 后更改消息。询问完整的记录所有者、 DNS类型、值以及任何所需的激活步骤。如果正在更改现有域，请询问转换如何影响已排队的消息。
RPost的 DKIM申请表 描述了实现提供的DNS信息、检查选择器记录，然后发送测试 RMail 消息以进行确认。公共表单是工作流程参考，而不是您公司的填充键。不要从支持地址派生未发布的选择器，也不要根据猜测的命名约定创建TXT值。
让 RMail 确认特定部署是否支持自定义信封域配置（如果有SPF 结盟 是一个业务需求。这里的公开证据并没有建立普遍的习惯 Return-Path 程序。如果无法满足该要求，请评估支持的一致DKIM是否满足组织的要求 DMARC 验收标准。记录实际结果，而不是报告与假设一致的两种机制。
准备DNS更改而不扩大不相关的信任
在进行编辑之前导出每个受影响所有者的现有记录。保留其他实时服务使用的SPF权限并识别现有的DKIM选择器。检查颁发的所有者是否与其他记录或委托服务冲突。将冲突升级给相关管理员，而不是覆盖活动的集成。
SPF验证SMTP 邮件来自 身份，具有独立的 HELO 评估，根据 RFC 7208。仅当该域是为路由评估的域时，在可见的“发件人”域中发布授权才有帮助。在决定提议的SPF更改所属位置之前，确定观察到的或提供商确认的信封身份。消息正文中可识别的业务地址在该决策中没有任何作用。
如果SPF策略需要修改，请在该所有者处保留一项策略并计算整个 DNS 查询成本，包括嵌套提供程序依赖项。不要在当前记录旁边粘贴第二个v=spf1记录。未经审查，请勿将示例策略的终端限定符转变为公司范围的安全决策。如果 RMail 无法提供所需的信息，请保留更改未实施并明确跟踪丢失的输入。
发布并验证公共DKIM材料
将提供商发布的公共值复制到批准的DNS更改中。检查编辑器对相对名称和区域后缀的处理。保留预期的逻辑TXT值，同时遵循DNS主机的输入格式。该表格提到了DNS系统之间的语法差异；这是验证结果答案的原因，而不是盲目添加反斜杠或标点符号。
保存后查询确切的公共选择器所有者，并与发布的值进行比较。记录观察时间和TTL。在下面 RFC 6376， 这 DKIM签名'sd= 和 s= 值标识用于键查找的域和选择器。 一个记录 位于附近但不同的名称将不会验证签名。 DNS发布也无法确定发送系统已开始使用该密钥进行签名。
在广泛测试之前要求 RMail 确认其配置状态。将私钥、API 机密和SMTP凭据保留在DNS工作表之外。将证据包限制为公共配置、相关的已编辑标头和提供者的确认。支持请求应包含足够的上下文来诊断路线，而无需复制机密合同、发票或客户信件。
运行提供商确认和独立接收者测试
请求表要求将跟踪和证明或加密测试消息发送到提供商的DKIM测试地址，并复制 RMail 代表。通过组织批准的支持流程安排测试并使用无害的内容。发送前与代表确认当前收件人和说明；发布的表格并不意味着无需遵守组织的外部消息规则。
还可以将受控邮件发送到管理员可以检查其标头的外部邮箱。捕获消息 ID、UTC 时间、可见发件人、 Return-Path 、 DKIM d= 和s=,以及接收系统的可信 Authentication-Results。避免依赖仅声称成功的发件人插入的标头。测试实际的处理模式和任何下游网关，而不是绕过生产路由的简化消息。
使用 RFC 9989 将传递的SPF或DKIM身份与可见的发件人域进行比较。记录协调的机制和适用的宽松或严格模式。有效的提供商域签名可能是有用的身份验证，但仍然无法与组织的发件人保持一致。相反，当SPF未对齐时，对齐的DKIM可以提供DMARC通行证。请勿承诺任一结果的收件箱放置情况。
在不削弱消息控制的情况下诊断故障
对于缺少DKIM情况，请先检查激活和路由选择。对于签名失败，请检查确切的密钥所有者以及稍后是否处理修改的签名内容。对于SPF失败的情况，请在调整权限之前确定评估的域和最终的发送源。对于DMARC失败以及传递机制，请检查对齐情况，而不是添加更多不相关的DNS记录。
在诊断身份验证时保持加密或接收要求完好无损。即使直接邮箱平台测试成功，绕过 RMail 也可能会改变发件人期望的业务功能。与应用程序所有者一起定义恢复计划，例如暂停受影响的工作流程或恢复已批准的配置。不要为了获得更清晰的身份验证结果而悄悄地将敏感通信切换到未加密的路由。
RMail 实施工作表
- 业务流程及RMail处理模式：____。
- 发起应用程序、提供商帐户和负责管理员：____。
- 预期发件人、信封域和最终出站路由：____。
- 提供商发布的SPF说明和政策审查：____。
- DKIM所有者、公开价值、 DNS观察和激活证据：____。
- 退回收据的单独目的地和身份：____。
- 提供商确认测试和独立接收器测试参考：____。
- 消息 ID、UTC 时间、 DKIM身份和可信结果：____。
- 一致的DMARC机制、未解决的要求和恢复所有者：____。
误导性收据的虚构示例
仅虚构的书面案例：RM-01 假设返回的收据已成功到达，而单独的面向客户的消息具有 From adviser@example.org和来自不相关提供商域的传递签名。确切的提供商域、选择器和SPF结果仍然未知。收据并不能确定原始消息的真实性；管理员应获取特定于帐户的配置并重新测试实际的受保护路由。无法推断出完整的DMARC判决，并且不得绕过加密。没有检查任何帐户、收据或消息。
保留范围保留直至账户证据存在
对于真正的租户来说，通用SPF值、发布的选择器、密钥、激活状态和自定义信封支持仍未解决。实时DNS和标头、租户检查、目视审查和 SME 人工批准正在等待中。本指南尚未发布，不应标记为已完成的生产配置。
将传递的消息与执行准备情况分开
RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。