SPF、DKIM、DMARC.com

“发件人验证”过程使我们能够区分合法发件人与欺骗其身份的攻击者，并防止可能的欺骗邮件攻击。

在本文中，我们将详细回顾三种发件人验证标准 - SPF、DKIM、DMARC 以及两种可以在 Exchange 和基于 Exchange Online 的环境中实施的发件人验证方法。

五英雄的SPF、DKIM DMARC、Exchange和Exchange Online防护

SPF、DKIM 和 DMARC 是为了验证发件人身份而创建的公共邮件标准。

我们可以使用的其他选项：

1. 使用 Exchange 服务器规则来识别敌对分子使用组织身份攻击 Exchange 托管的组织用户的事件。
2. 使用网络钓鱼过滤器的 Exchange Online 保护选项。

SPF 标准如何保护我们免受欺骗电子邮件的侵害？

SPF 标准基于这样一个概念：我们通过验证有关“他的邮件服务器”的信息来得出有关发件人的结论。

如果我们想要准确的话，当使用 SPF 时，我们涉及到电子邮件地址的“右侧部分”，即域名。

代表发件人的邮件服务器应被视为特定域名（发件人的电子邮件地址中出现的域名）的“授权邮件服务器”。

目的邮件服务器（代表目标收件人的邮件服务器）实现的发件人验证过程是通过验证发件人邮件服务器的“完整性”来执行的。

代表“发件人”的邮件服务器应被视为特定域名的“授权邮件服务器”。

SPF记录（TXT记录）中发布的有关可以代表域发送电子邮件的授权邮件服务器的信息，其中包括被授权发送电子邮件的邮件服务器的IP地址或主机名列表代表域。

发件人身份“存储”

使用 SPF 时，检查的发件人身份是出现在邮件信封的 MAIL FROM 字段中的电子邮件地址。

SPF 发件人验证流程

SPF发件人验证协议使用以下机制来验证发件人的身份：

当电子邮件消息到达目标邮件服务器时，邮件服务器从邮件信封（MAIL FROM字段）中“获取”有关发件人电子邮件地址的信息。

目的邮件服务器与电子邮件地址的域名（电子邮件地址的右侧部分）相关。

在我们的具体示例中，发件人的域名是 o365info.com

邮件服务器对托管域名 o365info.com 的 DNS 服务器进行寻址，并查找有关托管在 下的 SPF 记录的信息o365info.com 域名。

SPF 记录实现为 TXT 记录，其中包括有关被授权代表 o365info.com 域发送电子邮件的邮件服务器的相关信息。

在我们的具体示例中，邮件服务器验证“源邮件服务器”（代表发件人的邮件服务器）的 IP 地址是否出现在 SPF 记录中。

• 情况1 - 如果源邮件服务器的IP地址出现在SPF记录中，则SPF验证测试结果为 - “通过”含义；发件人是合法发件人，因为他的邮件服务器被视为合法邮件服务器。
• 情况 2 - 如果源邮件服务器的 IP 地址没有出现在 SPF 记录中列出，则 SPF 验证测试结果为 - “失败”意义;发件人不是合法发件人，因为他的邮件服务器不是有效的邮件服务器。

防晒指数 |电子邮件被归类为欺骗电子邮件的场景

在下图中，我们可以看到针对欺骗邮件场景的 SPF 验证过程的逻辑：

如果代表发件人发送电子邮件的邮件服务器 IP 地址未出现在特定域的 SPF 记录中，则可得出该电子邮件是欺骗邮件（欺骗发件人）。

SPF标准的缺点

SPF 方法有一个明显的缺点，该缺点与 SPF 验证过程中验证的邮件字段有关。

• SPF 验证过程“获取”MAIL FROM 中邮件信封中显示的电子邮件地址
• SPF 验证过程不相关或检查发件人中邮件标头中显示的电子邮件地址

这种方法很容易被敌对分子利用，通过提供两个不同的身份来绕过SPF验证机制。

1. MAIL FROM 字段中的身份将是合法身份。
2. FROM 字段中的身份将是欺骗身份。

SPF 标准流程配置为仅验证 MAIL FROM 字段中存储的发件人信息。换句话说，SPF发件人验证过程不会涉及FROM字段中存储的发件人信息。这是一个固有的弱点，可以被敌对分子利用。如果您想了解有关此漏洞的更多信息，可以阅读以下文章：

• 敌对分子如何执行欺骗电子邮件攻击并绕过现有的 SPF 实施？ |简介 | 1#2
• 如何模拟欺骗电子邮件攻击并绕过SPF发件人验证？ | 2#2

