使用 DMARC 验证电子邮件

项目
06/16/2023
适用于:

✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 plan 1 and plan 2, ✅ Microsoft Defender XDR

提示

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

基于域的邮件身份验证、报告和一致性 (DMARC) 与发件人策略框架 (SPF) 和域密钥识别邮件 (DKIM) 结合使用，以对邮件发件人进行身份验证。

DMARC 确保目标电子邮件系统信任从你的域发送的邮件。将 DMARC 与 SPF 和 DKIM 配合使用可为组织提供更多保护，防止欺骗和网络钓鱼电子邮件。 DMARC 可帮助接收邮件系统决定如何处理来自你的域中未通过 SPF 或 DKIM 检查的邮件。

提示

请访问 Microsoft 智能安全协会 (MISA) 目录，查看哪些第三方供应商提供 Microsoft 365 的 DMARC 报告。

提示

你看过我们的分步指南吗？ 配置 1-2-3，没有褶皱，管理员在匆忙。有关启用 Microsoft Online Email路由地址的 DMARC 报告的步骤 (MOERA) 和已寄存的域，请访问。

SPF 和 DMARC 如何协同工作来保护 Microsoft 365 中的电子邮件？

电子邮件可能包含多个发送者或发件人地址。这些地址用于不同用途。例如，以下列地址为例：

“邮件发件人”地址：标识发件人，并指定在传送邮件过程中出现问题时发送返回通知的地址（例如未送达通知）。 邮件发件人地址 显示在电子邮件的信封部分，而不会由电子邮件应用程序显示，有时称为 5321.MailFrom 地址 或 反向路径地址。
“发件人”地址：由邮件应用程序显示为发件人地址的地址。 发件人地址 标识电子邮件的作者。即，负责撰写邮件的个人或系统的邮箱。 发件人地址 有时被称为 5322.From 地址。

SPF 使用 DNS TXT 记录列出给定域的授权发送 IP 地址。通常情况下，仅会针对 5321.MailFrom 地址执行 SPF 检查。单独使用 SPF 时，5322.From 地址不会进行身份验证，这将允许用户获取通过 SPF 检查但具有欺骗性 5322.From 发件人地址的邮件。以下面的 SMTP 脚本为例：

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.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 User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

在此脚本中，发件人地址如下所示：

发件人地址 (5321.MailFrom) ： phish@phishing.contoso.com
发件人地址 (5322.From) ： security@woodgrovebank.com

如果配置了 SPF，则接收服务器对邮件发件人地址 phish@phishing.contoso.com执行检查。如果该邮件来自 phishing.contoso.com 域的有效源，则会通过 SPF 检查。由于电子邮件客户端仅显示发件人地址，因此用户会看到此邮件来自 security@woodgrovebank.com。单独使用 SPF，永远不会验证 woodgrovebank.com 的有效性。

使用 DMARC 时，接收服务器还会针对发件人地址执行检查。在上面的示例中，如果存在用于 woodgrovebank.com 的 DMARC TXT 记录，则针对发件人地址的检查将失败。

什么是 DMARC TXT 记录？

像 SPF 的 DNS 记录一样，DMARC 的记录是一个 DNS 文本 (TXT) 记录，有助于防止欺骗和钓鱼。在 DNS 中发布 DMARC TXT 记录。 DMARC TXT 记录根据发送域的可疑所有者来验证电子邮件作者的 IP 地址，从而验证电子邮件的来源。 DMARC TXT 记录可以标识得到授权的出站电子邮件服务器。然后，目标电子邮件系统可以验证接收的邮件是否来自得到授权的出站电子邮件服务器。

Microsoft 的 DMARC TXT 记录如下所示：

_dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"

如需查看更多可提供 Microsoft 365 的 DMARC 报告的第三方供应商，请访问 MISA 名录。

为入站邮件设置 DMARC

你不必为在 Microsoft 365 中收到的邮件设置 DMARC。这一切都会得到妥善处理。如果想了解未通过我们的 DMARC 检查时如何处理邮件，请参阅 Microsoft 365 如何处理未通过 DMARC 检查的入站电子邮件。

从 Microsoft 365 中为出站邮件设置 DMARC

