电子邮件身份验证指南

！！注意！！本文档由意大利语自动翻译而来。

指南

配置用于身份验证的电子邮件服务

意大利国家网络安全局发布了 电子邮件服务身份验证配置指南，旨在加强所有相关组织的电子邮件服务可靠性，并提高其整体安全级别。

版本控制

指数

1. 引言

1.1 前提

如今，电子邮件已成为数字化环境中至关重要的服务之一，它是组织和用户进行沟通和信息交流的主要渠道之一。¹.

电子邮件服务的运行，特别是邮件传输，基于SMTP协议。然而，SMTP协议本身并未内置足够的机制来验证发件人身份，也缺乏保护邮件机密性和完整性的机制。这些漏洞使其容易受到欺骗、网络钓鱼、篡改和邮件传输过程中拦截等攻击。.

为了缓解 SMTP 协议的弱点，从而降低上述攻击带来的风险，随着时间的推移，人们开发了发件人身份验证和消息完整性保护机制，例如 SPF（发件人策略框架）、DKIM（域密钥识别邮件）和 DMARC（基于域的消息身份验证、报告和一致性）。.

这些指南阐述了这些机制，旨在加强电子邮件服务的可靠性并提高其整体安全水平，尤其针对第 4 章中描述的威胁。.

保护电子邮件机密性所需的对策和协议（例如涉及邮件加密的 S/MIME 和 OpenPGP）不属于这些指南的主题。.

1.2. 参考规章

1.3 参考文件

返回顶部

2. 监管环境

为了保护国家的数字资产，包括电子邮件服务及其基础设施，已根据现行法律制定了一系列广泛的安全措施，并不断进行更新。.

为保障国家安全，国家最关键的服务（与国家安全息息相关）获得最高级别的保护，国家网络安全边界由2019年9月21日第105号法令设立，并经2019年11月18日第133号法律修订。该边界提供特别高级别的安全措施，详见2021年4月14日第81号总理令附件B。这些措施适用于公共和私营实体的网络、信息系统和IT服务，这些网络、系统和服务是国家履行基本职能或提供维护国家基本利益的公民、社会或经济活动所必需的，一旦遭到破坏，可能会损害国家安全。.

此外，电子邮件服务与所有公共行政部门的数字服务一样，均受所谓“云法规”的约束。该法规依据2012年10月18日第179号法令第33条之七制定，并由国家网络安全局（ACN）于2024年6月27日以第21007号局长令进行了更新。根据上述法规，所有公共行政部门均须按照ACN制定的模型，将其数字数据和服务分类为普通、关键或战略性。此举旨在确保公共行政部门的数字数据和服务通过符合相关要求（包括安全要求）的数字基础设施和云服务进行处理和交付，这些要求与法规中详述的相应分类级别相关的风险相适应。.

2024 年 9 月 4 日第 138 号立法法令（即所谓的 NIS 法令）将指令 (EU) 2022/2555 转化为国内法，并通过 ACN 决定 379907/2025 的附件 1 和附件 2，确立了重要实体为履行 NIS 法令第 23 条和第 24 条规定的义务而采取的基本安全措施，并定义了一个安全框架，以加强对网络和信息系统（包括电子邮件服务）的保护。.

返回顶部

3. 电子邮件服务架构

如前所述，电子邮件服务的运行基于 SMTP 协议，该协议规范电子邮件从发件人到收件人的传输。.

SMTP协议最初于1982年被定义^为 一种存储转发协议，其中发件人通过其邮件客户端（简称MUA）生成邮件，MUA将邮件发送到发件人的邮件服务器。邮件服务器通过名为邮件传输代理（MTA）的组件转发邮件，可能还会经过一个或多个中间MTA，最终将邮件传递到目标邮件服务器的MTA。收件人用户通过其邮件客户端（MUA）访问邮件[1]。

因此，邮件传输代理（MTA）是电子邮件服务的一个组件，负责处理从发件人到收件人的电子邮件传输。MTA 组件存在于发件人和收件人的邮件服务器上，还可以配置中间 MTA，例如，用于管理通讯组列表。.

