将 Hosted Exchange 视为旧服务名称
如果发送清单仍然显示 Rackspace Hosted Exchange，请首先确定现在发送组织邮件的内容。机架空间的 2023 年 1 月 5 日事件更新 声明其 Hosted Exchange 环境不会重建为持续服务。该更新将Microsoft 365迁移和 Rackspace Email 确定为替代方案。它是历史产品证据，而不是当前报价、价格承诺或迁移确认。
因此，本指南涵盖解决遗留依赖关系并验证替换路由。它不提供新的 Hosted Exchange 注册步骤、当前的 DKIM 切换或可重用的DNS值。旧的提供商标签 DMARC 报告是调查的线索，而不是证明已停止的邮箱服务仍然是您的活跃发件人。
保持变革的重点。一次协调一条业务路线，从受控邮箱中最近的一条普通消息开始。不要仅仅因为记录类似于旧的支持文章而删除它们。同一组织可能已移动员工邮件，同时保留单独的应用程序中继、转发安排或归档依赖性。
识别今天实际发送的服务
向帐户所有者询问当前的服务名称、管理员门户、域清单和迁移记录。区分谁从哪个平台发出消息来收取支持费用。必须使用实际的Microsoft 365租户和路由来评估 Rackspace 管理的Microsoft 365帐户。 Rackspace Email 必须根据该产品的当前说明进行评估。两者都没有继承旧的托管交换清单的证据。
构建涵盖员工邮箱、共享地址、应用程序、多功能设备和任何外部托管工具的路由列表。记录预期的发件人地址、责任所有者、当前提交方法以及每条消息的代表消息。几年前配置的应用程序可能仍然使用与用户桌面客户端不同的出站路径。
使用行政证据和收到的消息来解决分歧。发票可以建立商业关系，而新的标题则显示特定的交付。 MX记录 显示传入邮件的去向；它们本身并不能识别允许发送出站邮件的每项服务。将不确定的路线标记为未解决，而不是强迫它们进入最近的熟悉的产品类别。
清理前保留DNS基线
导出相关区域记录并记录其确切所有者、类型、值和 TTL。包括 SPF、 DKIM选择器、 DMARC和任何 返回路径 代表团。记录哪个应用程序或服务拥有每个依赖项以及在哪里可以找到其批准的替换说明。将此基线与更改请求一起保留，以便其他管理员可以区分有意迁移和意外删除。
SPF应用于SMTP 邮件来自 身份，具有独立的 HELO 评估，而不是简单地发送到消息中显示的地址。 RFC 7208 还需要正确选择单个SPF策略并限制 DNS 查询机制和修改器。在添加或删除授权之前，请查看实际评估所有者的完整策略。
不要创建第二个 SPF记录 作为迁移的捷径。在未确认当前服务需要历史包含内容的情况下，请勿将其粘贴到新策略中。同样，在所有依赖于该包含的路由都获得批准的配置之前，请勿删除该包含。出于合法原因，共享授权可以在邮箱迁移后继续存在，但其业务所有者和目的应该明确。
获取替换路由的配置
从其经过身份验证的管理界面或经过验证的支持渠道请求当前平台的特定于域的指令。所需的证据是确切的记录集、支持的签名身份、信封域行为以及该帐户的任何激活步骤。公共文档可以解释该过程，但无法确定您的域已注册或显示的示例是您分配的值。
如果说明与现有所有者冲突，请暂停该单独更改。记录冲突的服务并向相关提供商寻求支持的解决方案。不要发明一个 DKIM选择器，重复使用其他客户的公钥，或重定向现有的 CNAME 使向导看起来完整。保留组织的现有DMARC策略，除非授权所有者批准单独的策略更改。
定义激活前的恢复操作。它可能会恢复上次批准的发件人配置、暂停受影响的应用程序或恢复精确识别的DNS更改。恢复已停止的 Hosted Exchange 服务不是有效的回滚计划。恢复路径本身必须可用，并针对它将取代的业务功能进行验证。
在接收方验证新身份
通过每个范围内的路由将无害的邮件发送到受控的外部邮箱。在内部交付很重要的情况下，包括单独的内部测试。记录 Message-ID、UTC 时间、发件人域、 Return-Path 、每个DKIM签名域和选择器以及受信任接收系统标记的身份验证结果。保存足够的上下文以将消息与正确的应用程序相关联，而无需保留不必要的个人内容。
A DKIM签名'sd= 和 s= 标识用于查找其密钥的签名域和选择器，如中定义 RFC 6376。来自不相关的提供商域的传递签名并不单独建立 结盟 与您可见的发件人。比较观察到的身份而不是报告工具中显示的产品名称。
在下面 RFC 9989、当传递的SPF或DKIM身份与发件人域一致时， DMARC可以通过。应用实际配置的对齐方式；相关子域在宽松和严格设置下的行为可能有所不同。记录提供对齐通道的机制。绿色DNS检查或成功的收件箱放置不能替代此消息级证据。
Rackspace 旧路线工作表
为每个邮箱或应用程序路径填写单独的行：
- 历史服务标签和当前确认的服务：____。
- 企业主、管理员和当前指示参考号：____。
- 预期发件人地址和提交途径：____。
- 基线DNS导出和与其他服务共享的记录：____。
- 替换记录所有者、值和激活证据：____。
- 现有DMARC政策和适用的对齐模式：____。
- Message-ID、UTC 时间和受控接收邮箱：____。
- 观察到的Return-Path 、 DKIM d= 和s=,可信结果：____。
- 一致的传递机制和未解决的异常：____。
- 批准的恢复路线和退休所有者：____。
未知的当前服务或丢失的接收器结果会保持路由畅通。作为单独的工作项目跟踪数据恢复、历史邮箱保留和实时发送；某一方面的进展并不证明其他方面的完成。
过时发件人标签的虚构诊断
仅虚构示例：Birch Engineering 看到标记为 Hosted Exchange 的报告条目，并建议恢复旧的SPF授权。其管理员确认员工邮件已移至Microsoft 365 ，而扫描仪则使用另一个中继。受控测试显示员工邮件的身份验证一致，而扫描仪邮件上的提供商签名不一致。
该团队将两条路线分开，获取当前的中继指令并更正扫描仪支持的发送器配置。它使员工邮件身份验证保持不变。在新的扫描仪测试证明对齐后，它会根据剩余库存检查历史权限。没有检查 Birch 租户、域名或消息；这个例子说明了一个诊断决策，而不是一个经过验证的事件。
用证据关闭遗留依赖
仅当旧记录的所有者确认没有活动路由依赖它并且替换记录已通过受控测试后，才淘汰旧记录。将退役决定、批准的回滚和观察到的结果放在一起。邮件平台更改、 DNS迁移或报告中出现意外来源后重新检查。实时租户访问、当前帐户发布的配置、公共DNS和标头验证、目视审查、SME 人工批准和发布仍在等待中。
保留索赔的历史日期
状态页面将较晚的存档标题与注明日期的事件条目混合在一起。 2023 年 1 月 5 日的条目提供了不重建声明；这不是 2026 年 11 月的迁移优惠。在虚构的扫描仪示例中，如果存在不同的对齐传递机制，则仅未对齐的签名不会造成DMARC失败。该示例未指定其他结果。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。