如果使用 Microsoft 365 但未使用自定义域（使用 onmicrosoft.com），则已为你设置 SPF，并且 Microsoft 365 会自动为传出邮件生成 DKIM 签名（有关此签名的详细信息，请参阅 DKIM 和 Microsoft 365 的默认行为）。若要为组织设置 DMARC，需要形成 onmicrosoft.com 域的 DMARC TXT 记录，并通过Office 365 Admin中心>设置>域>单击 onmicrosoft.com 域>添加记录将其发布到 DNS。

如果你有自定义域或正在使用本地 Exchange 服务器以及 Microsoft 365，则需要为出站邮件手动设置 DMARC。为自定义域设置 DMARC 包括以下步骤：

步骤 1：为域标识邮件的有效源
步骤 2：为域设置 SPF
步骤3：为自定义域设置 DKIM
步骤 4：为域生成 DMARC TXT 记录

步骤 1：为域标识邮件的有效源

如果已设置 SPF，则已完成本练习。 DMARC 有一些进一步的注意事项。标识域的邮件源时，请回答以下两个问题：

哪些 IP 地址从我的域发送邮件？
对于第三方代表我发送的邮件，5321.MailFrom 和 5322.From 域会匹配吗？

步骤 2：为域设置 SPF

既然你拥有了所有的有效发件人的列表，你可以按照步骤设置 SPF 以防止欺骗。

例如，假定 contoso.com 从 Exchange Online 中发送邮件，本地 Exchange 服务器的 IP 地址是 192.168.0.1，并且 Web 应用程序的 IP 地址是 192.168.100.100，则 SPF TXT 记录将如下所示：

contoso.com  IN  TXT  " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"

作为最佳做法，请确保 SPF TXT 记录考虑第三方发件人。

步骤 3：为自定义域设置 DKIM

设置 SPF 后，需要设置 DKIM。你可以使用 DKIM 将数字签名添加到电子邮件的邮件头中。如果未设置 DKIM，而是允许 Microsoft 365 为域使用默认 DKIM 配置，则 DMARC 可能会失败。失败的原因可能是默认 DKIM 配置使用原始 onmicrosoft.com 域作为 5321.MailFrom 地址，而不是你的自定义域。这将导致从域发送的所有电子邮件中的 5321.MailFrom 和 5322.From 地址 之间不匹配。

如果你有代表你发送邮件的第三方发件人，并且他们发送的邮件的 5321.MailFrom 和 5322.From 地址不匹配，则该电子邮件将无法通过 DMARC。若要避免此问题，你需要专门为具有该第三方发件人的域设置 DKIM。这允许 Microsoft 365 对来自此第三方服务的电子邮件进行身份验证。但是，它也允许其他方（例如，Yahoo、Gmail 和 Comcast）验证通过该第三方发送给他们的电子邮件，就好像电子邮件是由你发送的一样。这是有益的，因为它允许你的客户与你的域建立信任，无论邮箱位于何处，同时 Microsoft 365 不会因为欺骗而将邮件标记为垃圾邮件，因为它通过域的身份验证检查。

有关为域设置 DKIM 的说明，包括如何为第三方发件人设置 DKIM，以便他们可以欺骗你的域，请参阅使用 DKIM 验证从自定义域发送的出站电子邮件。

步骤 4：为域生成 DMARC TXT 记录

虽然此处未提及其他语法选项，但这些是用于 Microsoft 365 的最常用选项。在 Office 365 中为域生成 DMARC TXT 记录，格式如下：

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=policy; pct=100"

其中：

域是你想要保护的域。默认情况下，该记录可保护从该域和所有子域发送的邮件。例如，如果指定 _dmarc.contoso.com，那么 DMARC 会保护从该域和所有子域（例如 housewares.contoso.com 或 plumbing.contoso.com）发送的邮件。
TTL 应始终相当于一小时。用于 TTL 的单位可以为小时（1 小时）、分钟（60 分钟）或秒（3600 秒），具体取决于你的域的注册机构。
pct=100 表示此规则应该用于所有的电子邮件。
策略指定 DMARC 失败时你希望接收服务器遵循的策略。你可以将策略设置为无、隔离或拒绝。

有关要使用的选项的信息，请熟悉在 Microsoft 365 中实现 DMARC 的最佳做法中的概念。

示例：

策略设置为无

_dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"

策略设置为隔离

_dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"

策略设置为拒绝