尽管 MTA 一词指的是电子邮件服务器的特定组件³，但为了本文档的目的，主要指的是电子邮件服务器作为 MTA 的功能，而没有歧义，为了便于阐述，通常会使用“电子邮件服务器”一词来代替更具体的 MTA。

本指南重点介绍 SPF、DKIM 和 DMARC 协议的配置，以便邮件服务器能够验证电子邮件的真实性和完整性。.

返回顶部

4. 威胁

上一章介绍的SMTP协议最初设计用于相对较小的学术网络，并未考虑传输消息的安全性或发送方身份验证等问题。 [1].

电子邮件的日益普及以及 SMTP 协议固有的弱点，随着时间的推移，导致了各种攻击的出现，以下段落简要介绍了这些攻击的主要类型。.

4.1. 发件人欺骗

欺骗 是一种网络攻击技术，用于伪造邮件的发件人地址，使邮件看起来像是来自可靠的地址（例如，同事、熟人或自己的银行机构），诱使收件人执行潜在的危险操作，例如，打开电子邮件附件或点击邮件中的链接。

这种类型的攻击相对容易实施，因为 SMTP 协议不包含发件人身份验证机制，因此，通过电子邮件客户端可以在发送邮件时配置任何发件人地址。.

发件人电子邮件地址：信封发件人和邮件发件人

电子邮件格式提供了两个不同的字段来指示发件人的电子邮件地址。这两个字段分别名为 envelope-from 和 message-from：前者（也称为 return-path， 因为它指定了当电子邮件未能送达收件人时，任何错误消息都必须发送到的电子邮件地址）是用于正确路由邮件的地址；后者是收件人在收到的邮件头中显示的地址。

打个比方，就像通过传统邮件将信件装入信封寄出一样， “信封寄件人” 代表信件信封上显示的寄件人地址，而“ 信件寄件人” 则对应于信件中的抬头，表明是谁写信给收件人。

需要注意的是，这两个地址可能并不一致。这种区别有助于处理诸如转发来自第三方服务的消息、通过邮件列表分发邮件或自动电子邮件回复等情况。.

确实可以在 邮件发件人 级别（收件人在收到的邮件头中显示的发件人电子邮件地址）和 信封发件人 级别（用于邮件传输的发件人电子邮件地址）指定任何发件人。

因此，为了应对这些威胁，必须提供可靠的机制来验证发件人的身份，并确认发送消息的人确实有权这样做。.

4.2 网络钓鱼

网络钓鱼是一种网络攻击技术，旨在通过发送模拟来自可靠^发件人的欺骗性消息，以欺诈手段获取信息（例如登录凭证、信用卡号或其他敏感数据） 。

欺骗是攻击者用来伪造发件人身份并使消息看起来像是来自合法用户或域的主要技术之一。

或者，可以使用与收件人可识别的地址/域类似的发送者地址/域，例如更改所谓的显示名称⁴ ，以增强消息的表面真实性。

攻击者还可以使用先前被盗用的合法账户来发送钓鱼信息。.

网络钓鱼邮件的内容通常旨在引起收件人的紧迫感、恐慌感或经济兴趣，从而诱使他们冲动行事，执行特定操作，例如打开恶意附件或点击重定向到看似合法网站的链接，但实际上这些网站是由攻击者创建的，目的是窃取信息和/或安装恶意软件。.

通常，网络钓鱼攻击是通过向大量受害者发送相同的电子邮件信息来进行的，而不会根据受害者的具体情况调整邮件内容。.

网络钓鱼的一种变体是所谓的 鱼叉式网络钓鱼，攻击者了解并专门针对受害者的个人资料进行攻击。

与普通钓鱼邮件不同，定向钓鱼邮件会使用更精确的上下文信息来使用户相信他们正在与可靠的发件人互动。 [2].

4.3. 信息篡改

