设置 SPF 以识别 Microsoft 365 域的有效电子邮件源

发件人策略框架 (SPF) 是一种 电子邮件身份验证 方法，可帮助验证从 Microsoft 365 组织发送的邮件，以防止商业电子邮件泄露 (BEC) 、勒索软件和其他网络钓鱼攻击中使用的欺骗性发件人。

SPF 的主要用途是验证域的电子邮件源。 具体而言，SPF 使用 DNS 中的 TXT 记录来标识域的有效邮件源。 接收电子邮件系统使用 SPF TXT 记录来验证邮件 SMTP 传输期间使用的发件人地址的电子邮件 (称为 MAIL 发件人地址、 5321.MailFrom 地址、P1 发件人或信封发件人，) 来自该域的已知指定邮件源。

例如，如果 Microsoft 365 中的电子邮件域 contoso.com，则你在 DNS 中为 contoso.com 域创建 SPF TXT 记录，以将 Microsoft 365 标识为来自 contoso.com 的授权邮件源。 目标电子邮件系统检查 contoso.com 中的 SPF TXT 记录，以确定邮件是否来自 contoso.com 电子邮件的授权源。

在开始之前，你需要根据你的电子邮件域了解以下有关 Microsoft 365 中的 SPF 的信息：

• 例如，如果仅将 Microsoft Online Email 路由地址 (MOERA) 域用于电子邮件 (，则无需执行任何操作 contoso.onmicrosoft.com) ： 已为你配置 SPF TXT 记录。 Microsoft 拥有 onmicrosoft.com 域，因此我们负责在该域和子域中创建和维护 DNS 记录。 有关 *.onmicrosoft.com 域的详细信息，请参阅 为什么我有“onmicrosoft.com”域？。

• 例如，如果你对电子邮件 (使用一个或多个自定义域，contoso.com) ：Microsoft 365 注册过程已要求你在 DNS 中创建或修改自定义域的 SPF TXT 记录，以将 Microsoft 365 标识为授权邮件源。 但是，你还需要做更多的工作来最大程度地保护电子邮件：

  • 子域注意事项：

    • 对于不受直接控制的电子邮件服务 (例如批量电子邮件服务) ，我们建议使用子域 (例如，marketing.contoso.com) 而不是main电子邮件域 (contoso.com) 。 你不希望从这些电子邮件服务发送的邮件问题影响main电子邮件域中员工发送的邮件的信誉。 有关添加子域的详细信息，请参阅 是否可以将自定义子域或多个域添加到 Microsoft 365？。

    • 用于从 Microsoft 365 发送电子邮件的每个子域都需要其自己的 SPF TXT 记录。 例如，contoso.com 的 SPF TXT 记录不涵盖 marketing.contoso.com;marketing.contoso.com 需要自己的 SPF TXT 记录。

      提示

      DMARC 涵盖对未定义子域的Email身份验证保护。 (定义或未定义的任何子域) 继承父域 (的 DMARC 设置，) 可重写每个子域。 有关详细信息，请参阅 设置 DMARC 以验证 Microsoft 365 中发件人的 From 地址域。

  • 如果您拥有已注册但未使用的域：如果您拥有不用于电子邮件的注册域或任何 (也称为 ) 的寄存域 ，请配置 SPF TXT 记录以指示任何电子邮件不应来自这些域，如本文稍后所述。

• 仅靠 SPF 是不够的。 为了获得自定义域的最佳电子邮件保护级别，还需要将 DKIM 和 DMARC 配置为整体 电子邮件身份验证 策略的一部分。 有关详细信息，请参阅本文末尾的 后续步骤 部分。

  重要

  在难以识别域的所有有效邮件源的复杂组织中，请务必在“不采取任何操作”模式下快速配置 DKIM 签名和 DMARC (，) 域。 DMARC 报告服务非常有助于识别域的电子邮件源和 SPF 故障。

本文的其余部分介绍了你需要为 Microsoft 365 中的自定义域创建的 SPF TXT 记录。

SPF TXT 记录的语法

RFC 7208 中详细描述了 SPF TXT 记录。

Microsoft 365 中自定义域的 SPF TX 记录的基本语法是：