_dmarc.contoso.com  3600 IN  TXT  "v=DMARC1; p=reject"

创建记录后，需要在域注册机构更新记录。

DMARC 邮件

警告

邮件可能不会每天发送。

在此示例 DMARC TXT 记录中， dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1"可以看到 rua 地址。此地址用于发送用于分析的“聚合反馈”，用于生成报告。

提示

访问 MISA 目录，查看更多可提供 Microsoft 365 的 DMARC 报告的第三方供应商。有关 DMARC ‘rua’ 地址的详细信息，请参阅 IETF.org 的‘基于域的邮件身份验证、报告和一致性 (DMARC)’。

在 Microsoft 365 中实现 DMARC 的最佳做法

你可以逐渐实现 DMARC，而不会影响邮件流的其余部分。创建并实施遵循这些步骤的推出计划。首先使用任一子域执行以下每一个步骤，然后使用其他子域，最后使用组织内的顶级域，然后再继续下一步骤。

监视实现 DMARC 的影响

从请求 DMARC 接收器向你发送关于使用该域时看到的消息的统计信息的子域或域的简单的监视模式记录开始。监视模式记录是将策略设置为无 (p=none) 的 DMARC TXT 记录。许多公司发布带有 p=none 的 DMARC TXT 记录，因为他们不确定发布限制性更强的 DMARC 策略可能会丢失多少封电子邮件。

即使在邮件传递基础结构中实现 SPF 或 DKIM 之前，你也可以这样做。但是，你将无法使用 DMARC 有效地隔离或拒绝邮件，直到你也实现了 SPF 和 DKIM 之后才可以。在引入 SPF 和 DKIM 时，通过 DMARC 生成的报表将提供通过这些检查的邮件数量和源，而且与未通过检查的邮件数和源进行对比。你可以轻松地查看这些邮件占用了多少合法通信量，并解决所有问题。你还将开始看到正在发送的欺诈邮件的数量以及发送地址。
请求外部邮件系统隔离未通过 DMARC 的邮件

当你相信全部或大部分合法通信受 SPF 和 DKIM 保护，并且了解实现 DMARC 的影响时，你可以实施隔离策略。隔离策略是策略设置为隔离 (p=quarantine) 的 DMARC TXT 记录。通过执行此操作，你要求 DMARC 接收器将来自你的域的未通过 DMARC 的邮件放入相当于垃圾邮件文件夹的本地文件夹中，而不是客户的收件箱中。
请求外部邮件系统不接受未通过 DMARC 的邮件

最后一步是实施拒绝策略。拒绝策略是策略设置为拒绝 (p=reject) 的 DMARC TXT 记录。执行此操作时，你将要求 DMARC 接收器不接受未通过 DMARC 检查的邮件。
如何设置子域的 DMARC？

DMARC 通过将策略发布为 DNS 中的 TXT 记录来实现，并且是分层 (例如，为 contoso.com 发布的策略将应用于 sub.domain.contoso.com，除非为子域) 显式定义了不同的策略。此功能很有用，因为组织可以指定较少数量的高级 DMARC 记录以扩大覆盖面。如果不想让子域继承顶级域的 DMARC 记录，应注意配置明确的子域 DMARC 记录。

此外，当子域不应该发送电子邮件时，还可通过添加 sp=reject 值来添加 DMARC 的通配符类型策略。例如：
```
_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
```

DMARC 拒绝

DMARC p=reject 是域所有者在 DMARC TXT 记录中设置的策略，用于通知服务提供商拒绝 DMARC 失败的电子邮件。

这是因为当 OReject 设置为默认值时，拒绝的电子邮件被发送到企业中的隔离区，并发送到使用者 (中的垃圾邮件Email文件夹，因为消费者) 中缺少隔离。但是，使用 DMARC p=reject时，电子邮件将被拒绝。

配置可以在 Microsoft Defender 门户中完成，也可以由 PowerShell Exchange Online 中的 New-AntiPhishPolicy 或 Set-AntiPhishPolicy cmdlet 完成。有关详细信息，请参阅以下文章：

Microsoft 365 如何处理未通过 DMARC 的出站电子邮件

如果邮件是从 Microsoft 365 出站的而且未通过 DMARC，并且你已将策略设置为 p=quarantine 或 p=reject，则该邮件通过出站邮件的高风险传递池进行路由。出站电子邮件不存在任何替代方法。