与任何其他通过互联网网络传输且未使用端到端加密 (E2EE) 技术的通信一样，电子邮件的内容在发件人和收件人之间传输时可能会被拦截和篡改（这种威胁通常被称为中间人攻击）。.

因此，除了会失去保密性之外，收到的消息可能与发送者最初编写的消息不符。.

例如，攻击者可以篡改消息内容，使其看起来像是来自可靠的发件人，修改消息中的文本或任何链接和/或附件，或者插入恶意代码。.

因此，收件人如果相信消息的表面真实性，就可能被诱使执行潜在的有害操作，例如泄露登录凭证、授权付款或打开恶意文件。.

因此，为了应对这些威胁，必须采取机制来保证信息的完整性和真实性，确保接收到的内容没有被篡改，并且发送者确实是他们所声称的那个人。.

返回顶部

5. 对策

第二章 回顾了有关电子邮件服务安全保护措施的法规。本文档的主要目的是指导如何实施这些法规规定的安全措施（详见 附录A），这些措施也适用于电子邮件服务的配置，旨在降低 第四章。需要注意的是，本指南中的建议也适用于不受上述法规约束的用户。

相关安全措施并非明确针对电子邮件服务的配置，而是根据所依据的法规，针对信息技术系统和工业控制系统（PSNC 和云法规）或信息和网络系统（NIS2）的配置。本指南所涉及的电子邮件服务同时属于这两类系统。.

特别 SPF、 DKIM、 DMARC 协议，这些协议提供了旨在加强电子邮件服务整体安全性的安全机制，特别是发件人身份验证和邮件完整性控制。

5.1. 防晒系数

SPF（发件人策略框架） 是一种身份验证协议，由 RFC 7208，它允许域所有者指定哪些 IP 地址被授权代表其发送电子邮件，并建立收件人在与发件人电子邮件地址的域⁵ 不在明确授权的 IP 地址之列时必须应用的策略。

授权的 IP 地址列在与发件人域相关的 DNS TXT 记录中，称为 SPF 记录，并在本段的后续部分中进行说明。.

这样，当收件人的电子邮件服务器⁶ 收到来自给定域的消息时，可以查询相关的 SPF 记录，并通过验证接收消息的 IP 地址是否属于有权代表该域发送消息的地址来验证其来源。

需要注意的是，SPF 层验证的域名是与信封发件人相关的域名，因此，仅采用 SPF 协议不足以抵御欺骗攻击，因为此类攻击也可能在邮件发件人层进行。⁷.

如果组织将全部或部分电子邮件服务外包给第三方（例如云服务提供商），则必须确保此类提供商发送的邮件通过 SPF 检查。为此，组织应在其 SPF 记录中包含提供商代表组织域名发送电子邮件的 IP 地址。.

对于自动邮件转发，由于邮件通常会被中间服务器重定向，最终投递邮件的 IP 地址不再与发件人域最初授权的 IP 地址一致。在这种情况下，为了避免 SPF 验证失败，必须同时授权所有中间转发服务器，或者采用 SRS（发件人重写方案）或 ARC（认证接收链）等机制，尤其是在存在大量中间转发服务器的情况下，这些机制可能更为有效。.

需要强调的是，要使 SPF 真正有效，不仅发件人必须正确配置，收件人也必须正确配置。具体而言：

• 发件人 ， 声明哪些地址被授权代表其发送电子邮件；
• 收件人 ， 以便对收到的邮件执行 SPF 验证，并一致地应用由此产生的策略。

5.1.1. SPF 记录

SPF 记录是 TXT 类型的 DNS 记录，其名称对应于发件人域，其内容由指示版本 9 的部分和一系列指令组成，^这些指令指示当发件人域的 IP 地址与某个指令匹配时，收件人邮件服务器的行为。

指令由一个前面带有限定符的机制构成。SPF 记录中使用的主要机制有： [2]:

• ip4，列出已授权的 IPv4 地址；
• ip6，列出已授权的 IPv6 地址；
• a，授权域 A 记录中存在的 IP 地址；
• mx，授权与域名的 MX 记录相关的 IP 地址；
• include，授权另一个域的 SPF 记录中存在的 IP 地址；
• all代表所有未通过其他机制明确授权的 IP 地址。