v=spf1 <valid mail sources> <enforcement rule>

或：

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

例如：

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

• v=spf1 将 TXT 记录标识为 SPF TXT 记录。

• 有效邮件源：为域指定了有效的邮件源。 使用 域和/或 IP 地址：

  • 域： include: 值将其他服务或域指定为来自原始域的有效邮件源。 这些值最终导致使用 DNS 查找的 IP 地址。

    大多数 Microsoft 365 组织要求 include:spf.protection.outlook.com 在 SPF TXT 记录中输入域。 其他第三方电子邮件服务通常需要一个额外的 include: 值，以将服务标识为来自原始域的有效电子邮件源。

  • IP 地址：IP 地址值包括以下两个元素：

    • 值 ip4: 或 ip6: ，用于标识 IP 地址的类型。
    • 源电子邮件系统的可公开解析 IP 地址。 例如：
      • 单个 IP 地址 (，例如 192.168.0.10) 。
      • 使用无类 Inter-Domain 路由 (CIDR) 表示法 (的 IP 地址范围，例如 192.168.0.1/26) 。 请确保范围不是太大或太小。

    在 Microsoft 365 中，仅当本地电子邮件服务器从 Microsoft 365 域发送邮件 (时，通常才使用 SPF TXT 记录中的 IP 地址，例如，Exchange Server混合部署) 。 某些第三方电子邮件服务可能还会使用 IP 地址范围， include: 而不是 SPF TXT 记录中的值。

• 强制规则：告知目标电子邮件系统如何处理来自域的 SPF TXT 记录中未指定的源的邮件。 有效值包含:

  • -all (硬故障) ：SPF TXT 记录中未指定的源无权为域发送邮件，因此应拒绝邮件。 邮件实际发生的情况取决于目标电子邮件系统，但邮件通常会被丢弃。

    对于 Microsoft 365 域，我们建议 -all (硬故障) ，因为我们还建议将 DKIM 和 DMARC 用于域。 DMARC 策略指定对 SPF 或 DKIM 失败的消息执行的操作，DMARC 报告允许验证结果。

    提示

    如前所述，使用 DMARC 报告服务配置的 DMARC 极大地有助于识别域的电子邮件源和 SPF 故障。

  • ~all (软失败) ：未在 SPF TXT 记录中指定的源 可能 无权为域发送邮件，因此应接受但标记邮件。 邮件实际发生的情况取决于目标电子邮件系统。 例如，邮件可能被隔离为垃圾邮件、传递到“垃圾邮件Email”文件夹，或者使用添加到主题或邮件正文的标识符传递到收件箱。

    由于我们还建议将 DKIM 和 DMARC 用于 Microsoft 365 域，因此， (硬故障) 与 ~all (软故障) 之间的差异-all将有效地消除 (DMARC 将任一结果视为 SPF 故障) 。 DMARC 使用 SPF 确认 MAIL FROM 和 From 地址中的域是否一致 ，并且 邮件来自源域的有效源。

  提示

  ?all (中性) 也可用于建议对来自不明来源的消息采取任何特定操作。 此值用于测试，不建议在生产环境中使用此值。

需要记住的要点：

• DNS 中每个定义的域或子域都需要一条 SPF TXT 记录，并且每个域或子域只允许一条 SPF 记录。 Email对未定义的子域的身份验证保护最好由 DMARC 处理。
• 无法修改 *.onmicrosoft.com 域的现有 SPF TXT 记录。
• 当目标电子邮件系统检查 SPF 记录中的有效电子邮件源时，如果检查需要太多 DNS 查找，则 SPF 验证将失败。 有关详细信息，请参阅本文后面的 排查 SPF TXT 记录 问题部分。

Microsoft 365 中自定义域的 SPF TXT 记录

• 场景：你对 Microsoft 365 中的电子邮件使用 contoso.com，而 Microsoft 365 是来自 contoso.com 的唯一电子邮件源。

  Microsoft 365 和 Microsoft 365 政府社区云中 contoso.com 的 SPF TXT 记录 (GCC) ：

  v=spf1 include:spf.protection.outlook.com -all
  

  Microsoft 365 政府社区云高 (GCC High) 和 Microsoft 365 国防部 (DoD) 中 contoso.com 的 SPF TXT 记录 ：

  v=spf1 include:spf.protection.office365.us -all
  

  由世纪互联运营的 Microsoft 365中 contoso.com 的 SPF TXT 记录

  v=spf1 include:spf.protection.partner.outlook.cn -all
  

