专家专栏 | 基于DNS验证的三种主流协议，如何确保电邮通信安全？

有多种协议可用于保护电子邮件安全，主流的包括SPF、DKIM 和 DMARC 协议，这三种协议通过保护发件人（电子邮件地址/域名）、发送主机（邮件系统）以及电子邮件消息的真实性来防范网络钓鱼、垃圾邮件、病毒和其他恶意软件。启用这些协议需要修改邮件服务器处理消息的方式(即邮件服务器或服务商需配置或提供相关功能)，并向域名的DNS系统中添加相关的解析记录。

这三种协议通常是一起使用的，但也可以在没有 DMARC 的情况下使用 SPF 或 DKIM中的任一个。

当前 Email 通信，仍在使用 SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）协议，正如协议的名字所暗示的，SMTP 实际上是一个非常简单（甚至简陋）的传输协议，本身并没有很好的安全措施。根据 SMTP 的规则，发件人的邮箱地址是可以由发信方任意声明的。在 SMTP 协议制定的时候也许还好，但在垃圾和诈骗邮件横行的今天，这显然是极不安全的。SPF 出现的目的，就是为了防止随意伪造发件人。

SPF（Sender Policy Framework，发送者策略框架）使得 MX（邮件交换）网关能够拒绝来自未经授权服务器的电子邮件消息。通过 DNS 发布有效发送地址的列表。列出的地址通常是终端用户用于其出站消息的SMTP网关，但也可能包括为组织发送营销邮件的外部服务提供商的地址。接收系统可以对照已发布的列表检查入站消息，并拒绝任何来自未列出服务器的消息。

SPF 记录实际上是DNS服务器的一个特殊格式的 TXT 记录，验证原理如下所述：

假设邮件服务器收到了一封邮件，来自主机的 IP 是101.226.139.1，并且声称发件人为email@example.cn。为了确认发件人不是伪造的，邮件服务器会去查询example.cn的 SPF 记录。如果该域的 SPF 记录设置允许 IP 为101.226.139.1的主机发送邮件，则服务器就认为这封邮件是合法的；如果不允许，则通常会退信，或将其标记为垃圾/仿冒邮件。

仿冒者虽然可以“声称”他的邮件来自example.cn，但是却无权操作example.cn的 DNS 记录；同时他也无法伪造自己的 IP 地址。因此 SPF 是很有效的，当前基本上所有的邮件服务提供商（例如 Gmail、QQ 邮箱等）都会验证它。

SPF记录的格式是在 DNS 中以 TXT 类型的资源记录形式存在的，一条基本的SPF记录通常包含以下几个部分：

关于v=spf1，这是必须的，这个表示采用 SPF 1 版本，现在SPF的最新版本就是第 1 版。

一条 SPF 记录定义了一个或者多个 mechanism，而 mechanism 则定义了哪些 IP 是允许的，哪些 IP 是拒绝的。mechanism 包括以下几类：

每个 mechanism 可以有四种前缀：

验证时，将从前往后依次验证每个 mechanism。如果一个 mechanism 包含了要查询的 IP 地址（称为命中），则验证结果由相应 mechanism 的前缀决定。默认的前缀为+。如果验证完所有的 mechanisms 也没有命中，则结果为 Neutral。

除了以上四种情况，还有 None（无结果）、PermError（永久错误）和 TempError（临时错误）三种其他情况。对于这些情况的解释和服务器通常的处理办法如下：

注意，上面所说的服务器处理办法仅仅是 SPF 标准做出的建议，并非所有的邮件服务器都严格遵循这套规定。

各类型 mechanism 说明如下：

会命中相应域名的 a 记录（或 mx 记录）中包含的 IP 地址（或地址段）。如果没有提供域名，则使用当前域名。例如：

例如，这是一个比较常见的 SPF 记录，它表示支持当前域名的 a 记录和 mx 记录，同时支持一个给定的 IP 地址；其他地址则拒绝：

Include：格式为include:，表示引入域名下的 SPF 记录。注意，如果该域名下不存在 SPF 记录，则会导致一个PermError结果。例如：

SPF：验证“EHLO”/“HELO”和“MAIL FROM”信息（邮件信封）：

DKIM（DomainKeys Identified Mail，域密钥识别邮件），是一种电子邮件验证系统，旨在帮助接收邮件服务器确定某个电子邮件是否真的由声称拥有其发件人地址的域所授权并发送。

邮件发送方发送邮件时，利用本域私钥加密邮件生成DKIM签名，将DKIM签名及其相关信息插入邮件头。邮件接收方接收邮件时，通过DNS查询获得公钥，验证邮件DKIM签名的有效性。从而确认在邮件发送的过程中，防止邮件被恶意篡改，保证邮件内容的完整性。

密钥生成与存储：发送域首先生成一对公钥和私钥。私钥保留在邮件服务器上，并用于签署即将发出的邮件。公钥则作为DKIM记录存储在发送域的DNS记录中，通常是以TXT类型的DNS记录形式存在。