具体来说，该 机制 允许为来自先前机制未声明的 IP 地址的消息建立策略。

此外，SPF 还提供了以下限定符来与机制关联：

• + （pass）表示与关联机制匹配的 IP 地址已获得授权。如果没有指定其他限定符，则它是默认限定符；
• - （失败）表示与关联机制匹配的 IP 地址未获得授权；
• ~ （软失败）表示与关联机制匹配的 IP 地址可能未获得授权。这比之前的声明更不确定。在这种情况下，应该接受该消息，但将其标记为需要更深入的分析，例如用于调试情况或预计 SPF 验证可能不会成功时；
• ? （中性）表示未对与关联机制匹配的 IP 地址给出任何指示。默认行为是接受消息。.

需要强调的是，在实际应用中，SPF 记录通常先指定授权的 IP 地址，然后使用 `-all` 指定所有其他地址均未经授权（相关示例请参见下文）。这是推荐的配置方式，因为它允许明确指定授权的 IP 地址并排除所有其他地址。

总之，建议永远不要使用 +all （或等效的 all指令），因为它相当于授权所有 IP 地址。

SPF 记录示例

授权特定 IP 地址

v=spf1 ip4:203.0.113.0 -all

上述 SPF 记录使用 SPF 版本 1，并通过IPv4机制授权 IP 地址203.0.113.0 （实际上，由于未为IPv4机制指定限定符，因此隐式使用了默认值+ ）。由all机制和- （失败）限定符组成的-all指令指定所有其他地址均未获得授权。

授权特定 IP 地址空间

v=spf1 ip4:203.0.113.0/24 -all

上面显示的 SPF 记录与之前的记录类似，但它授权了 203.0.113.0/24 地址空间的所有 IP 地址。

授权多个 IP 地址

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

上面显示的 SPF 记录专门授权 IPv4 地址 203.0.113.22 和 203.0.113.44。

授权 MX 记录地址和特定域名

v=spf1 mx include:spf.emailprovider.it -all

上面显示的 SPF 记录仅授权与 SPF 记录同域的 MX 记录的 IP 地址以及 spf.emailprovider.it （例如，电子邮件服务提供商的域）的授权 IP 地址。

5.1.2. 身份验证过程

如果正确配置以执行 SPF 验证，收件人的邮件服务器在收到新电子邮件时，会通过查询包含发件人域记录的 DNS 服务器来检索该域的 SPF 记录，查询结果与信封发件人字段中报告的地址一致。例如，如果信封发件人字段中报告的地址是alice@example.com ，则收件人的邮件服务器会检索域example.com的 SPF 记录。

收件人的邮件服务器随后执行 SPF 验证，分析 SPF 记录以确定接收邮件的 IP 地址是否有权代表 example.com 域发送电子邮件。如果电子邮件通过 SPF 验证，则会将其投递给收件人。

例如，如果 example.com 域的 SPF 记录为 v=spf1 ip4:203.0.113.22 -all， 则只有当发件服务器的 IP 地址为 203.0.113.22，验证才会通过，而对于任何其他地址，验证都会失败。

返回顶部

5.2. DKIM

DKIM – DomainKeys Identified Mail 是一种身份验证协议，由 RFC 6376 正式规定，它允许域所有者通过在要传输的消息的标头中附加由邮件服务器使用公共加密算法生成的数字签名（DKIM 签名）来保证所发送电子邮件的真实性。

为了让收件人能够验证邮件在传输过程中是否被修改，与 DKIM 签名关联的公钥会保存在发件人域的公共 DNS 的 TXT 记录中，称为 DKIM 记录，收件人邮件服务器会在收到邮件时查询该记录。.

本段后续章节将对 DKIM 签名和记录进行说明。.

与 SPF 一样，DKIM 也必须由发件人和收件人正确配置，尤其需要注意的是：