• 场景：在 Microsoft 365 中对电子邮件使用 contoso.com，并且已在 contoso.com 中配置了 SPF TXT 记录，其中包含来自域的所有电子邮件源。 你还拥有 contoso.net 和 contoso.org 域，但不会将其用于电子邮件。 你想要指定没有人有权从 contoso.net 或 contoso.org 发送电子邮件。

  contoso.net 的 SPF TXT 记录：

  v=spf1 -all
  

  contoso.org 的 SPF TXT 记录：

  v=spf1 -all
  

• 方案：在 Microsoft 365 中对电子邮件使用 contoso.com。 你计划从以下来源发送邮件：

  • 外部电子邮件地址为 192.168.0.10 的本地电子邮件服务器。 由于你可以直接控制此电子邮件源，因此我们认为可以将服务器用于 contoso.com 域中的发件人。
  • Adatum 批量邮件服务。 由于你无法直接控制此电子邮件源，因此我们建议使用子域，因此请为此创建 marketing.contoso.com。 根据 Adatum 服务文档，需要将 添加到 include:servers.adatum.com 域的 SPF TXT 记录。

  contoso.com 的 SPF TXT 记录：

  v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all
  

  marketing.contoso.com 的 SPF TXT 记录：

  v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all
  

排查 SPF TXT 记录问题

• 每个域或子域一条 SPF 记录：同一域或子域的多个 SPF TXT 记录会导致 DNS 查找循环失败，因此每个域或子域仅使用一条 SPF 记录。

• 少于 10 个 DNS 查找：当目标电子邮件系统在 SPF TXT 记录中查询 MAIL FROM 地址域的有效源时，查询会扫描记录中的 IP 地址和 include: 语句，直到邮件源最终 (，IP 地址) 与指定的源之一匹配。 如果 DNS 查找数 (可能不同于) DNS 查询 数大于 10，则消息失败 SPF 并显示永久错误 (也称为 permerror) 。 目标电子邮件系统拒绝未送达报告中的邮件， (也称为 NDR 或 退回邮件) 并出现以下错误之一：

  • 邮件超出跃点计数。
  • 邮件需要的查找次数过多。

  在 SPF TXT 记录中，单个 IP 地址或 IP 地址范围不会导致 DNS 查找。 每个 include: 语句至少需要一个 DNS 查找，如果值指向嵌套资源， include: 则可能需要更多查找。 换句话说，少于 10 include: 个语句并不保证 DNS 查找数少于 10 个。

  还要记住：目标电子邮件系统从左到右评估 SPF TXT 记录中的源。 验证消息源时，评估将停止，并且不再检查源。 因此，SPF TXT 记录可能包含足够的信息，导致 10 个以上的 DNS 查找，但某些目标对某些邮件源的验证在记录中不够深入，导致错误。

  除了保留main电子邮件域的信誉外，不超过 DNS 查找次数是将子域用于你无法控制的其他电子邮件服务的另一个原因。

可以使用免费的联机工具查看你的域的 SPF TXT 记录和其他 DNS 记录。 某些工具甚至计算 SPF TXT 记录所需的 DNS 记录查找数。

后续步骤

如 SPF、DKIM 和 DMARC 如何协同对电子邮件发件人进行身份验证中所述，仅 SPF 不足以防止 Microsoft 365 域的欺骗。 还需要配置 DKIM 和 DMARC 以获得最佳保护。 有关说明，请参阅以下内容：

• 使用 DKIM 验证从自定义域发送的出站电子邮件
• 使用 DMARC 验证电子邮件

对于 传入 Microsoft 365 的邮件，如果使用在传递到组织之前修改传输中的邮件的服务，则可能还需要配置受信任的 ARC 封口器。 有关详细信息，请参阅 配置受信任的 ARC 密封器。