DKIM 标准如何保护我们免受欺骗邮件的侵害？

用于验证邮件发件人身份合法性的DKIM方法是通过“授权实体”对发件人发送的电子邮件消息进行数字签名的方法来实现的。

基于现有PKI（公钥基础设施）的数字签名。

使用数字签名选项使“另一方”（在我们的场景中代表目标收件人的邮件服务器）能够确保由受信任的机构发送信息（电子邮件消息）。

因为电子邮件是由受信任的机构（邮件服务器，他们代表发件人）发送的，所以目标邮件服务器可以确定发件人是合法的发件人（发件人就是他所声称的人）。

对发件人电子邮件进行数字签名的“权威机构”通常是代表发件人传送电子邮件的邮件服务器。

在 DKIM 基础结构中，签署电子邮件消息的实体被描述为 DKIM 选择器。

由 DKIM 选择器签名的信息包括几个邮件字段。在我们的主题中，我们应该知道的主要事情是 - 包含发件人身份（发件人电子邮件地址）的名为 FROM 的邮件字段经过数字签名。

如果您想了解有关 DKIM 标准以及 DKIM 在基于 Office 365 的环境中实施的更多详细信息，您可以阅读系列文章 DKIM - 域密钥识别邮件 |基本介绍 |第 1#10 部分。

DKIM 发件人验证流程。

DKIM 发件人验证协议，使用以下机制来验证发件人的身份：

从源邮件服务器发送的电子邮件包括。

• 数据的数字签名，包括发件人的电子邮件地址。
• 有关签署电子邮件的邮件服务器的名称 (FQDN) 的信息，即 DKIM 选择器。

当电子邮件消息到达目标邮件服务器时，邮件服务器从邮件标头（FROM 字段）“获取”有关发件人电子邮件地址的信息。

为了能够获得有关对电子邮件消息进行数字签名的“权威”的信息，目标邮件服务器与电子邮件地址的域名（电子邮件地址的右侧部分）相关。

在我们的具体示例中，发件人的域名是 o365info.com

邮件服务器从邮件标头中“获取”签名电子邮件消息的 DKIM 选择器的主机名。

目标邮件服务器对托管特定域名的 DNS 服务器进行寻址，并查找托管在 o365info.com 域名“下”的 DKIM 记录信息。
DKIM 记录实现为 TXT 记录，其中包括有关 DKIM 选择器主机名的相关信息。

在 DKIM 场景中，邮件服务器将查找有关 DKIM 选择器的主机名的信息。

如果 DKIM 记录包含出现在电子邮件中的 DKIM 选择器的主机名，则邮件服务器“知道”他是授权机构，并且可以信任他。

现在，在目标邮件服务器上，进入下一阶段，在该阶段中，他需要验证电子邮件中出现的数字签名。

数字签名验证过程是由一个相当复杂的过程实现的。目的邮件服务器自己计算邮件字段（包括包含发件人E-mail地址的邮件字段FROM）的HASH值，并将得到的HASH值与该HASH值进行比较出现在电子邮件中。

• 情况1 - 如果HASH值相同，则意味着数据没有以任何方式改变，然后我们可以确定发送者是合法发送者。
• 情况 2 - 如果 HASH 值不相同，则意味着数据已被更改，因此，我们无法确定发送者是合法的发件人。

DKIM |电子邮件被归类为欺骗电子邮件的情况。

从 DKIM 流程的角度来看，验证测试包括两个必须成功完成的“测试”。

测试 1 - 如果电子邮件中出现的 DKIM 选择器未出现在发件人域名下托管的 DKIM 记录中，则验证过程会认为失败，即 E -mail 被视为欺骗邮件。

测试 2 - 如果数字签名的 HASH 值无效（不相同），验证过程将视为失败，这意味着电子邮件将被视为欺骗邮件。

Exchange 如何保护我们免受欺骗电子邮件的侵害？

让我们从一个声明开始——默认情况下； Exchange 未配置为“保护我们”免受欺骗邮件（欺骗发件人）的影响。

我们甚至可以说，Exchange 服务器对于欺骗电子邮件攻击或发件人的身份“漠不关心”。

尽管默认情况下 Exchange 服务器对发件人身份合法性“不关心”，但我们可以使用 Exchange 强大的选项来帮助我们识别合法发件人。在特定场景中，我们想要验证使用 Exchange 组织托管的域名（Exchange 认为具有权威的特定域名）的发件人的身份。

“交易所验证测试”是通过“两部分”组合来实现的：

• 保存在电子邮件标题中的信息。
• 交换规则。