• 发件人必须配置其邮件服务器以生成 DKIM 签名，并在相应的 DNS 服务器中发布 DKIM 记录；
• 收件人必须配置其邮件服务器，以便对收到的邮件执行 DKIM 验证。.

5.2.1. DKIM签名

DKIM 签名由消息体和消息头中的指定元素生成，由一系列键值对组成，这些键值对指定了以下元素：

• v：协议版本¹⁰；
• a：使用的加密算法¹¹；
• d：签名域声明消息真实性¹²；
• s：选择器，指示要在 DNS 记录中查找哪个 DKIM 公钥¹³；
• h：签名中包含的电子邮件标头列表¹⁴；
• bh：以 base64 格式编码的消息体的哈希值¹⁵；
• b：使用私钥生成并以 base64 格式编码的实际数字签名¹⁶；
• x：签名有效期；
• c：规范化类型。

规范化是指在对消息元素进行数字签名之前对其进行规范化处理的过程，目的是减少传输过程中可能发生的细微修改（例如重复空格或换行符）的影响。规范化分为两种类型： 简单规范化和宽松规范化。简单规范化要求原始消息和接收消息完全匹配； 宽松规范化则会应用一些规范化操作，例如移除空格、将邮件头中的大写字母转换为小写字母以及减少消息体中的连续空行。

5.2.2. DKIM 记录

DKIM 记录保存在 TXT 类型的 DNS 记录中，其名称结构为 selector._domainkey.domain，其中 _domainkey 是一个标签，用于指示该 DNS 记录确实是 DKIM 记录。DKIM 记录的内容由一系列键值对组成，这些键值对指定了以下元素：

• v：协议版本；
• k：密钥类型，默认值为 RSA；
• p：以 base64 格式编码的公钥。

DKIM 记录示例

名称： s1._domainkey.example.com
值： v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

示例 DKIM 记录与example.com域的选择器s1相关联，使用版本 1，并包含以 base64 格式编码的 RSA 公钥 ( Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h... )。

5.2.3. 身份验证过程

如果发件人和收件人的邮件服务器上都正确配置了 DKIM 协议，DKIM 身份验证和验证过程将确保发件人邮件服务器按照 5.2.1 节所述创建邮件的 DKIM 签名，并将其添加到邮件正文中。具体而言，DKIM 签名的 d 字段包含签名域¹⁷ ， b 字段包含使用签名域的私钥生成的邮件数字签名。

收到邮件后，收件人邮件服务器会从包含该域记录的 DNS 服务器中检索签名域的 DKIM 记录（d 字段）。然后，它使用 DKIM 记录中包含的公钥来验证 DKIM 签名中的数字签名（b 字段）。如果验证成功，则将邮件发送给收件人。

5.2.4. 密码学方面

在加密方面，DKIM 历来使用 RSA 算法，特别是 rsa-sha256 变体，该变体自 2007 年以来一直被认为是标准。RFC 8463是 Ed25519-SHA256，这是一种基于椭圆曲线的现代数字签名形式，可保证更高的效率和更小的密钥。

从技术层面来看，密钥长度为 2048 位的 RSA 仍然是通用标准，但其密钥较长，签名也相对较大。而 Ed25519 的密钥长度仅为 RSA 的九分之一，签名大小仅为 RSA 的四分之一，签名性能比 RSA 2048 提升高达三十倍。尽管 Ed25519 具有这些优势，但其在实际应用中的支持却十分有限：2026 年，只有少数服务提供商验证了 Ed25519，而一些主流运营商对签名和验证的支持也不够可靠，因此它并不适合作为生产环境中的唯一解决方案。.

因此，尽管 Ed25519 在技术上更胜一筹，但在撰写本文档时，除与 RSA 结合使用、通过双重签名、出于实验目的以及作为未来兼容性措施外，不建议单独使用 Ed25519 。在主要服务提供商全面实现其验证之前，RSA 仍然是确保消息最大程度送达的关键。

