范围：Cloud Mail 并非所有 Web.com 服务
本指南保留了目录的 Web.com 身份验证主题，但将记录的实施限制为 Cloud Mail SPF。这不是经过验证的 DKIM 每个 Web.com 电子邮件包的配置指南。可用的提供商指南是较旧的云邮件捕获，因此在更改之前必须确认当前帐户的适用性。仅凭这一事实，从 Web.com 购买的域名并不能识别其出站电子邮件服务。从订阅和发送路径开始，而不是从注册商徽标开始。
云邮件页面将其产品与其他电子邮件产品区分开来。它将SPF在其整体DNS设置中列为可选。它的正常示例是v=spf1 include:spf.cloudus.oxcs.net ~all 。对于托管包或网站联系表单，它包含spf.registeredsite.com和spf.cloudus.oxcs.net 。它需要一个 SPF记录。这些是记录的示例，而不是根据当前客户帐户验证的值。 Web.com 云邮件DNS设置
在选择策略之前先确定路线
创建一个小的消息生成应用程序清单。区分通过托管邮箱提交的人员与生成通知的网站、使用相同可见地址的营销平台以及第三方计费服务。对于每条路线，确定可以确认其实际配置的团队。明确记录不确定性。域或网站的购买收据不足以证明每个应用程序都使用相同的出站基础设施。
SPF策略描述了SMTP身份的授权发送基础结构。它并不简单地验证可见发件人字段包含域的每条消息。相关信封标识可以与该可见字段不同。当网站通过其他服务提交或应用程序使用提供商控制的服务时，这一点很重要 退回地址。策略可能在语法上是正确的，但与正在评估的身份无关。 RFC 7208 ， HELO和 MAIL FROM 身份
因此，清单应将已知事实与等待帐户访问的问题区分开来。标记可见的作者域、预期的信封域、预期的提交路径和应用程序所有者。将未知值留空，而不是从网络邮件地址派生它们。这是拟议的证据收集计划，而不是已检查任何消息的报告。
准备SPF时保留现有发件人
求婚前 一个记录，通过授权变更流程保留当前权威TXT响应及其收集时间。识别相关所有者名称处的单个SPF策略。其他 TXT记录 可以以该名称共存，但多个SPF策略不能通过简单地选择最新的策略来解决。一个TXT资源记录中的多个字符串也不同于多个资源记录。 RFC 7208 ， DNS资源记录和多个字符串
准备前后比较，以保留仍授权的发件人。不要仅仅因为示例看起来更容易理解而用简短的提供程序示例替换生产策略。最终的全部机制也表达了政策意图。以softfail结尾的示例并不授权削弱现有策略，更严格的结尾也不会使未经审核的发件人清单完整。
查看完整的评估路径，包括嵌套包含。 SPF限制涉及评估的 DNS 查询术语，而不仅仅是顶级字符串中可见包含单词的数量。缓存不会使过多的策略变得有效。将提议的依赖性审查与当前实时评估成功的声明分开捕获。这里没有断言这样的评估。 RFC 7208 ， DNS查找限制并包括
将路由和身份验证更改分开
身份验证更改不应悄悄成为邮箱迁移。更改的所有者应解释为什么每个提议的DNS编辑都是必要的。邮箱目标更改与SPF授权更改具有不同的服务后果。回滚计划必须特定于实际批准的记录，而不是从旧导出恢复整个区域的广泛指令。
这种分离还可以保护不相关的应用程序。域可以托管公共网站、传入邮件、服务发现记录和委托的第三方服务。身份验证工作表应标识确切的所有者名称、类型和预期内容。在不了解后果的情况下，不应要求运营商复制整个提供商DNS表。 DNS表示可以使用相对名称或绝对名称，具体取决于编辑器；操作员必须确认最终的所有者名称，而不是假设通用接口规则。 RFC 1035 ，主文件格式
DKIM和DMARC仍然是单独的验收问题
记录的SPF范围不提供经过验证的云邮件 DKIM选择器、公钥或签名激活过程。这些领域仍然悬而未决。不要发明默认选择器、从不同的托管产品借用密钥或将SPF包含的存在视为消息已签名的证据。 DKIM验证取决于签名的签名域和选择器以及相应的已发布密钥。托管支持安全电子邮件并不是通过一般性声明来确定的。 RFC 6376 、 DKIM-Signature和密钥存储
DMARC 需要传递经过身份验证的标识符以及与可见作者域的所需关系。为不相关的信封域传递SPF是不够的。相反，即使SPF不对齐，对齐的通过DKIM也可以提供合格的身份验证路径。运营审查应该记录哪条路径支持每条实际路线，而不是要求发明一个通用组合。身份验证不能保证收件箱的放置或证明消息的业务请求是合法的。 RFC 9989 ，标识符对齐和范围
虚构诊断：两种应用，一种假设路线
以虚构的组织马林工作室为例。其管理员将“Web.com”列为员工电子邮件和网站收据的所有者。提议的更改复制最短的SPF示例并删除现有授权，而不检查哪个应用程序仍在使用它。这是一个虚构的计划错误，而不是报告的事件或执行的测试。
审阅者停止更改并将两个申请行分开。员工邮箱所有者必须识别实际产品。网站所有者必须确定如何提交收据。 DNS运营商保留现有政策，并仅在获得这些事实后才准备审查比较。如果路线不同，他们的证据也一定不同。该诊断是关于共享基础设施的不受支持的假设，而不是特定提供商未能验证邮件的证据。
空白验收工作表
仅根据授权的观察结果填写此工作表。空单元格意味着未解决的证据，而不是失败的实时测试。
- 产品和订阅证据：______
- 当前提供商确认信息和日期：______
- 申请及责任人：______
- 可见作者域：______
- 实际信封身份和证据：______
- 当前权威SPF所有者及价值：______
- 保留发件人的拟议变更：______
- 嵌套依赖和查找限制审查：______
- DKIM功能、选择器和激活证据：______
- 实际对齐的认证结果：______
- 变更批准、回滚和观察窗口：______
发布边界
本手稿提供了范围审查方法，而不是完整的配置。当前的产品适用性、生成的帐户价值、权威出版物、收到的消息证据、人类主题审查、生产路线、视觉可访问性和所有者发布仍然开放。该目录更广泛的实施证据要求没有变化。此草案未执行任何DNS编辑、支持请求、消息或租户测试。