在遵循DKIM指南之前先识别 Rackspace 产品
Rackspace 提供多种可以出现在同一组织的邮件清单中的服务。 Rackspace 托管的DNS区域、Rackspace 电子邮件邮箱、托管 Exchange、 Microsoft 365以及在云服务器上运行的应用程序不是可互换的身份验证路由。本指南涵盖已记录的 Cloud Office 发件人身份验证工作流程支持的域。在应用之前确认实际产品和可用的域控制。
Rackspace 的单独创建 DKIM TXT记录 文章明确指出，其通用 Cloud DNS方法与 Rackspace Email、Hosted Exchange 和Office 365客户的设置不同，并引导这些客户获得 Cloud Office 帮助。不要使用通用密钥生成过程作为托管邮件将使用手动创建的密钥进行签名的证据。 Rackspace DKIM产品范围说明
记下邮箱产品、帐户管理员、可见发件人域、提交端点和任何出站中继。对于网站或业务应用程序，确定是通过托管邮箱服务提交还是独立发送。由 Rackspace 托管的网站未确定其传出消息使用 Cloud Office 签名。
该产品标识是一个验收门。如果请求的域未公开记录的发件人身份验证控制，请停止并获取当前的特定于产品的说明。不要通过创建任意的 选择器 在DNS中，更改邮箱 MX记录，或假设其他 Rackspace 产品的设置适用。
在支持的托管域流程中启用签名
记录的 Cloud Office 工作流程从控制面板的发件人身份验证 ( DKIM ) 的域部分开始。选择域并启用DKIM 。通过该面板管理的DNS由记录的流程自动处理；外部托管的DNS需要发布公共TXT记录说明。使用验证TXT记录检查公共记录并查看任何验证错误。 Rackspace 指出，启用DKIM后会对新的传出消息进行签名。 Rackspace 云办公室DKIM
捕获所选域的实际生成的所有者和公共值。如果当前界面未显示足够的信息，请向 Cloud Office 支持人员询问域支持的说明，而不是猜测密钥。 DNS主机发布公共信息；它不会独立为托管邮件服务选择私有签名密钥。
确认活跃权威 名称服务器 即使客户使用 Rackspace 提供某些服务也是如此。 一个记录 在一个控制面板中可见的记录可能不是收件人查询的。对于外部DNS ，请在发布后检查完全限定的选择器所有者，并确保编辑者没有两次追加该区域。保留先前存在的记录，并在覆盖之前解决选择器冲突。
验证按钮和收到的签名回答了不同的问题。验证检查公共DNS先决条件。受控传出消息显示真实路由是否使用了预期的签名域和选择器。变更单中的任何一个步骤都不应默默地替换另一个步骤。
使用SPF授权真实SMTP路由
Rackspace 的云办公室 SPF 策略示例使用include:emailsrvr.com.仅在识别其打算覆盖的托管邮件路由后才应用该授权。如果组织已经有一个 SPF记录，保留其合法发件人并合并必要的机制，而不是用单一服务示例替换整个策略。 Rackspace SPF政策指导
同一域还可以通过 CRM、计费平台或单独的网站服务发送。记录每条路由及其支持的身份验证配置。不要仅仅因为服务器和邮箱共享 Rackspace 品牌就授权不相关的云服务器地址。相反，启用托管邮箱DKIM不会配置绕过托管服务的单独应用程序。
SPF允许记录所有者采用一项适用的策略，并限制依赖于 DNS 的评估。使用适当的机制进行实际授权； include 引用另一个SPF策略，并且不是任意 IP 地址的通用容器。检查完整的结果策略以及根据收到的消息评估的身份。 SPF RFC 7208
将对政策最终限定符的任何更改保留在其自己审核的决定中。添加服务并不会自动批准以加强对所有现有发件人的执行。保存原始值和回滚计划，包括谁可以恢复它以及如何验证由此产生的公共答案。
分别测试邮箱和应用消息
从范围内的实际 Webmail 或邮件客户端路由发送受控消息，然后从每个单独配置的应用程序发送受控消息。保留安全测试标识符、时间戳、接收者、可见发件人、信封域和受信任的 Authentication-Results。捕获每个DKIM d= 和 s= 对并查询匹配的公共记录。
DKIM将签名绑定到其签名域；仅仅在组织域下的某个地方找到公钥并不能证明观察到的消息使用了它。确认预期的签名已在接收者处通过。对于失败的签名，在替换记录之前区分丢失密钥、错误密钥和消息修改。 DKIM RFC 6376
DMARC 需要与可见的发件人域一致的传递SPF或DKIM机制。提供商域身份验证通行证可能未对齐。保留准确的 结盟 证据中的模式、域关系和适用策略。不需要这两种机制都作为DMARC的定义传递，尽管维护这两种机制可以提高跨不同传递条件的弹性。 DMARC RFC 9989
如果转发对业务很重要，则应该单独观察。 SMTP路径的更改可能会影响SPF ，签名内容的更改可能会影响DKIM 。直邮成功并不能保证每一次转发安排。不要仅仅为了使无法解释的转发消息显得成功而削弱组织的政策。
推出后维护单独的邮件流
Rackspace 的声誉指南建议按用途区分邮件，并为不同的发送服务使用单独的签名密钥。使用该原则可以使托管的员工邮件路由与营销或交易系统区分开来。其示例政策选择不能替代特定于组织的执行审查。 Rackspace 域名声誉指导
维护域、服务、选择器、 SPF授权和所有者的注册。当服务停用时，请验证其流量是否已结束并安排批准的删除，而不是累积永久未使用的授权。添加发件人后，在将其视为早期邮箱测试所覆盖之前，需要提供新路由的证据。
Rackspace 验收工作表
为每个产品和出站路线分别填写此建议工作表。它不包含实时客户观察。
- 产品范围：Rackspace 服务、租户、支持的域、控制面板访问、管理员和任何特定于产品的支持确认。
- 发送路由：邮箱客户端、Webmail、应用程序、提交端点、中继、预期发件人和信封标识。
- DKIM设置：启用状态、当前生成的所有者和公共值、 DNS管理位置、验证结果以及确切错误（如果有）。
- DNS证据：权威名称服务器、完整记录所有者、已发布密钥或支持的目标、 SPF策略、TTL 和捕获时间。
- 消息证据：安全测试标识符、接收者、时间戳、 DKIM域和选择器、可信结果以及提供对齐的机制。
- 依赖关系：使用相同域的其他服务、单独的应用程序路由、转发案例和未经测试的产品。
- 发布决策：产品范围保留、回滚所有者、变更批准、SME 审查和发布状态。
虚构诊断错误产品中的钥匙
这个例子是虚构的。管理员遵循一般的 Rackspace Cloud DNS文章，创建公钥记录，并期望托管邮箱消息使用它。下一个测试未使用该选择器进行签名，因此管理员考虑生成另一个密钥。
拟议的调查首先确定托管产品并检查其支持的 Cloud Office 签名控制。团队获取实际的托管域指令，根据需要发布相应的公共值，并测试新的邮箱消息。托管在单独云服务器上的网站仍然需要自己的路由评估。单独发布密钥不能使不相关的系统拥有或使用匹配的私钥。此场景是诊断说明，而不是完整的配置。
产品范围和发布门槛
确切的客户产品、域资格、租户生成的值、权威DNS和收到的身份验证结果仍未得到验证。如果没有特定于产品的确认，则不会断言托管 Exchange、 Microsoft 365和自我管理云服务器配置遵循此过程。人类 SME 审查、目视审查、实时邮箱和应用程序测试以及出版批准仍在等待中。在其范围证据完成之前，候选人必须保持不公开状态。
保持托管产品决策的明确性
虚构的情况仅规定观察到的消息不使用手动选择的选择器。其实际的DKIM和SPF结果尚未明确。可能存在不同的有效签名，因此在诊断签名中断之前检查所有签名。在建议更换密钥之前，记录支持的邮箱产品和控制面板说明。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求发布p=reject域具有有效的DKIM ，并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。