Exchange 2016 中的 SenderID、SPF、DKIM 和 DMARC – 第一部分

SenderID 在 Exchange 中作为反垃圾邮件的手段已经使用了很长一段时间，据我记得这是在 Exchange 2010 中首次使用的。与 SenderID 相关的是 SPF（发件人策略框架）。 SPF 看起来类似于 SenderID 功能，但其检查电子邮件的方式有所不同。

两者都使用带有 TXT 记录的公共 DNS 记录，其中存储有关发送 SMTP 服务器的信息，并且接收 (Exchange) 服务器使用此信息来验证是否允许发送服务器代表发件人发送电子邮件。

DKIM（域密钥识别邮件）和 DMARC（基于域的消息身份验证、报告和一致性）在打击垃圾邮件方面越来越流行。就像 SenderID 和 SPF 一样，这些解决方案也使用公共 DNS 来获取附加信息，但由于使用了加密，大多数 Exchange 管理员对 DKIM 和 DMARC 的复杂性存在一些疑问。

在即将发布的博文中，我将讨论在我的实验室环境中实现的 SPF、DKIM 和 DMARC，如下所示：

有一个 Exchange 2016 CU2 邮箱服务器托管多个邮箱。该服务器可通过 webmail.exchangelabs.nl 和 autodiscover.exchangelabs.nl（相同的 IP 地址，位于 Kemp LM3600 负载平衡器后面）访问，并配置有 Digicert UC 证书。

除此之外，还有一个具有 FQDN smtphost.exchangelabs.nl 的 Exchange 2016 CU2 边缘传输服务器。除了常规的 A 和 MX 记录外，IP 地址也在反向 DNS 中配置。边缘传输服务器也位于 Kemp LM3600 负载平衡器后面，并且具有具有相同域名的 Digicert SSL 证书。邮箱服务器和边缘传输服务器之间配置了边缘同步，所有入站和出站邮件均由边缘传输服务器处理。

发件人 ID 和 SPF

对抗垃圾邮件的解决方案之一是在 Exchange Server 2010 及更高版本中使用 SenderID 筛选。 SenderID 过滤尝试确定是否确实允许发送 SMTP 服务器代表发件人及其 SMTP 域发送邮件。 SenderID 过滤使用公共 DNS 中的附加记录来实现此目的。在此 DNS 记录中，存储了允许哪些服务器代表 SMTP 域发送邮件的信息。相反，如果 SMTP 服务器代表 SMTP 域发送邮件，并且此信息未存储在 DNS 中，则它很可能是 SPAM（欺骗邮件）的来源。 DNS 中的该记录是 SPF 记录。

SPF 和 SenderID 不同。两者都使用 DNS 中的 SPF 记录验证用户的电子邮件地址，并且 SPF 和 SenderID 的记录相同。两者之间的区别在于它们在 SMTP 消息的哪一层进行验证。简而言之，SPF 验证 HELO 域命令，即电子邮件的信封。另一方面，SenderID 通常会检查邮件内的 Mail From 命令。但正因为如此，典型的管理员会对 SPF 和 SenderID 之间的差异感到困惑。它们都没有好坏之分，但说 SenderID 是新的 SPF 或 SPF 2.0 也是错误的，事实也并非如此。理由足以让人困惑……更令人困惑的是，有传言称 Microsoft 并未在 SenderID 上进行开发，而是完全支持 SPF...

这就是它的工作原理。用户向组织中的收件人发送消息 (1)，并且用户的 SMTP 服务器建立连接。发送 EHLO 和 MAIL FROM (2) 命令时，接收 Exchange 服务器将尝试联系 DNS 以获取 SPF 记录 (3) 并将 SPF 记录中找到的数据与发送服务器的名称和 IP 地址进行比较，以查看如果有匹配项 (4)。如果存在匹配（“通过”），则会向消息标头添加一个条目，但如果不存在匹配（“失败”），则有多个选项：

• 消息被拒绝，没有任何反应；
• 该邮件会标有一个附加邮件标头，表明 SenderID 失败，同时垃圾邮件置信度 (SCL) 会增加。当然，如果 SCL 低于阈值，则消息将被传递到邮箱 (5)。

因此，如果您已将 SPF 记录添加到公共 DNS，并且接收邮件服务器对此 SPF 记录执行检查，则需要进行一项额外测试才能成功传递邮件。

此 SPF 记录中有什么内容？对于我自己的环境，它包含以下值：

