通过

Microsoft 365 中的电子邮件身份验证

提示

你知道可以免费试用Microsoft Defender for Office 365计划 2 中的功能吗？ 在 Microsoft Defender 门户试用中心使用 90 天Defender for Office 365试用版。 了解谁可以在试用Microsoft Defender for Office 365上注册和试用条款。

作为Microsoft 365 组织，在 Exchange Online 中具有邮箱，或者没有Exchange Online邮箱的独立Exchange Online Protection (EOP) 组织，保护域中发件人的电子邮件的完整性非常重要。 收件人应确信域中发件人的邮件确实来自域中的发件人。

Email身份验证 (也称为电子邮件验证) 是一组标准，用于识别和防止来自伪造发件人的电子邮件传递 (也称为欺骗) 。 欺骗发件人通常用于商业电子邮件入侵 (BEC) 、网络钓鱼和其他电子邮件攻击。 这些标准包括：

  • 发件人策略框架 (SPF) ：指定有权为域发送邮件的源电子邮件服务器。
  • 域密钥标识邮件 (DKIM) ：使用域对邮件的重要元素进行数字签名，以确保邮件在传输过程中未被更改。
  • 基于域的消息身份验证、报告和符合性 (DMARC) ：指定未通过 SPF 或 DKIM 检查域中发件人的消息的操作，并指定将 DMARC 结果发送到何处 (报告) 。
  • 经过身份验证的接收链 (ARC) ：保留修改传输中邮件的已知服务的原始电子邮件身份验证信息。 目标电子邮件服务器可以使用此信息对将失败 DMARC 的邮件进行身份验证。

请务必认识到，这些标准是 相互依赖的构建基块 ，它们 协同工作 ，以提供针对欺骗和网络钓鱼攻击的最佳电子邮件保护。 任何低于所有电子邮件身份验证方法的内容都会导致保护不合格。

若要配置来自 Microsoft 365 个组织（邮箱位于 Exchange Online 或独立Exchange Online Protection (EOP) 组织中没有Exchange Online邮箱）的邮件的电子邮件身份验证，请参阅以下文章：

若要防止由于服务修改发送到 Microsoft 365 组织的 入站 邮件而导致电子邮件身份验证失败，请参阅 配置受信任的 ARC 封口器。

本文的其余部分将介绍：

提示

作为本文的配套内容，请参阅我们的Microsoft Defender for Office 365设置指南，以查看最佳做法并防范电子邮件、链接和协作威胁。 功能包括安全链接、安全附件等。 对于基于环境的自定义体验，可以访问Microsoft 365 管理中心中的Microsoft Defender for Office 365自动设置指南。

为什么 Internet 电子邮件需要身份验证

根据设计，Internet 上的简单邮件传输协议 (SMTP) 电子邮件不会尝试验证邮件发件人是否是他们声称的发件人。

标准 SMTP 电子邮件由 邮件信封和邮件 内容组成：

  • 邮件信封包含用于在 SMTP 服务器之间传输和接收邮件的信息。 RFC 5321 中介绍了邮件信封。 收件人永远不会看到邮件信封，因为它是在邮件传输过程中生成的。
  • 邮件内容包含邮件头字段（统称为邮件头）和邮件正文。 RFC 5322 中介绍了消息标头。

由于此设计，邮件具有多个发件人值：

  • MAIL FROM 地址 (也称为 5321.MailFrom 地址、P1 发件人或信封发件人) 是用于在 SMTP 电子邮件服务器之间传输邮件的电子邮件地址。 此地址通常记录在邮件头 (的 “返回路径 ”标头字段中，尽管源电子邮件服务器可以指定不同的 “返回路径 ”电子邮件地址) 。 此电子邮件地址用于未送达报告 (也称为) 退回邮件或退回邮件。
  • 发件人地址 (也称为 5322.From 地址或 P2 发件人) 是 发件人 标头字段中的电子邮件地址，是电子邮件客户端中显示的发件人电子邮件地址。

以下示例显示了两个 SMTP 电子邮件服务器之间有效邮件传输的简化脚本：

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

在此示例中：

  • 源电子邮件服务器在 HELO 命令中将自己标识为目标电子邮件服务器 tailspintoys.com woodgrovebank.com。
  • 邮件收件人为 astobes@tailspintoys.com。
  • 邮件信封中的 MAIL FROM 地址 (用于在 SMTP 电子邮件服务器) dubious@proseware.com之间传输邮件。
  • 收件人的电子邮件客户端中显示的发件人地址为 security@woodgrovebank.com。

尽管此邮件根据 SMTP 有效，但 MAIL FROM 地址 (proseware.com) 的域与发件人地址 (woodgrovebank.com) 中的域不匹配。 此邮件是欺骗的经典示例，其中意图可能会通过屏蔽邮件的真实来源来欺骗收件人，以用于网络钓鱼攻击。

显然，SMTP 电子邮件需要帮助来验证邮件发件人是否是他们声称的！

SPF、DKIM 和 DMARC 如何协同工作来对电子邮件发件人进行身份验证