关于长期安全性，需要记住的是， RSA 和 Ed25519 都无法抵御未来量子计算机的攻击 [3]，而向后量子算法的过渡将需要目前尚不存在的新 DKIM 标准，因此密切关注下一代密码学的发展和 ACN 在该领域的未来建议至关重要。

在加密密钥管理方面，DKIM 私钥必须采取严格的安全措施进行保护，将其保存在只有授权服务才能访问的隔离系统中，采用限制性权限、定期轮换和持续监控，以防止未经授权的访问或泄露。.

返回顶部

5.3. DMARC

DMARC（基于域的消息认证、报告和一致性）是一种认证协议，由 RFC 7489，它集成了^SPF 和 DKIM 机制，允许域所有者向从该域发送的消息的接收者指定管理那些未能通过 SPF 和 DKIM 验证的消息的策略。

具体来说，DMARC 引入了一种称为对齐的认证机制，用于验证 SPF 和 DKIM 认证的域与接收消息的message-from字段对应的域之间的一致性。需要注意的是，如果相应的 SPF/DKIM 验证失败，则message-from字段与 SPF/DKIM 域之间的对齐检查也会失败（参见图 4）。

对齐方式可以采用 严格 模式进行验证，其中 SPF/DKIM 验证的域与 消息来源 字段相关的域必须完全匹配；也 宽松模式，其中只要主域匹配即可，即使子域可能不同。

例如，在宽松模式下，对于域名sub1.example.com和sub2.example.com，由于它们的主域名example.com相同，因此可以进行 DMARC 验证。但在严格模式下，由于域名之间缺乏完全匹配，DMARC 匹配检查将会失败。

通过对齐验证，即使攻击者设法使用与 SPF 认证的信封发件人不同或来自已认证签名域的消息发件人通过了 SPF 和/或DKIM 检查，DMARC 仍然会检测到差异，从而确保对发件人身份进行一致和可靠的验证[2] 。

管理^未通过 DMARC 验证的消息的策略在发件人域的相对 DNS 服务器的 TXT 记录（称为 DMARC 记录）中指定，并在本段的后续部分中进行说明。

DMARC 还允许收件人向发件人域所有者发送报告，报告内容涉及声称源自该域的邮件。这样，域所有者可以验证其域是否被未经授权使用，以及未经授权使用的程度，例如，分析在所有声称源自其域的邮件中，实际可追溯到其域的邮件数量。.

与 SPF 和 DKIM 一样，DMARC 也必须由发件人和收件人正确配置，尤其需要注意以下几点：

• 发件人必须在其 DNS 中发布 DMARC 记录，指定用于管理未通过 DMARC 验证的消息的策略；
• 收件人必须配置其邮件服务器，以对收到的邮件执行 DMARC 验证。.

5.3.1. DMARC记录

DMARC 记录名称的结构为 _dmarc.domain，其中 _dmarc 是一个标签，用于指示 DNS 记录是 DMARC 记录，而 domain 是策略所引用的域。

DMARC 记录由一系列键值对组成，这些键值对指定了以下元素：

• v：DMARC协议版本²⁰；
• p：应用于 DMARC 验证失败的消息的策略，可以取值 none、 quarantine、 reject；
• aspf：应用于 SPF 检查的对齐模式（可以是 宽松、默认值或 严格）；
• adkim：应用于 DKIM 检查的对齐模式（可以是 宽松、默认值或 严格）；
• rua：用于发送包含来自发件人域的邮件的统计和摘要信息的汇总报告的电子邮件地址；
• ruf：用于向其发送有关从发件人域收到的未通过 DMARC 验证的单个消息的详细报告的电子邮件地址。

DMARC记录示例

名称：
_dmarc.example.com
值：
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

示例 DMARC 记录与 example.com 域关联，使用版本 1，并指定 拒绝 策略，拒绝 DMARC 验证失败的消息，请求 严格 模式 ()以验证 SPF 和 DKIM 域的对齐情况，并将汇总报告发送到电子邮件地址 dmarc-reports@example.com ，将失败报告发送到地址 dmarc-fail@example.com。