使用 Exchange 规则，我们可以定义逻辑条件，这将使我们能够识别欺骗发件人（欺骗邮件）的情况。

当我们使用术语“欺骗邮件”时，其含义是特定场景 - 敌对分子使用“我们的用户身份”并尝试攻击我们组织用户之一的场景。

我们根据以下逻辑定义的交换规则条件-

每个使用我们组织身份（包含我们域名的电子邮件地址）的实体都应该是合法实体，由我们的 Exchange 服务器托管。

寻址 Exchange 服务器的每个合法实体都应提供用户凭据，以便 Exchange 服务器能够知道这是合法且受信任的实体。

例如，当我们打开 Outlook 并访问邮箱中存储的数据时，我们的用户凭据会在 Exchange 服务器的后台“传输”。

有关“实体”提供或未提供用户凭据这一事实的信息被注册为邮件标头的一部分。

• 如果实体提供用户凭据，则实体身份验证状态为 - 内部。
• 如果实体未提供用户凭据，则实体身份验证状态为 - 匿名。

我们可以使用的“技巧”是基于一个过程，在该过程中我们“获取”有关发件人身份验证状态的信息，即他们的电子邮件包含我们的域名。

例如，在我们的具体示例中，敌对分子使用电子邮件地址表示自己 - [email protected] （虚假身份）。

John 是“真正的”Exchange 收件人，拥有 Exchange 邮箱等。

Exchange 邮件服务器认为域名 -o365info.com 具有权威，并期望发件人提供用户凭据。这是合法收件人用来访问存储在 Exchange 邮箱中的私人数据的“正确”方式。

在我们的场景中，该元素是一个敌对元素，没有 John 的凭据（用户名 + 密码）。

因此，他的身份验证状态为“匿名”，但同时使用“约翰”的电子邮件地址。

这是我们表明这是一个欺骗发件人（欺骗邮件）这一事实的标志。

能够“告诉”Exchange服务器我们想要识别发件人身份验证状态为匿名且发件人电子邮件地址包含我们的域名的欺骗邮件事件；我们可以创建一个 Exchange 规则来监视此类事件，并在识别出此类事件时“执行某些操作”。

需要强调的是，此选项仅适用于使用 Exchange 邮件基础结构的组织，并且这不是正式或公共标准。相反，我们可以使用一种对我们有利的“噱头”作为欺骗邮件扣除机制，或者作为实施现有邮件发件人验证标准（例如 SPF）的附加层。

兑换规则|电子邮件被归类为欺骗电子邮件的场景

“欺骗邮件”事件将通过两个条件的组合来描述，这两个条件应该同时发生。

发件人需要使用包含组织域名的电子邮件地址，并被视为匿名发件人（未提供用户凭据的发件人）。

Exchange Online 如何保护我们免受欺骗电子邮件的侵害？

网络钓鱼过滤器（和网络钓鱼过滤器策略）功能是一项相对较新的功能，可供 Exchange Online 客户（即 Office 365 客户）使用。

“网络钓鱼过滤器”选项是一项 EOP（Exchange Online Protection）功能。在基于Office 365的环境中，EOP充当“邮件安全网关”。

网络钓鱼过滤器的目的是使 Office 365 客户能够检测欺骗邮件的典型场景，其中攻击者提供两种不同的身份 - 出现在 MAIL FROM 字段中的发件人身份（邮件信封）+ FROM 字段（邮件标头）中显示的发件人身份。

如果您想了解有关敌对分子使用的此方法的更多信息，为了绕过现有的发件人验证机制（例如 SPF），您可以阅读文章敌对分子如何执行欺骗电子邮件攻击并绕过现有的 SPF 实施？ |简介 | 1#2。

网络钓鱼过滤器基于非常简单的验证测试来检测欺骗邮件事件：

当发件人寻址 Exchange Online 邮件服务器（如果我们想要更准确，即 Exchange Online Protection），并使用两组发件人身份时，Exchange Online Phish Filter Policy 将验证 中的发件人信息是否有效。 MAIL FROM 字段与FROM 邮件字段中的发件人身份相同。

如果身份不同，则表明特定电子邮件消息出现“错误”。

Exchange 在线网络钓鱼过滤策略 |电子邮件被归类为欺骗电子邮件的场景

“欺骗邮件”事件将被描述为——MAIL FROM字段中拖欠的E-mail地址是“未对齐”含义的场景，与之前的E-mail地址不同。出现在 FROM 字段中。

在这种情况下，该电子邮件将被视为高风险电子邮件，并且将在原始电子邮件中添加警告通知。