本部分介绍 Internet 上的域需要 SPF、DKIM 和 DMARC 的原因。

  • SPF：如 设置 SPF 以识别 Microsoft 365 域的有效电子邮件源中所述，SPF 使用 DNS 中的 TXT 记录来标识来自 MAIL FROM 域的有效邮件源，以及如果目标电子邮件服务器接收来自未定义源的邮件， (“很难”拒绝邮件，该怎么办;“软失败”接受并将消息标记为) 。

    SPF 问题：

    • SPF 仅验证 MAIL FROM 域中发件人的源。 SPF 不考虑“发件人”地址中的域，也不考虑 MAIL FROM 和 From 域之间的对齐方式：

      • 攻击者可以通过以下步骤发送通过 SPF 身份验证 (假负) 的电子邮件：
        • (注册域，例如，为域 proseware.com) 和配置 SPF。
        • 从已注册域的有效源发送电子邮件，使用其他域中的发件人电子邮件地址 (例如，woodgrovebank.com) 。
      • 代表其他域发送邮件的合法电子邮件服务可能会控制 MAIL FROM 地址。 其他域和 MAIL FROM 域不匹配，因此邮件无法通过 SPF 身份验证 (误报) 。

    • 邮件遇到重定向或 中继 邮件的基于服务器的电子邮件转发后，SPF 中断。

      • 基于服务器的电子邮件转发将邮件源从原始服务器更改为转发服务器。
      • 转发服务器无权从原始 MAIL FROM 域发送邮件，因此邮件无法通过 SPF 身份验证 (误报) 。

    • 每个域和任何子域都需要其自己的单个 SPF 记录。 子域不继承父域的 SPF 记录。 如果想要允许来自已定义和已使用子域的电子邮件，但阻止来自未定义和未使用的子域的电子邮件，则此行为将变得有问题。

  • DKIM：如 设置 DKIM 以对来自 Microsoft 365 域的邮件进行签名中所述，DKIM 使用域对邮件 (的重要元素（包括发件人地址) ）进行数字签名，并将签名存储在邮件头中。 目标服务器验证消息的已签名元素是否未更改。

    DKIM 如何帮助 SPF：DKIM 可以验证 SPF 失败的消息。 例如：

    • 来自电子邮件托管服务的邮件，其中同一 MAIL FROM 地址用于来自其他域的邮件。
    • 遇到基于服务器的电子邮件转发的邮件。

    由于消息标头中的 DKIM 签名在这些情况下不会受到影响或更改，因此这些消息能够传递 DKIM。

    DKIM 问题：DKIM 用于对邮件进行签名的域不需要与电子邮件客户端中显示的“发件人”地址中的域匹配。

    与 SPF 一样，攻击者可以按照以下步骤发送通过 DKIM 身份验证 (假负) 的电子邮件：

    • (注册域，例如，proseware.com) 并配置域的 DKIM。
    • 使用不同域中的发件人电子邮件地址发送电子邮件 (例如，woodgrovebank.com) 。

  • DMARC：如设置 DMARC 以验证 Microsoft 365 中发件人的发件人的 From 地址域中所述，DMARC 使用 SPF 和 DKIM 来检查 MAIL FROM 和 From 地址中的域之间的一致性。 DMARC 还指定目标电子邮件系统应对失败 DMARC 的邮件执行的操作，并标识 (通过和失败) 发送 DMARC 结果的位置。

    DMARC 如何帮助 SPF 和 DKIM：如前所述，SPF 不会尝试匹配 MAIL FROM 域和 From 地址中的域。 DKIM 不关心对消息进行签名的域是否与发件人地址中的域匹配。

    DMARC 通过使用 SPF 和 DKIM 来确认 MAIL FROM 和 From 地址中的域是否匹配，从而解决了这些缺陷。

    DMARC 问题：在传递之前修改传输中的消息的合法服务会中断 SPF、DKIM，因此 DMARC 检查。

  • ARC：如 配置受信任的 ARC 密封器中所述，修改传输中邮件的合法服务可以使用 ARC 保留修改邮件的原始电子邮件身份验证信息。

    ARC 如何帮助 DMARC：目标电子邮件系统可将服务标识为受信任的 ARC 密封器。 然后，ARC 可以使用保留的电子邮件身份验证信息来验证邮件。

发送到 Microsoft 365 的邮件的入站电子邮件身份验证

由于网络钓鱼问题以及 Internet 上电子邮件发件人对强电子邮件身份验证策略的完全采用程度不足，Microsoft 365 使用隐式电子邮件身份验证来检查入站电子邮件。 隐式电子邮件身份验证使用来自其他源的信号来评估入站电子邮件，从而扩展了常规 SPF、DKIM 和 DMARC 检查。 这些源包括：

  • 发件人信誉。
  • 发件人历史记录。
  • 收件人历史记录。
  • 行为分析。
  • 其他高级技术。

若要查看Microsoft关于隐式身份验证的原始公告，请参阅 钓鱼之海第 2 部分 - Microsoft 365 中的增强反欺骗。

通过使用这些其他信号，通过传统电子邮件身份验证检查失败的邮件可以通过隐式身份验证并允许进入 Microsoft 365。