5.3.2. DMARC 政策

如前段所述，DMARC 记录指示收件人邮件服务器应针对未通过 DMARC 验证的邮件应用何种策略。可能的策略如下：

• 无：发件人域未提供任​​何关于 DMARC 验证失败的消息传递的信息；
• 隔离：发件人域表明，未通过 DMARC 验证的消息应被视为可疑邮件（例如，接受进一步审查、视为垃圾邮件或标记为可疑邮件）；
• 拒绝：发件人域指示应拒绝未通过 DMARC 验证的消息。

5.3.3. 保单核实和申请流程

如果发件人和收件人的邮件服务器上都正确配置了 DMARC 协议，则收件人邮件服务器在收到邮件后会检索 SPF 和 DKIM 记录以执行相关验证，以及 DMARC 验证（详见 5.2.4 节开头）。如果邮件未通过 DMARC 验证，则会应用DMARC 记录中指定的策略（无、隔离或拒绝）。

请注意，每个邮件服务器都可以采用本地启发式算法和策略来决定邮件是否送达，同时也会考虑 SPF、DKIM 和 DMARC 验证的结果。因此，通常在上述验证之后还会有一个额外的决策过程（图 5 中的“标准过滤器”），该过程可能还会包含其他检查（例如，反垃圾邮件和反恶意软件过滤器）。.

此外，收件人邮件服务器还可以传输：

• 向 DMARC 记录的rua字段中指示的地址发送包含从发件人域收到的消息的统计和摘要信息的汇总报告；
• 向 DMARC 记录的ruf字段中指示的地址发送关于从发件人域收到的未通过 DMARC 验证的单个消息的详细报告。

返回顶部

6. 结论

如前一章所述，为了更好地应对与发件人域冒充相关的威胁，必须联合实施所有三个已考察的协议，尤其需要注意的是： [3]:

• 发件人域在 DNS 中正确发布 SPF、DKIM 和 DMARC 记录；
• 发件人的邮件服务器配置为使用 DKIM 对邮件进行签名；
• 收件人的邮件服务器配置为执行 SPF 和 DKIM 验证并应用 DMARC 策略。.

关于协议实施，还提出了以下建议。 [2]:

• 配置 SPF，指定哪些 IP 地址被授权代表该域发送电子邮件；对于不用于电子邮件传输的域（例如仅用于网站的域），仍然应该创建 SPF 记录，以明确表明该域没有有效的电子邮件发件人；
• 使用最先进的加密协议和算法，这些协议和算法被认为对 DKIM 密钥安全；截至撰写本文档之时，建议使用 2048 位 RSA；
• 充分保护存储在邮件服务器上的 DKIM 私钥，采用严格的访问权限，确保只有邮件服务器软件才有读取密钥的权限；
• 为每个邮件服务器配置唯一的密钥对和选择器，以降低私钥泄露可能造成的影响；
• 保护私钥免遭意外泄露以及攻击者试图访问或修改私钥；
• 确保与邮件列表相关的软件能够验证传入邮件的 DKIM 签名，并在传出邮件上附加新的 DKIM 签名；
• 对代表组织发送电子邮件的每个第三方使用唯一的 DKIM 密钥对；
• 定期轮换 DKIM 密钥对（至少每六个月一次），以减轻潜在安全漏洞的影响；
• 一旦怀疑密钥泄露，立即撤销密钥；
• 监控 DMARC 报告，以识别任何配置错误或滥用企图。.

更多详情请参阅参考文档中列出的资源。

据观察，为了充分保护电子邮件安全，除了这里讨论的身份验证协议之外，还有其他协议（这些协议不属于本指南的主题），例如 TLS（传输层安全协议） ，它保证传输通道加密；以及 SMIME 和 OpenPGP ，它们涉及端到端加密和消息身份验证。