邮件签署：当邮件从授权的服务器发出时，邮件服务器会使用私钥对邮件的部分或全部内容（通常是邮件头和主体的一部分）进行加密签名。这个签名被添加到邮件头部的DKIM-Signature字段中，包含了一系列标识符（比如d=域名、s=选择器、bh=散列摘要、b=签名数据等）。

邮件验证：当邮件到达接收方邮件服务器时，服务器会提取DKIM-Signature头信息，并查找与邮件中标识的域名和选择器相对应的DKIM记录。接收方邮件服务器从DNS中获取到相应的公钥后，使用该公钥对邮件签名进行解密验证。

如果数字签名验证通过，则表明邮件内容在传输过程中未被篡改，并且邮件的确是从声称的域名授权的服务器发送的。

DKIM记录的格式是在 DNS 中以 TXT 类型的资源记录形式存在的，它包含了公开可用的DKIM公钥和其他相关参数，以便邮件接收服务器能够验证发送自特定域名的电子邮件的真实性。DKIM记录的核心组成部分包括以下几个部分：

此外，DKIM TXT记录还可能包含其他参数，如：

DKIM：对发出的邮件及其标题进行签名，并验证收到的邮件上的签名

DMARC（Domain-based Message Authentication, Reporting and Conformance，基于域名的消息认证、报告与一致性）是对其他两种邮件安全标准DKIM和SPF的补充，旨在解决域名冒充问题，特别是防范那些企图伪装成某个组织或个人进行电子邮件欺诈的行为。

DMARC基于已经广泛部署的SPF和DKIM两种邮件身份验证协议，通过增加域名对齐检查和提供详细的报告机制，强化了电子邮件安全和防止钓鱼攻击的能力。

这一协议是通过DNS发布的。它也可能包含一个邮件地址，邮件系统可以通过该地址报告被拒绝的消息。这样一来，邮件域名的操作者就可以监控真实和伪造邮件的投递情况。

目前也有各种开源工具可用于处理和分析DMARC报告，比如parcedmarc、TA-dmarc等。

DMARC要求SPF和DKIM验证结果与邮件信头中的发信域（即用户直观看到的发信人域名）一致。也就是说，如果邮件信头声称来自example.cn，则SPF和DKIM验证也必须与example.cn保持一致。

DMARC允许域名管理员定义政策，决定邮件服务器在邮件无法通过DMARC验证时应该如何处理，比如“none”（不做任何动作，仅报告）、“quarantine”（隔离邮件，例如放入垃圾邮件文件夹）或“reject”（直接拒收邮件）。

DMARC提供了一个标准化的反馈机制，让邮件接收方能够定期向域名管理员发送关于DMARC检查结果的报告。这些报告可以帮助管理员了解其域名下邮件的发送情况，及时发现并阻止未经授权的邮件发送行为。

DMARC记录的格式是在 DNS 中以 TXT 类型的资源记录形式存在的，DMARC记录的核心组成部分包括以下几个部分：

这个记录中包含了DMARC策略及其参数：

注意：管理员在首次实施DMARC时，通常会先设置为“监控”模式（policy of “none”），收集一段时间的报告，了解正常邮件和潜在欺诈邮件的情况，之后逐步加强策略至“隔离”或“拒绝”。

DMARC：根据发送域在“From”标头中发布的策略处理 SPF 和/或 DKIM 验证的结果

管理员可通过以下测试工具验证相关的邮件安全配置：

在过去，没有办法明确地指示一个域没有邮件服务。发送给这样一个域的邮件发送者必须首先请求MX记录，如果没有找到MX记录，则会回退到查询A/AAAA记录。发送者必须确定（web）服务器没有入站邮件端口（如25端口上的SMTP）才能推断出——在多次无效查询和相当长的延迟之后——该域实际上没有邮件服务。

然而，RFC 7505 引入了一种使用 DNS 明确指示一个域没有邮件服务的方法：Null MX 记录。Null MX 记录格式如下（注意末尾的点）：

由于这一概念相对较新（RFC是在2015年发布的），许多没有邮件服务的域还没有设置Null MX记录。（截至2024年4月，大约有5万个.nl域已经设置了这样的记录。）出于效率和安全性的考虑，建议邮箱或DNS管理员为那些还没有设置Null MX记录的无邮件服务域添加这些记录。

此外，管理员还应该发布一个相应的SPF记录，在该记录中不授权任何服务器为该域发送邮件。一个典型的SPF记录配置可能看起来像这样：

为了进一步增强安全性，除了配置Null MX记录和SPF记录之外，管理员还应该设置一个带有'reject'选项的DMARC记录，并指定一个RUA（Report URI）地址，以便接收关于不符合DMARC策略的消息报告。这里是一个示例DMARC记录，它包含了'reject'选项以及一个报告URI地址：

最后，被指定的DMARC报告接收者必须首先在其自己的域中发布一个DMARC授权记录，以允许接收这些消息。

注：RFC 7505：

https://www.rfc-editor.org/rfc/rfc7505.html