提示
你知道可以免费试用Office 365计划 2 Microsoft Defender 中的功能吗？ 在 Microsoft Defender 门户试用中心使用为期 90 天的 Defender 进行Office 365试用。 在试用 Microsoft Defender for Office 365中了解哪些用户可以注册，以及试用条款。
作为一个拥有云邮箱的组织，保护域中发件人的电子邮件的完整性非常重要。 收件人应确信域中发件人的邮件确实来自域中的发件人。
Email身份验证 (也称为电子邮件验证) 是一组标准，用于识别和防止来自伪造发件人的电子邮件传递 (也称为欺骗) 。 欺骗发件人通常用于商业电子邮件入侵 (BEC) 、网络钓鱼和其他电子邮件攻击。 这些标准包括：
- 发件人策略框架 (SPF) ：指定有权为域发送邮件的源电子邮件服务器。
- 域密钥标识邮件 (DKIM) ：使用域对邮件的重要元素进行数字签名，以确保邮件在传输过程中保持不变。
- 基于域的消息身份验证、报告和符合性 (DMARC) ：指定未通过 SPF 或 DKIM 检查域中发件人的消息的操作，并指定将 DMARC 结果发送到何处 (报告) 。
- 已验证接收链 (ARC)：保留电子邮件在传输过程中被已知服务修改时的原始身份验证信息。 目标电子邮件服务器可以使用此信息对原本会无法通过 DMARC 验证的邮件进行身份验证。
请务必认识到，这些标准是 相互依赖的构建基块 ，它们 协同工作 ，以提供针对欺骗和网络钓鱼攻击的最佳电子邮件保护。 任何低于所有电子邮件身份验证方法的内容都会导致保护不合格。
若要使用云邮箱为从 Microsoft 365 组织 发送 的邮件配置电子邮件身份验证，请参阅以下文章：
若要防止由于服务修改发送到 Microsoft 365 组织的 入站 邮件而导致电子邮件身份验证失败，请参阅 配置受信任的 ARC 封口器。
若要诊断和修复电子邮件身份验证失败，请参阅 排查 Microsoft 365 中的电子邮件身份验证问题。
本文还介绍了为什么 Internet 电子邮件需要身份验证、SPF、DKIM 和 DMARC 如何协同工作来验证电子邮件发件人的身份、Microsoft如何使用隐式和复合电子邮件身份验证来检查发送到Microsoft 365的入站邮件，以及如何避免向Microsoft 365发送电子邮件时的电子邮件身份验证失败。
提示
作为本文的配套内容，请参阅我们的Microsoft Defender Office 365设置指南，以查看最佳做法并防范电子邮件、链接和协作威胁。 功能包括安全链接、安全附件等。 对于基于环境的自定义体验，可以访问Microsoft 365 管理中心中的Office 365自动设置指南Microsoft Defender。
为什么 Internet 电子邮件需要身份验证
根据设计，Internet 上的简单邮件传输协议 (SMTP) 电子邮件不会尝试验证邮件发件人是否是他们声称的发件人。
标准 SMTP 电子邮件由 邮件信封和邮件 内容组成：
- 邮件信封包含用于在 SMTP 服务器之间传输和接收邮件的信息。 RFC 5321 中介绍了邮件信封。 收件人永远不会看到邮件信封，因为它是在邮件传输过程中生成的。
- 邮件内容包含邮件头字段（统称为邮件头）和邮件正文。 RFC 5322 中介绍了消息标头。
由于此设计，邮件具有多个发件人值：
- MAIL FROM 地址 (也称为
5321.MailFrom地址、P1 发件人或信封发件人) 是在 SMTP 电子邮件服务器之间传输邮件时使用的电子邮件地址。 此地址通常记录在邮件头 (的 “返回路径 ”标头字段中，尽管源电子邮件服务器可以指定不同的 “返回路径 ”电子邮件地址) 。 此电子邮件地址用于未送达报告（也称为 NDR 或退回邮件）。 - 发件人地址 (也称为
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) 的域名与 From 地址 (woodgrovebank.com) 的域名不匹配。 此邮件是欺骗的经典示例，其中意图可能会通过屏蔽邮件的真实来源来欺骗收件人，以用于网络钓鱼攻击。
显然，SMTP 电子邮件需要验证邮件发件人是他们声称是谁！
SPF、DKIM 和 DMARC 如何协同工作来对电子邮件发件人进行身份验证
Internet 域需要 SPF、DKIM 和 DMARC 协同工作，以便进行有效的电子邮件身份验证。
SPF：如 设置 SPF 以标识自定义云域的有效电子邮件源中所述，SPF 使用 DNS 中的 TXT 记录来：
- 标识来自 MAIL FROM 域的有效邮件源。
- 如果目标电子邮件服务器收到来自未定义来源的邮件，应如何处理（“硬失败”表示拒绝该邮件；“软失败”表示接受并标记该邮件）。
SPF 问题：
SPF 仅验证 MAIL FROM 域中发件人的源。 SPF 不会考虑 From 地址中的域，也不会考虑 MAIL FROM 域与 From 域之间的对齐：
- 攻击者可以通过以下步骤发送通过 SPF 身份验证 (假负) 的电子邮件：
- 注册一个域名（例如 proseware.com），并为该域名配置 SPF。
- 从注册域的有效来源发送电子邮件，但“发件人”电子邮件地址使用不同的域（例如，woodgrovebank.com）。
- 代表其他域发送邮件的合法电子邮件服务可能会控制 MAIL FROM 地址。 其他域和 MAIL FROM 域不匹配，因此邮件无法通过 SPF 身份验证 (误报) 。
- 攻击者可以通过以下步骤发送通过 SPF 身份验证 (假负) 的电子邮件：
邮件经过会重定向或中继邮件的服务器端电子邮件转发后，SPF 会失效。
- 基于服务器的电子邮件转发将邮件源从原始服务器更改为转发服务器。
- 转发服务器无权从原始 MAIL FROM 域发送邮件，因此邮件无法通过 SPF 身份验证 (误报) 。
每个域和任何子域都需要其自己的单个 SPF 记录。 子域不继承父域的 SPF 记录。 如果想要允许来自已定义和已使用子域的电子邮件，但阻止来自未定义和未使用的子域的电子邮件，则此行为将变得有问题。
DKIM：如 设置 DKIM 以从云域对邮件进行签名中所述，DKIM 使用域对邮件 (的重要元素（包括发件人地址) ）进行数字签名，并将签名存储在邮件头中。 目标服务器验证消息的已签名元素是否未更改。
DKIM 如何帮助 SPF：DKIM 可以验证 SPF 失败的消息。 例如：
- 来自电子邮件托管服务的邮件，这些邮件使用了与其他域邮件相同的 MAIL FROM 地址。
- 遇到基于服务器的电子邮件转发的邮件。
由于邮件标头中的 DKIM 签名在电子邮件转发期间不受影响或更改，或者当托管服务对多个域使用相同的 MAIL FROM 地址时，这些邮件能够传递 DKIM。
DKIM 问题：DKIM 用于对邮件进行签名的域不需要与电子邮件客户端中显示的“发件人”地址中的域匹配。
与 SPF 一样，攻击者可以按照以下步骤发送通过 DKIM 身份验证 (假负) 的电子邮件：
- 注册一个域名（例如 proseware.com），并为该域名配置 DKIM。
- 使用其他域中的发件人电子邮件地址发送电子邮件（例如，woodgrovebank.com）。
DMARC：如设置 DMARC 以验证云邮箱发件人的 From 地址域中所述，DMARC 使用 SPF 和 DKIM 检查，以便在 MAIL FROM 和 From 地址中的域之间进行对齐。 DMARC 还规定了接收方电子邮件系统应如何处理未通过 DMARC 验证的邮件，并指定将 DMARC 结果（包括通过和失败）发送到何处。
DMARC 如何帮助 SPF 和 DKIM：如前所述，SPF 不会尝试将 MAIL FROM 域与 From 地址中的域名进行匹配。 DKIM 不关心对消息进行签名的域是否与发件人地址中的域匹配。
DMARC 通过确认 MAIL FROM 和 From 地址中的域名是否匹配，来应对 SPF 和 DKIM 中缺乏域对齐检查机制的问题。
DMARC 问题：在投递前修改传输中邮件的合法服务会导致 SPF 和 DKIM 失效，进而导致 DMARC 检查失败。
当消息在域或组织之间自动转发时，即使对于合法的服务发件人，DMARC 对齐也可能失败。 例如，如果某个 Microsoft 服务域（如 voicemail.microsoft.com）在转发后未通过 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 简称的单个值中。
Authentication-Results 标头是一个消息标头字段，用于记录电子邮件身份验证检查的结果。
compauth 值会写入邮件标头中的 Authentication-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 域名具有 DKIM 记录，但没有 SPF 记录。 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 发送邮件时避免电子邮件身份验证失败
为域配置 SPF、DKIM 和 DMARC 记录：使用域注册机构或 DNS 托管服务提供的配置信息。 还有专用于帮助设置电子邮件身份验证记录的非Microsoft服务。
许多公司不发布 SPF 记录，因为他们不知道其域中邮件的所有电子邮件来源。
首先，发布一条 SPF 记录，其中包含你已知的所有电子邮件来源（尤其是企业邮件流量的来源），并使用“软失败”作为强制执行规则值 (
~all)。 例如：fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"如果创建此 SPF 记录，Microsoft 365 会将来自公司基础结构的入站电子邮件视为经过身份验证。 如果复合身份验证失败，来自未识别源的Email可能仍被标记为欺骗。 不过，与 Microsoft 365 将来自该域中所有发件人的电子邮件都标记为欺骗相比，这种行为仍然是一种改进。 通常，当 SPF 配置为软失败强制规则时，目标邮件系统会接受来自未识别来源、但发件人属于该域的邮件。
发现并添加更多可用于您的邮件的电子邮件来源。 例如：
- 本地电子邮件服务器。
- 通过软件即服务 (SaaS) 提供程序发送的电子邮件。
- 通过云托管服务（Microsoft Azure、GoDaddy、Rackspace、Amazon Web Services 等）发送的电子邮件。
在识别出您的域的所有电子邮件来源后，您可以更新 SPF 记录，将强制规则值设为“hard fail”(
-all)。设置 DKIM 以对消息进行数字签名。
设置 DMARC 以验证 MAIL FROM 和 From 地址中的域是否匹配，以指定如何处理未通过 DMARC 检查的邮件 (拒绝或隔离) ，并确定报告服务以监视 DMARC 结果。
如果使用批量发件人代表你发送电子邮件，请验证发件人地址中的域是否与通过 SPF 或 DMARC 的域匹配。
您托管某个域的电子邮件服务，或提供可发送电子邮件的托管基础设施：
- 确保客户有说明如何为其域配置 SPF 的文档。
- 请考虑对出站邮件进行 DKIM 签名，即使客户未在其域名中明确配置 DKIM，也可使用默认域名进行签名。 您甚至可以使用 DKIM 签名对电子邮件进行双重签名（使用贵公司域名，以及在可用时使用客户域名）。
即使你对源自平台的电子邮件进行身份验证，也无法保证发送到Microsoft。 但是，电子邮件身份验证可确保 Microsoft 不会仅仅因为邮件未经身份验证，就自动将来自您的客户域的电子邮件判定为垃圾邮件。