此外，值得注意的是，虽然DNSSEC（域名系统安全扩展）并非严格意义上的电子邮件安全协议，但为了电子邮件服务的安全，建议实施DNSSEC。DNSSEC是一种DNS协议扩展，它为DNS记录添加加密签名，以确保DNS查询的完整性和真实性。例如，借助DNSSEC，SPF、DKIM和DMARC记录等信息在传输过程中受到保护，从而降低被篡改的风险，进而提高电子邮件服务的安全性。

返回顶部

附录A：安全措施

国家网络安全边界（PSNC）

PR.IP-1：定义并管理参考实践（所谓的基线），用于配置包含安全原则（例如，最小功能原则）的 IT 系统和工业控制系统。.

1. 有一份详细的更新文件指出，至少在 ID.AM 类别中也存在以下情况：
   • a) 为开发 IT 和工业控制系统配置而采用的安全策略，并且仅部署已采用的配置；
   • b) 所采用的 IT 和工业控制系统配置列表以及相关参考实践；
   • c) 为遵守安全策略而采用的流程、方法和技术。.

云监管——公共管理领域的数字基础设施和服务

PR.IP-01：定义并管理参考实践（所谓的基线），用于配置包含安全原则（例如，最小功能原则）的 IT 系统和工业控制系统。.

1. 政策和程序是参照应用程序安全制定的，旨在为规划、实现和维护应用程序安全功能提供充分的支持，这些政策和程序必须至少每年进行审查和更新。.
2. 有一份详细的更新文件指出，至少在 ID.AM 类别中也存在以下情况：
   • a) 为开发 IT 和工业控制系统配置而采用的安全策略，并且仅部署已采用的配置；
   • b) 所采用的 IT 和工业控制系统配置列表以及相关参考实践；
   • c) 为遵守安全策略而采用的流程、方法和技术。.
3. 已定义并记录了各种应用程序安全的基本要求。.
4. 制定并实施了技术性指标，用于监控对已定义的安全要求和合规义务的遵守程度。.
5. 对于应用程序安全，存在一个应用程序漏洞缓解和恢复流程，并在可能的情况下实现自动修复。.
6. 有一套流程来验证设备与操作系统和应用程序的兼容性。.
7. 操作系统、补丁和/或应用程序方面存在一个变更管理系统。.

云监管——面向公共管理的云服务

PR.IP-01：定义并管理参考实践（所谓的基线），用于配置包含安全原则（例如，最小功能原则）的 IT 系统和工业控制系统。.

1. 政策和程序是参照应用程序安全制定的，旨在为规划、实现和维护应用程序安全功能提供充分的支持，这些功能必须至少每年审查和更新一次[IaaS，SaaS]。.
2. 有一份详细的更新文件指出，至少在 ID.AM 类别中也存在以下情况：
   • a) 为开发 IT 和工业控制系统配置而采用的安全策略，并且仅部署已采用的配置；
   • b) 所采用的 IT 和工业控制系统配置列表以及相关参考实践；
   • c) 为遵守安全策略而采用的流程、方法和技术 [SaaS]。.
3. 已定义并记录了各种应用程序安全的基本要求。.
4. 已定义并实施用于监控对既定安全要求和合规义务遵守程度的技术性指标。5. 已制定应用程序漏洞缓解和恢复流程，以保障应用程序安全，并在可能的情况下实现修复自动化。.
5. 有一个流程用于验证设备与操作系统和应用程序（PaaS、SaaS）的兼容性。.
6. 操作系统、补丁和/或应用程序（PaaS、SaaS）方面存在变更管理系统。.

NIS 2

PR.PS-01：配置管理实践已建立并应用。.

1. 至少对于相关的信息和网络系统，其安全基线配置（强化）已定义并记录在更新的列表中。.
2. 根据措施 GV.PO-01 中提及的政策，已就第 1 点采取并记录了相关程序。.

返回顶部

参考书目

[1] NIST，《技术说明 1945》。
[2] NIST，《NIST 特别出版物 800-177 修订版 1》。
[3] 美国国家网络安全局，《后量子和量子密码学——应对量子威胁的准备》。
[4] 美国国家网络安全局，《电子邮件认证框架》。

返回顶部