DMARC 如何保护我们免受欺骗电子邮件的侵害？

DMARC 标准是一个特殊的标准，因为它不包含用于实现发件人验证的“独立机制”或协议，而是依赖于另一种发件人身份验证协议 - SPF 和 DKIM。

DMARC 标准有关发件人验证过程的“工作”是

1. 检查特定电子邮件是否已通过发件人验证标准之一（SPF 或 DKIM）验证。
2. 检查验证测试的结果是通过还是失败。
3. 实施称为对齐的附加发件人验证层。

如果我们使用其中一种发件人身份验证协议，DKIM 将“扩展”每个协议所实现的验证过程。

换句话说，与发件人验证标准（SPF 或 DKIM）相比，DMARC 正在执行更“严格的发件人验证测试”。

DMARC 用于描述发件人验证的“附加层”的技术术语，描述为 - 对齐。

例如，如果我们使用 SPF 或 DKIM，从 DMARC 的角度来看，SPF 或 DKIM 验证测试成功还不够，而且 DMARC “规定”附加条件，需要成功实施。

DMARC 标准和 SPF 一致性

在我们的邮件基础设施使用 SPF 标准来实现发件人验证的情况下，每封传入邮件都将被 SPF 验证测试“标记”为失败或通过。

注意： 实际上，SPF 标准包含额外的状态代码，但目前我们希望简化描述。因此，我们将仅将失败或通过状态代码关联起来。

当我们使用 DMARC 标准时，DMARC 将执行的第一个测试是 - 验证 SPF 状态是失败还是通过 。

如果 SPF 状态为通过，DMARC 将继续进行下一个测试，其中 DMARC 验证所需的“SPF 对齐”。 ”

SPF 对齐测试是通过检查 MAIL FROM 字段中显示的发件人电子邮件地址（邮件信封中显示的信息）是否与发送邮件的电子邮件地址相同来实现的。显示在 FROM 字段中（出现在邮件标头中的信息）。

案例 1 - DMARC SPF 对齐测试通过

在下图中，我们可以看到一个示例，其中电子邮件消息包含 2 个发件人身份。在我们的示例中，MAIL FROM 中显示的发件人身份与 FROM 字段中显示的发件人身份相同。

在这种情况下，SPF 对齐测试已成功完成，并且 DMARC 会在
电子邮件消息上标记状态代码 - dmarc=pass

案例 2 - DMARC SPF 对齐测试失败

在下图中，我们可以看到一个示例，其中电子邮件消息包含 2 个发件人身份。在我们的示例中，MAIL FROM 中显示的发件人身份与 FROM 字段中显示的发件人身份不同。

在这种情况下，SPF 对齐测试未成功完成，并且 DMARC 在
电子邮件上标记状态代码 - dmarc=fail

DMARC 标准和 DKIM 一致性

在我们的邮件基础设施使用 DKIM 标准来实施发件人验证的情况下，每封传入邮件都将被 DKIM 验证测试“标记”为失败或通过。

当我们使用 DMARC 标准时，DMARC 将执行的第一个测试是 - 验证 DKIM 状态是否为 - 失败 或 通过。

如果 DKIM 状态为通过，DMARC 将继续进行下一个测试，其中 DMARC 验证所需的“DKIM 对齐”。

DKIM 对齐测试是通过验证 DKIM 选择器 域名是否与 FROM 中显示的发件人域名相同来实现的。字段（保存在邮件标头中的信息）。

案例 1 - DMARC DKIM 对齐测试通过

在下图中，我们可以看到有关签署电子邮件的 DKIM 选择器名称的信息示例。有关 DKIM 选择器主机名的信息保存为电子邮件的一部分。

在我们的场景中，DKIM 选择器名称包含域名 - o365info.com

在FROM字段中，我们可以看到发件人电子邮件地址也使用了域名 - o365info.com

在这种情况下，DKIM 对齐测试已成功完成，并且 DMARC 会在
电子邮件消息上标记状态代码 - dmarc=pass

案例 2 - DMARC DKIM 对齐测试失败

在下图中，我们可以看到有关签署电子邮件的 DKIM 选择器名称的信息示例。有关 DKIM 选择器主机名的信息保存为电子邮件的一部分。

在我们的场景中，DKIM 选择器名称包括域名 - outlook.com

在FROM字段中，我们可以看到发件人电子邮件地址也使用了域名 - o365info.com

在这种情况下，DKIM 对齐测试未成功完成，因为 DKIM 选择器域名与发件人域名不相同。

DMARC 使用状态代码标记电子邮件消息 - dmarc=fail