如何在 Office 365 (O365) Exchange Server 中设置 DMARC, DKIM, 和 SPF : 完整实现教程
Table of Contents
对任何使用 Office 365 Exchange Server 来发送电子邮件的公司来说，使用 DMARC, DKIM, 和 SPF 来防止邮件假冒和邮件钓鱼以及提高邮件抵达率，是至关重要的。
Office 365 已经成为事实上的生产力软件标准。百万计的公司每天使用 Office 365 来发送商务邮件。如果您的公司：
- 从 Office 365 (Exchange Online) 发送邮件；
- 使用 Office 365 初始域名或者您自己的域名来发送邮件；
- 使用本地的 Microsoft Exchange Server，云端的 Office 365 或者混合环境。
并且想要设置 DMARC, DKIM 和 SPF 来阻止邮件假冒和邮件钓鱼，请继续阅读本教程。
典型的 Office 365 邮件场景
在 Office 365 Exchange Server 中，一封邮件从互联网到邮箱（反之亦然）所经历的路径被称为邮件流。Office 365 为邮件如何投递到您公司的邮箱提供了极大的灵活性。
以下是 Office 365 支持的邮件流场景：
- 所有的邮箱都由 Office 365 托管，并且使用 Office 365 的反垃圾邮件和反恶意软件解决方案；
- 所有的邮箱都由 Office 365 托管，并且使用第三方的反垃圾邮件，反恶意软件，归档，以及审核解决方案；
- 邮箱位于自己的服务器上面；您想要使用 Office 365 的反垃圾邮件服务，并且通过 Office 365 发送邮件；
- 邮箱分布于自己的服务器和 Office 365 上面；想要使用自己的过滤和合规解决方案；所有的邮件，包括接收和发送，必须通过自己的服务器；
- 邮箱分布于自己的服务器和 Office 365 上面；想要使用一个第三方的垃圾邮件过滤方案；想通过 Office 365 发送邮件，这样可以保护自己的服务器 IP 不被列入黑名单；
- 所有的邮箱都由 Office 365 托管，同时有多功能打印机，扫描仪，或者传真机需要发送邮件；
- 所有的邮箱都自己托管，并且使用 Exchange Online Protection (EOP) 来保护电子邮件；
除非另外指出，本文描述的步骤适用于上面所有的场景。
MX 记录如何工作
MX 是 "mail exchanger" 的缩写。MX 记录是发布在域名上的一种 DNS 记录。MX 记录提供一个简单的方法使得邮件服务器知道将电子邮件发往何处。
当有人请求把邮件发送到 [email protected] 的时候，发送服务器需要：
- 查询 DNS 以获得 microsoft.com 上面的 MX 记录；
- 查询 MX 记录中的域名的 IP 地址；
- 把邮件发送到具有最高优先级的域名的 IP 地址。
举个例子，下面用来查询 microsoft.com 上面的 MX 记录的命令显示 microsoft.com 的邮件服务器是 microsoft-com.mail.protection.outlook.com:
nslookup -q=mx microsoft.com
Non-authoritative answer:
microsoft.com mail exchanger = 10 microsoft-com.mail.protection.outlook.com.假设 microsoft-com.mail.protection.outlook.com 的 IP 地址是 104.47.54.36，这意味着所有发送到 microsoft.com 的邮件，包括前面提到的发送到 [email protected] 的邮件，会被发送到位于 IP 地址 104.47.54.36 的服务器。
如上所述，您并不局限于仅仅在运行在组织域名上面的服务器接收邮件。您可以更新在您的域名上面的 MX 记录来在其他地方收取邮件。MX 记录让域名拥有者可以方便地在任何主机上接收发送到其域名的邮件。
Office 365 邮件流介绍
Office 365 使用域名，更准确地说，域名上面的 MX 记录来路由邮件。
在您用组织域名注册了 Office 365 帐号以后，比如说 company.com，系统会创建一个缺省的帐号，例如 [email protected]。尽管可以使用该帐号发送和接收邮件，您或许想切换到自己的域名，因为这样看起来更加专业。
在 Office 365 中，要使用自己的域名来接收邮件，更新 company.com 上面的 MX 记录使其指向 Office 365，如下所示：
Hostname: company-com.mail.protection.outlook.com
Priority: 0
TTL: 1 hourMX 记录如何影响垃圾邮件过滤
Office 365 推荐将组织域名上面的 MX 记录指向 Office 365。这样 Office 365 将能够检查邮件的发送者，发送服务器的 IP 地址，以及链接邮件服务器的行为，这些都有助于标记该邮件是合法邮件还是垃圾邮件。如果不把 MX 记录指向 Office 365 的话，一些有用的信息会丢失，这样 Office 365 的垃圾邮件过滤器效果会下降：一些合法的邮件会被标记为垃圾邮件，同时一些垃圾邮件会被标记为合法的邮件。
在 Office 365 中设置 SPF
要在 Office 365 中设置 SPF，您需要创建一条 SPF 记录，在该记录中指定所有合法发送邮件的主机，并将其发布在 DNS 中。
需要注意的是，SPF 记录中包含的 DNS 查询不能超过 10 次，否则 SPF 会返回 PermError。如果出现这样的情况的话，需要采取措施来修复。
什么是 SPF?
邮件验证的第一个重要协议是 Sender Policy Framework (SPF)，出现于 2002 年左右。SPF 使得只有经过授权的发送者可以代表域名发送邮件，同时阻拦其他的发送者代表域名发送邮件。SPF 让接收服务器可以检查声称来自某个特定域名的邮件是否发送自该域名的管理者指定的 IP 地址。
SPF 由 RFC 7208 定义，要了解更多信息可以参阅 www.open-spf.org。
SPF 如何工作
为了方便讨论，假定以下场景：
- 您的公司域名是 business.com；发往雇员和客户的邮件地址是
[email protected]; - 为您发送邮件的主机的 IP 地址是
192.168.0.1; - 某个攻击者使用位于 IP 地址
1.2.3.4的假冒服务器来发送假冒邮件。
当邮件发送服务连接到托管邮件接受者邮箱的服务器主机时：
- 邮件服务器从 envelope from address 提取域名，即
business.com； - 邮件服务器检查发起连接的主机 IP 地址是否在
business.com的 SPF 记录中。如果是，那么 SPF 检查通过，否则不通过。
举个例子，假设您的 SPF 记录是这样子：
v=spf1 ip4:192.168.0.1 -all这意味着仅有来自 IP 地址 192.168.0.1 的邮件可以通过 SPF 检查，与此同时，所有来自其他 IP 地址的邮件将会在 SPF 检查时失败。因此，位于 IP 地址 1.2.3.4 的服务器发送的所有的邮件都不能通过 SPF 检查。
可以把 SPF 记录看成是一个合法 IP 地址的列表，当且仅当邮件来自其中一个 IP 地址时，SPF 允许通过。其他任何主机无法代表您的域名发送邮件。SPF 检查结果会进一步被用来计算 DMARC 验证结果。
为 Office 365 创建 SPF 记录
根据实际的发送电子邮件的场景，创建对应的 SPF 记录。
场景 1：仅使用 Office 365 Exchange Online 来代表组织发送邮件。
在这个场景下，既然 Office 365 被允许发送邮件，只需要简单地添加它的 SPF 记录 (spf.protection.outlook.com) 到您的 SPF 记录中，像这样：
v=spf1 include:spf.protection.outlook.com –all场景 2：使用自托管的邮件服务器发送邮件；并且想用 Office 365 来为组织发送邮件。
在这个场景下，如果已经有了 SPF 记录，像 v=spf1 mx –all，只需要把 Office 365 的 SPF 记录添加进来，像这样：
v=spf1 mx include:spf.protection.outlook.com –all如果还没有 SPF 记录，那么使用场景 1 中的 SPF 记录就好。
场景 3：已经使用第三方邮件投递服务比如 SendGrid，并且想要 Office 365 来代表组织发送邮件。
假设现有的 SPF 记录是 v=spf1 include:sendgrid.net –all，那么把 Office 365 的 SPF 记录包含进来：
v=spf1 include:sendgrid.net include:spf.protection.outlook.com –all创建一条 SPF 记录的更好的办法是使用 DMARCLY 的在线 SPF 记录产生器。这将会避免很多因为手工创作产生的错误。
Office 365 让您可以调整垃圾邮件过滤器设置，使得 Office 365 Exchange Online 把 SPF 检查结果为 hardfail 的邮件标记为 spam。
要在 Exchange Online admin center 中作出这个调整，浏览至 protection > spam filter > advanced options，把开关 SPF record: hard fail 切换到 On，然后点击 Save。
另外，您也可以在 PowerShell 中运行以下的 cmdlet：
Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On发布 SPF 记录
一旦创建了 SPF 记录，您需要把它发布到 DNS 中去，这样接收邮件的服务器可以访问到它。发布 SPF 记录实际上是在域名上面创建一条 TXT 记录。
假定您使用 GoDaddy 作为 DNS 服务提供商。如果是其他 DNS 服务提供商的话，界面应该类似。
以下是操作步骤：
-
登录进 GoDaddy。选择域名，然后点击 DNS 按钮。
-
如果您从来没有在域名上面创建过 SPF 记录，点击 Records 区域的 Add 按钮。
- 否则已经有 SPF 记录，需要编辑它。要检查是否已经有 SPF 记录，尝试在域名上面查找是否有以
v=spf1开头的 TXT 记录。 -
在 Type 下拉框中选择 TXT。在 Host 域中输入 @，并在 TXT 值中输入该 SPF 记录。然后点击 Save 按钮。
现在已经发布了 SPF 记录。值得注意的是，可能需要等 1 小时才能从 DNS 中查询到该记录。
SPF DNS 查询限制
每当邮件到达接收主机时，该主机需要查询 DNS 来执行 SPF 检查。此时需要有对应的措施来防止这种查询变成 DoS 攻击。
SPF 规范规定每次 SPF 检查的 DNS 查询次数不能超过 10 次，其中包括 "include" mechanism 或者 "redirect" modifier 所引起的 DNS 查询。如果超过 10 次，SPF 将会返回 PermError。
include, a, mx, ptr, and exists mechanisms 还有 redirect modifier 被算入该查询限制。all, ip4, and ip6 mechanisms 并不查询 DNS，因此不被算入该查询限制。exp modifier 不算入该查询限制，因为它在 SPF 记录被估值之后才执行 DNS 查询。
参阅 SPF DNS Lookup Limit 以了解更多信息。
如果 SPF 记录超过了 10 次 DNS 查询限制怎么办？
如果 SPF 记录包含超过 10 次 DNS 查询，SPF 会返回一个 permanent error (永久错误) 显示 "too many DNS lookups"，即太多 DNS 查询。SPF 永久错误在 DMARC 中被解释为 fail。因此，当这种情况发生时，会对邮件抵达率有负面的影响。
您可以使用免费的 SPF 记录检查器来检查域名上面的 SPF 记录，确保它没有包含超过 10 次 DNS 查询。如果这个数字高于 10，您需要"压平"该 SPF 记录，这样邮件可以成功抵达收件箱。
手工压平 SPF 记录既乏味也容易出错，我们建议使用工具来自动化该过程。DMARCLY 有一个叫 Safe SPF 的功能可以解决这个问题，它可以完全自动化 SPF 记录压平的工作。
要了解更多的信息，请参阅：SPF PermError: Too Many DNS Lookups - When SPF Record Exceeds 10-DNS-Lookup Limit
在 Office 365 中设置 DKIM
在 Office 365 中设置 DKIM 意味着创建 2 个 DKIM 记录，将它们发布到 DNS 中，并且在 Exchange 管理中心激活 DKIM。
在 Office 365 中创建 DKIM 记录
要在 Office 365 中设置 DKIM，首先需要在每个域名上面创建 2 个 CNAME 类型的 DKIM 记录。这些记录类似下面所示：
Host name: selector1._domainkey.CompanyDomainName
Points to: selector1-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.com
Host name: selector2._domainkey.CompanyDomainName
Points to: selector2-CompanyDomainName-com._domainkey.TenantName.onmicrosoft.com例如，如果域名是 company.com，并且您使用 company 注册 Office 365，那么需要创建这 2 个 DKIM 记录：
Host name: selector1._domainkey.company.com
Points to: selector1-company-com._domainkey.company.onmicrosoft.com
Host name: selector2._domainkey.company.com
Points to: selector2-company-com._domainkey.company.onmicrosoft.com注意到在上面的 Points to 的值中，CompanyDomainName 应该匹配 Office 365 产生的 MX 记录的域名部分。在这个情况里，company-com 在 Points to 值里应该匹配 company-com.mail.protection.outlook.com 中的 company-com。
在发布了这些记录后，等待 10 分钟左右来让记录生效。
在 Office 365 中激活 DKIM 签名
接下来您需要在 Office 365 中激活 DKIM 签名。登录至 Exchange 管理中心，然后浏览至 protection > dkim，选择需要激活 DKIM 的域名，然后点击 Enable。
值得注意的是，如果发布在 DNS 中的 DKIM 记录尚未生效，上面的操作会失败。当这种情况发生时，可以稍后重试。如果持续看到这个错误，检查是否已经正确地发布了 DKIM 记录。
在 Office 365 中设置 DMARC
在 Office 365 中设置 DMARC 需要创建一个 DMARC 记录，在 DNS 中发布该记录，接收并且分析 DMARC 报告，并采取适当的行动。
创建一个 DMARC 记录
要实现 DMARC 的话，首先需要创建一个 DMARC 记录。
先确定发送邮件的域名。比如，如果使用 [email protected] 发送销售邮件的话，域名就是 mycompany.com。
然后登录到 DMARCLY 控制面板，浏览至 DNS Records -> Publish DMARC Record。系统已经创建了一个缺省的 DMARC 记录，如下所示：
您可以在页面的下部调整 DMARC 记录的设置。最重要的设置是 DMARC 策略，决定了接收服务器应该如何处理 DMARC 检查失败的邮件。
在这里我们把策略设置成缺省的 None (p=none)，这将把 DMARC 设置成监测模式，这样可以检查邮件的 DMARC 验证的成功/失败的百分比。
在监测模式下面，接收服务器不会隔离或者拒绝验证失败的邮件，从收件人的角度来看，跟以前完全一样。监测模式带来一个好处：您会收到 DMARC aggregate reports，并且可以从中发现邮件送达异常情况。
如果刚开始使用 DMARC，可以简单地跳过这些设置。您可以以后再回来调整这些设置。
External destination verification
当使用 rua 标签把 DMARC 记录发布为：
v=DMARC1; p=none; rua=mailto:[email protected];您请求邮件服务器发送聚合报告到指定的邮件地址 [email protected]。然而，[email protected] 的所有者必须先授权。否则，这些报告不会发送到指定的邮件地址。这个机制叫 external destination verification (EDV)。
External destination verification 工作过程如下所示：
-
为了激活 EDV，
reporting.com的所有者发布一个 EDV 记录在：example.com._report._dmarc.reporting.com上面，值是
v=DMARC1。 - 在邮箱服务提供商发送聚合报告到
[email protected]之前，它会检查reporting.com是否已经允许接收example.com上面的报告。如果在 DNS 中位于example.com._report._dmarc.reporting.com存在记录，并且它的值是v=DMARC1，报告将被发送，否则不会被发送。
上面的 EDV 记录是基于单个域名的，也就是说，它仅允许关于 example.com 的报告发送到 [email protected]。如果需要允许关于 anotherexample.com 的报告发送到 [email protected]，需要为 anotherexample.com 发布一个 EDV 记录。
如果要允许关于任何域名的报告发往 [email protected]，发布一条通配的 EDV 记录如下：
*._report._dmarc.reporting.com如果使用 DMARCLY 来处理 DMARC 报告，无需设置 EDV - DMARCLY 已经为您处理好了。
发布 DMARC 记录
为了让 DMARC 记录发挥效用，必须把它发布到 DNS 中。
为什么要把 DMARC 记录发布到 DNS 中：当邮件抵达接收服务器时，服务器从邮件地址中提取域名，并且尝试从域名的 DNS 数据中查找 DMARC 记录。如果找到，它将执行在 DMARC 记录中指定的行动。
现在登录到 DNS 管理后台，选择需要发布 DMARC 记录的域名，比如 mycompany.com。
用下面的设置，在 mycompany.com 上面创建一个 TXT 记录：
Type: TXT
Host: _dmarc
TXT Value: (DMARC record created above)
TTL: 1 hour比如，下面是一个发布的记录：
在 CloudFlare 中发布一个 DMARC 记录：
这样就完成了。该域名上面的 DMARC aggregate reports 在一两天内会到达指定的邮箱。
如果需要监测多个域名，为每一个域名重复以上步骤。
DMARC 报告
DMARC 可以发送 2 种类型的报告：aggregate reports 和 forensic reports。
DMARC aggregate reports 提供关于 SPF/DKIM/DMARC 检查成功/失败的百分比信息。
尽管这些报告并不包含很多单封邮件的信息，aggregate reports 能够提供关于邮件设施的健康信息，并且定位潜在的邮件验证问题和恶意活动。
可以使用 DMARC 记录中的 rua 标签来指定 aggregate reports 的接收人。
例如，下面的 rua 标签请求 ESP 把 aggregate reports 发送到 [email protected]：
rua=mailto:[email protected]与此对比，DMARC forensic reports 是在邮件验证失败后，由邮件服务器发送的。Forensic reports 包含消息头域，包括源 IP 地址，验证结果，To 和 From 邮件地址，还有消息体。
可以使用 DMARC 记录中的 ruf 标签来指定 forensic reports 的接收人。
比如，下面的 ruf 标签请求 ESP 把 forensic reports 发送到 [email protected]：
ruf=mailto:[email protected]DMARC 报告工作流
要完整地实现 DMARC，首先要设置 DMARC 监测。
要设置 DMARC 监测，需要：
- 设置邮箱来接收 aggregate reports 和 forensic reports；
- 发布 DMARC 记录；
- 将 DMARC 报告解释为数据；
- 将数据渲染成图表。
这看起来工作量不小，特别是考虑到其中一些工作需要每天重复。有些 DMARC 分析工具可以将这些步骤自动化，比如，DMARCLY 可以自动完成所有这些工作。
分析 aggregate reports
DMARC aggregate reports 用 XML 格式编码，这种编码对机器很容易，但是对人来说，很难阅读和理解。
下面是一个 aggregate report 例子：
手工分析这样的数据极易出错，特别是如果每天都要做的话。因此使用一个 DMARC 分析工具来完成这种工作是一个明智的选择。下面是 DMARCLY 将数据可视化以后的样子：
更新邮件流
分析 DMARC 报告的主要目的是定位那些合法但是未能通过验证检查的邮件源。
下面是一个未对齐的邮件源的列表：
在发现了这些合法但是未能通过验证检查的邮件源后，更新 SPF/DKIM 设置以使得来自这些邮件源的邮件下次能够通过验证。
例如，如果使用 Mailchimp 来发送邮件，但是它被列为一个未对齐的邮件源，那么 Mailchimp 就是一个合法但是未能通过验证检查的邮件源。现在需要修正 Mailchimp 邮件流，换句话说，为 Mailchimp 设置 SPF 和 DKIM。
在不同的邮件投递服务中设置 SPF 和 DKIM的流程非常类似。下面是一个在 Mailchimp 上面设置 SPF 和 DKIM 的教程
如果使用其他的邮件投递服务，请尝试阅读他们的文档。
另外，如果有通过验证，但是不应该为您的组织发送邮件的主机，请将其从 SPF 和 DKIM 设置中移除。
Protect Business Email & Improve Email Deliverability
Get a 14 day trial. No credit card required.
Create Account