如果你发布 DMARC 拒绝策略 (p=reject)，则 Microsoft 365 中的任何其他客户都无法欺骗你的域，因为通过服务中继出站邮件时邮件将无法通过你的域的 SPF 或 DKIM。不过，如果你发布 DMARC 拒绝策略，但未通过 Microsoft 365 对所有电子邮件进行身份验证，部分邮件可能会被标记为入站电子邮件的垃圾邮件（如上所述），或者如果你不发布 SPF 且尝试通过服务将其中继到出站，邮件将被拒绝。例如，当你生成 DMARC TXT 记录时，如果你忘记包括代表你的域发送邮件的服务器和应用的某些 IP 地址，就会出现这种情况。

Microsoft 365 如何处理未通过 DMARC 的入站电子邮件

如果发送域的 DMARC 策略为 p=reject，则默认情况下，Exchange Online Protection (EOP) 拒绝消息。可以在发件人 DMARC 策略中配置反钓鱼策略以遵守或不遵循 p=quarantine 和 p=reject ，并为 p=quarantine 和 p=reject指定单独的操作。有关详细信息，请参阅欺骗保护和发件人 DMARC 策略。

当反钓鱼策略配置为不遵循 p=quarantine 或 p=reject DMARC 策略时，DMARC 失败的邮件将标记为垃圾邮件，并且不会被拒绝。用户仍可以通过以下方法在收件箱中获取这些邮件：

用户使用其电子邮件客户端分别添加安全发件人。
管理员可以使用欺骗智能保护或租户允许/阻止列表来允许来自欺骗性发件人的邮件。
管理员创建一个适用于所有用户的 Exchange 邮件流规则（也称为传输规则），该规则允许那些特定发件人的邮件。
管理员为不符合组织的 DMARC 策略的被拒绝电子邮件的所有用户创建 Exchange 邮件流规则。

有关详细信息，请参阅创建安全发件人列表。

Microsoft 365 如何使用经过身份验证的接收链 (ARC)

Microsoft 365 中的所有托管邮箱都将获得 ARC 的优势，实现改进的邮件可传递性和增强的反欺骗保护。当电子邮件从始发服务器路由到收件人邮箱时，ARC 将保留来自所有参与中介或跃点的电子邮件身份验证结果。在采用 ARC 之前，电子邮件路由中的中介执行的修改（如转发规则或自动签名）可能会在电子邮件到达收件人邮箱时导致 DMARC 故障。有了 ARC 之后，身份验证结果的加密保留使得 Microsoft 365 能够验证电子邮件发件人的真伪。

目前，当 Microsoft 是 ARC 保护方时，Microsoft 365 会利用 ARC 来验证身份验证结果，但计划在将来添加对第三方 ARC 保护方的支持。

DMARC 实现疑难解答

如果已配置了域的 MX 记录，其中 EOP 不是第一项，将不会为你的域强制执行 DMARC 失败。

如果你是客户，并且你的域的主 MX 记录不指向 EOP，你将不会获得 DMARC 的好处。例如，如果你将 MX 记录指向你的本地邮件服务器，然后使用连接器将电子邮件路由到 EOP，则 DMARC 将不起作用。在这种情况下，接收域是你的被接受域之一，但 EOP 不是主 MX。例如，假设 contoso.com 本身指向其 MX 并将 EOP 用作辅助 MX 记录，contoso.com 的 MX 记录将如下所示：

contoso.com     3600   IN  MX  0  mail.contoso.com
contoso.com     3600   IN  MX  10 contoso-com.mail.protection.outlook.com

由于它是主 MX，全部或大部分电子邮件将首先被路由到 mail.contoso.com，然后将邮件路由到 EOP。在某些情况下，你甚至不可能将 EOP 列为 MX 记录，并直接挂接连接器来路由你的电子邮件。 EOP 不必是第一个条目以进行 DMARC 验证。它只是确保验证，以确定所有本地/非 O365 服务器都将执行 DMARC 检查。设置 DMARC TXT 记录时，DMARC 有资格强制用于客户的域（而不是服务器），但是实际是否进行强制执行是由接收服务器决定的。如果将 EOP 设置为接收服务器，那么 EOP 强制执行 DMARC。