“v=spf1 a:smtphost.exchangelabs.nl ~all”

其中 smtphost.exchangelabs.nl 是我的发送 Exchange 2016 边缘传输服务器的 FQDN。如果我发送消息，它应始终源自此 FQDN。如果它来自其他邮件服务器，则该消息很可能不是我发送的！

由于我的 MX 记录与上面的 FQDN 相同，因此也可以将 MX 记录用于 SPF 目的，如下所示：

“v=spf1 mx ~all”

~ 符号表示接收邮件服务器应该接受该邮件，但对该邮件进行标记（即添加附加的邮件标头），这称为软失败。如果 ~ 符号替换为 - 符号，则表示硬失败。接收服务器很可能会退回任何不符合要求的邮件。 A ？也可以使用 符号，并且它是相当中性的，由接收 SMTP 服务器决定如何处理邮件。

还可以使用 SPF 记录中的 IP 地址或 IP 地址范围来确定您的邮件可能源自何处。在此示例中，176.62.196.240/28 范围内的所有服务器都可以代表我的姓名发送 SMTP 消息：

“v=spf1 ip4: 176.62.196.244/28 ~全部

有关如何构建正确的 SPF 记录的更多信息，您可以查看 http://www.openspf.org/SPF_Record_Syntax 上的发件人策略框架语法页面。

注意。 Microsoft 曾经有自己的用于创建 SPF 记录的向导，但该向导已经下线很久了。

当您构建了 SPF 记录并将其添加到公共 DNS 后，您就可以进行测试了。

您可以使用 Port25.com 网站提供的验证程序。要使用此功能，您可以发送电子邮件至 [email protected] 并等待结果。在返回的电子邮件正文中，您应该会找到类似以下内容的内容：

HELO 主机名：smtphost.exchangelabs.nl
源IP：176.62.196.244
邮件发件人：[email protected]
——————————————
SPF检查详情：
——————————————
结果：通过 ID 已验证：[email protected]
DNS 记录：
Exchangelabs.nl。 SPF（无记录）
Exchangelabs.nl。第 617 章 smtphost.exchangelabs.nl。 617 于 176.62.196.244

另一种基本检查是向另一个邮箱发送电子邮件，并在收到邮件后检查邮件标题。当我向我的家庭帐户发送电子邮件并检查邮件标题时，我可以在邮件标题中看到以下信息：

身份验证结果：hotmail.com; spf=pass （发件人 IP 为 176.62.196.244） [email protected]; dkim=无 header.d=Exchangelabs.nl;

此时，我们知道 SPF 工作正常，我们可以继续使用 DKIM。这是以下博客的主题。

接收电子邮件时，Exchange 2016 边缘传输服务器还会检查发送组织的 SPF 记录，如入站邮件标头中所示：

已接收 SPF：通过（smtphost.exchangelabs.nl：[email protected] 的域指定 145.128.1.35 作为允许的发件人）receiver=smtphost。交换实验室.nl；客户端IP=145.135.16.35;

概括

您可以使用 SPF 作为邮件服务器的验证机制，以便接收邮件的主机可以实际检查您的邮件服务器是否允许代表您公司的 SMTP 域发送邮件。对于只有几个出站 SMTP 服务器的直接环境，这不是问题。当您知道哪些服务器是出站 SMTP 服务器后，您可以将它们添加到 SPF 记录中，然后就可以开始了。

当您有多个电子邮件环境时，事情会变得更加复杂，所有电子邮件环境都代表您的域发送。或者，当您有第三方组织（例如营销组织或发送大量邮件的服务）时，这些服务器也必须添加到 SPF 记录中，以确保所有邮件均已送达按计划进行，并且不会被视为垃圾邮件或垃圾邮件。这是SPF最困难的部分，这不是一个技术问题，更多的是一个组织问题。

SPF 是通用解决方案，而不是特定于供应商的解决方案，因此您可以为 Exchange 环境实施 SPF，也可以为 Lotus Notes 或 Groupwise 环境，或者为 Office 365 或 Google Mail 等云解决方案实施 SPF。

SPF 只是验证电子邮件和对抗未经请求的电子邮件的第一步。在我的下一篇博客中，我将讨论 DKIM 作为附加步骤。

更多信息

• http://www.openspf.org/
• http://spfwizard.com/
• http://www.openspf.org/工具
• http://www.openspf.org/SPF_vs_Sender_ID