复合身份验证

Microsoft 365 的隐式身份验证检查的结果合并并存储在名为 复合身份验证 或 compauth 简称的单个值中。 可以在邮件头的“compauthAuthentication-Results”标头中标记 值。 Authentication-Results 标头使用以下语法：

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Authentication-results 邮件头对这些值进行了说明。

管理员和用户可以检查邮件头，以发现 Microsoft 365 如何将发件人识别为可疑的欺骗发件人或合法发件人。

提示

请务必了解，复合身份验证失败不会直接导致消息被阻止。 我们的系统使用整体评估策略，该策略考虑消息的整体可疑性质以及复合身份验证结果。 此方法旨在降低错误地阻止来自可能未严格遵循电子邮件身份验证协议的域的合法电子邮件的风险。 这种平衡的方法有助于将真正的恶意电子邮件与根本不符合标准电子邮件身份验证做法的邮件发件人区分开来。

以下示例重点介绍电子邮件身份验证的结果，仅 (compauth 值和原因) 。 其他Microsoft 365 保护技术可以将通过电子邮件身份验证的邮件识别为欺骗邮件，或将电子邮件身份验证失败的邮件识别为合法邮件。

  • 场景：SPF 记录中的域或 DKIM 签名与 From 地址中的域不匹配。

  • 结果：该消息可能无法通过复合身份验证。 尽管复合身份验证失败，但如果其他评估未指示可疑性质，仍可能允许该消息：

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • 场景：fabrikam.com 域没有 SPF、DKIM 或 DMARC 记录。

  • 结果：来自 fabrikam.com 域中发件人的消息可能会使复合身份验证失败：

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • 场景：fabrikam.com 域具有 SPF 记录，没有 DKIM 记录。 MAIL FROM 和 From 地址中的域匹配。

  • 结果：消息可以通过复合身份验证，因为传递 SPF 的域与发件人地址中的域匹配：

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • 方案：fabrikam.com 域具有没有 SPF 记录的 DKIM 记录。 DKIM 对消息进行签名的域与“发件人”地址中的域匹配。

  • 结果：消息可以通过复合身份验证，因为 DKIM 签名中的域与 From 地址中的域匹配：

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • 场景：SPF 记录中的域或 DKIM 签名与 From 地址中的域不匹配。

  • 结果：该消息可能无法通过复合身份验证：

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

如何在向 Microsoft 365 发送邮件时避免电子邮件身份验证失败

提示

Microsoft 365 客户可以使用以下方法来允许来自标识为欺骗或身份验证失败的发件人的邮件：

  • 为域配置 SPF、DKIM 和 DMARC 记录：使用域注册机构或 DNS 托管服务提供的配置信息。 还有一些第三方公司致力于帮助设置电子邮件身份验证记录。

    许多公司不发布 SPF 记录，因为他们不知道其域中邮件的所有电子邮件来源。

    1. 首先发布一条 SPF 记录，其中包含你知道的所有电子邮件源 (尤其是公司流量) 所在的位置，并使用强制规则值“软失败” (~all) 。 例如：

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      如果创建此 SPF 记录，Microsoft 365 会将来自公司基础结构的入站电子邮件视为经过身份验证，但如果来自不明来源的电子邮件未能通过复合身份验证，则可能仍可能标记为欺骗。 但是，对于Microsoft 365 标记为欺骗的域中发件人的所有电子邮件，此行为仍有所改进。 通常，当 SPF 配置软失败强制规则时，目标电子邮件系统接受来自域中发件人的邮件，邮件来源不明。

    2. 发现并包含邮件的更多电子邮件源。 例如：

      • 本地电子邮件服务器。
      • 通过软件即服务 (SaaS) 提供程序发送的电子邮件。
      • 通过云托管服务（Microsoft Azure、GoDaddy、Rackspace、Amazon Web Services 等）发送的电子邮件。

      确定域的所有电子邮件源后，可以更新 SPF 记录，以使用强制规则值“硬失败” (-all) 。

    3. 设置 DKIM 以对消息进行数字签名。

    4. 设置 DMARC 以验证 MAIL FROM 和 From 地址中的域是否匹配，以指定如何处理未通过 DMARC 检查的邮件 (拒绝或隔离) ，并确定报告服务以监视 DMARC 结果。

    5. 如果使用批量发件人代表你发送电子邮件，请验证发件人地址中的域是否与通过 SPF 或 DMARC 的域匹配。

  • 托管域的电子邮件或提供可发送电子邮件的托管基础结构：

    • 确保客户有说明如何为其域配置 SPF 的文档。
    • 请考虑对 DKIM 出站邮件进行签名，即使客户未在其域中显式设置 DKIM， (使用默认域) 进行签名。 甚至可以使用 DKIM 签名对电子邮件进行双重签名， (公司域和客户的域（如果/何时可用）) 。

    即使你对源自平台的电子邮件进行身份验证，也无法保证发送到Microsoft。 但是，电子邮件身份验证可确保Microsoft不会因为未经身份验证而自动将来自客户域的电子邮件垃圾邮件。