电子邮件身份验证指南

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

指南

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

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

版本控制

目录

1. 引言

1.1. 前提

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

电子邮件服务的运行，尤其是邮件的传输，基于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， 第81号总理令的附件B中详细列明，这些措施适用于公共和私营实体的网络、信息系统及信息技术服务。这些实体所承担的职能或提供的服务，对于维持对国家利益至关重要的民事、社会或经济活动具有关键作用，其安全若受到损害，可能危及国家安全。

此外，电子邮件服务与公共行政部门的所有数字服务一样，均须遵守所谓《云服务条例》的规定。该条例依据2012年10月18日第179号法令第33-septies条通过，并由国家网络安全局（ACN）通过2024年6月27日第21007号局长令进行了更新。 根据上述条例，所有公共行政部门均须依据ACN制定的模型，将其数字数据和服务划分为普通、关键或战略三类。此项工作旨在确保公共行政部门的数字数据和服务通过符合要求的数字基础设施和云服务进行处理和交付，包括满足与相关分类级别相关风险相适应的安全要求，具体细则详见该条例。

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

» 返回顶部

3. 电子邮件服务架构

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

SMTP协议最初于1982年制定² 作为一种存储转发协议，发件人通过其邮件客户端（行话中称为邮件用户代理，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

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

打个比方，就像通过传统邮寄方式寄送信件时，信封上的“寄件人地址”代表信封上显示的寄件人地址，而“发件人”则对应信件中的署名，表明是谁写信给收件人的。

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

确实可以在“消息发件人”（收件人在收到的邮件头部看到的发件人电子邮件地址）和“信封发件人”（用于传输邮件的发件人电子邮件地址）两个层面上指定任意发件人。

因此，为了应对这些威胁，必须建立相应的机制，以便可靠地验证发件人的身份，并确认发送消息的人确实具备相应的授权。

4.2. 网络钓鱼

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

上段所述的“欺骗”是攻击者常用的主要手段之一，用于伪造发件人身份，使消息看起来像是来自合法用户或域。

或者，可以使用一个与收件人熟悉的地址/域名相似的发件人地址，例如修改所谓的“显示名称”⁴ ，从而增强邮件表面上的真实性。

为了发送钓鱼信息，攻击者还可以利用此前已被其入侵的合法账户。

钓鱼邮件的内容通常经过精心设计，旨在引发收件人的紧迫感、恐慌情绪或经济利益，从而诱使其冲动行事，执行特定操作，例如打开恶意附件或点击链接。这些链接看似指向合法网站，实则由攻击者创建，其目的是窃取信息和/或安装恶意软件。

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

网络钓鱼的一种变体是所谓的“鱼叉式网络钓鱼”，在此类攻击中，攻击者了解受害者的背景信息，并针对其进行精准攻击。

与普通的钓鱼邮件不同，鱼叉式钓鱼邮件会利用更精准的上下文信息，让用户相信自己正在与可信的发件人进行互动[2]。

4.3. 消息篡改

电子邮件的内容，与任何其他未采用端到端加密（E2EE）技术的互联网通信一样，在发送方与接收方之间的传输过程中可能会被截获和篡改（这种威胁通常被称为“中间人攻击”）。

因此，除了保密性受到损害外，收到的消息可能与发件人最初编写的内容不符。

例如，攻击者可能会篡改消息内容，使其看起来像是来自可信发件人；修改消息中的文本、链接和/或附件；或者植入恶意代码。

收件人若相信该消息看似真实，便可能被诱导执行潜在的有害操作，例如提供登录凭据、授权支付或打开恶意文件。

因此，为了应对这些威胁，必须采取相关机制来保障消息的完整性和真实性，确保接收到的内容未被篡改，并且发件人确实是其自称的身份。

» 返回顶部

5. 应对措施

第2章回顾了规定安全措施的法规，其中也涵盖了电子邮件服务的保护。 本文件主要旨在为实施这些法规所规定且载于附录A中的安全措施提供指导，这些措施同样适用于电子邮件服务的配置，以减轻第4章所讨论的威胁带来的风险。不过，需要指出的是，本指南中的建议也适用于不受上述法规约束的主体。

相关安全措施并未明确涉及电子邮件服务的配置，而是——视具体法规而定——涉及信息技术系统和工业控制系统的配置（《PSNC》和《云服务法规》），或信息与网络系统的配置（《NIS2》）。本指南所涉及的电子邮件服务同时属于这两类系统。

下文将重点介绍SPF、DKIM和DMARC协议，这些协议提供的安全机制旨在增强电子邮件服务的整体安全性，特别是发件人身份验证和消息完整性控制。

5.1. SPF

SPF（发件人策略框架）是一种由RFC 7208 规范化的身份验证协议，它允许域所有者指定哪些 IP 地址有权代表其发送电子邮件，并制定相关政策，规定当与该域关联的 IP 地址⁵ 未在明确授权的IP地址之列时，收件人必须遵循的策略。

授权的 IP 地址列在与发件人域名相关的 DNS TXT 记录中，该记录称为 SPF 记录，具体说明见本段后续部分。

这样一来，收件人的邮件服务器⁶ 在收到来自特定域名的邮件时，可以查询相关的SPF记录，并通过验证邮件来源IP地址是否属于获授权代表该域名发送邮件的IP地址列表，从而验证其来源。

需要注意的是，SPF 级别验证的域名是与信封发件人相关的域名，因此仅采用 SPF 协议并不足以防范欺骗攻击，因为此类攻击可能在消息发件人级别进行⁷。

如果某组织将其电子邮件服务全部或部分外包给第三方（例如云服务提供商），则必须确保这些提供商发送的邮件能够通过 SPF 验证。为此，该组织应在其 SPF 记录中包含这些提供商代表该组织域名发送邮件所使用的 IP 地址。

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

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

• 发件人必须在其相应的DNS服务器上发布SPF记录，声明哪些地址有权代表其发送电子邮件；
• 收件方必须配置其自身的邮件服务器，使其对收到的邮件执行 SPF 验证，并一致地应用验证结果所确定的策略。

5.1.1. SPF 记录

SPF 记录是一种 TXT 类型的 DNS 记录，其名称对应发件人域名，内容由以下内容构成⁸ 由版本标识部分组成⁹ 以及一系列指令，这些指令用于指定当发件人域的 IP 地址与某条指令匹配时，收件人邮件服务器的响应行为。

指令由一个机制组成，该机制前缀有一个限定符。SPF记录中主要使用的机制包括[2]：

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

特别是，该 全部 该机制允许针对来自未被先前机制声明的 IP 地址的消息制定策略。

此外，SPF 还提供了以下修饰符，用于与机制相关联：

• +（通过）表示匹配相关机制的 IP 地址已被授权。如果未指定其他限定符，则此为默认限定符；
• -(失败) 表示与相关机制匹配的 IP 地址未获授权；
• ~（软失败）表示与相关机制匹配的 IP 地址可能未获授权。这一声明比前一种更为不确定。在这种情况下，应接受该消息，但需将其标记以便进行更深入的分析；例如，在调试过程中，或预计 SPF 验证可能无法通过时，会使用此标记；
• ?（中性）表示对于与相关机制匹配的 IP 地址，未给出任何指示。默认行为是接受该消息。

值得强调的是，在实际应用中，SPF 记录的编写目的是为了指定授权的 IP 地址，然后采用该指令 -全部 以明确指定所有其他地址均未获授权（关于这一点，请参阅下文示例）。这是推荐的配置方式，因为它允许明确指定获授权的 IP 地址，并排除所有其他地址。

无论如何，建议永远不要使用该指令 +全部 （或等效内容） 全部) 因为这相当于授权所有 IP 地址。

SPF 记录示例

授权特定 IP 地址

v=spf1 ip4:203.0.113.0 -all

上方的 SPF 记录使用 SPF 1.0 版本，并通过 ip4 机制 IP 地址 203.0.113.0 （事实上，由于未为 ip4 机制，默认 + （隐式使用）。该 -全部 由……形成的指令 全部 机制以及 - (fail) 限定符指定所有其他地址均未获授权。

授权特定的IP地址段

v=spf1 ip4:203.0.113.0/24 -all

上方的 SPF 记录与前一个类似，但授权了该 203.0.113.0/24 地址空间。

授权多个 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 地址，以及该域名的授权 IP 地址 spf.emailprovider.it （例如，某电子邮件服务提供商的域名）。

5.1.2. 身份验证流程

如果已正确配置以执行 SPF 验证，则收件人的邮件服务器在收到新邮件时，会根据信封发件人字段中报告的地址，查询包含该域名记录的 DNS 服务器，从而获取发件人域名的 SPF 记录。例如，如果信封发件人字段中报告的地址是 alice@example.com, 收件人的邮件服务器会检索该域名的 SPF 记录 example.com.

随后，收件人的邮件服务器将执行 SPF 验证，通过分析 SPF 记录来确定接收邮件的 IP 地址是否被授权代表该 example.com 域名。如果电子邮件通过了SPF验证，就会被投递给收件人。

例如，如果该域的SPF记录为 example.com 域名是 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 记录与选择器相关联 s1 的 example.com 域名，使用版本 1，并包含以 base64 格式编码的 RSA 公钥（Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. 身份验证流程

如果发件人和收件人的邮件服务器均正确配置了 DKIM 协议，则 DKIM 认证和验证流程的运作机制要求发件人邮件服务器按照第 5.2.1 节所述为邮件生成 DKIM 签名，并将该签名添加到邮件本身中。具体而言，DKIM 签名包含在 d 填写签名域¹⁷ 以及在 b 使用签名域的私钥生成消息的数字签名，并将其填入该字段。

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

5.2.4. 加密方面

在加密领域，DKIM历来采用RSA算法，尤其是自2007年以来被视为标准的rsa-sha256变体。RFC 8463引入了一种新的替代方案——Ed25519-SHA256，这是一种基于椭圆曲线的现代数字签名方案，能够保证更高的效率并生成更为紧凑的密钥。

从技术层面来看，密钥长度为2048位的RSA仍是通用标准，但其密钥较长且签名体积相对较大；而Ed25519的密钥长度仅为RSA的九分之一，签名体积仅为RSA的四分之一，且签名性能比RSA 2048高出30倍。 尽管具备这些优势，但实际应用中的支持仍显有限：截至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 认证的域名与相关域名的对应关系。 消息来源 接收消息的字段。请注意，在 消息来源 字段，且如果相应的 SPF/DKIM 验证失败，则该 SPF/DKIM 域无论如何都会验证失败（参见图 4）。

可在以下位置验证对齐情况： 严格 模式，该模式要求由 SPF/DKIM 验证的域名与相关域名之间必须完全匹配 消息来源 字段，或 轻松的，此时只需主域名一致即可，即使子域名可能不同。

例如，在 轻松的 域名的模式 sub1.example.com 以及 sub2.example.com 将找到一个用于 DMARC 验证的匹配项（因为主域名， example.com（……也是如此）。在 严格 然而，在该模式下，由于域名之间无法完全匹配，DMARC 对齐检查将会失败。

通过一致性验证，即使攻击者设法利用 消息来源 与……不同 信封寄件人 即使邮件已通过 SPF 验证，且/或来自经过验证的签名域，DMARC 仍会检测到不一致之处，从而确保对发件人身份进行一致且可靠的验证 [2].

处理失败消息的策略¹⁹ DMARC验证失败的消息管理政策，规定在发件人域的相对DNS服务器中名为DMARC记录的TXT记录中，并在本段后续部分中进行了说明。

DMARC 还允许指示收件人向发件人域的所有者发送报告，内容涉及声称源自该域的邮件。通过这种方式，域所有者可以核实其域是否被未经授权地使用以及使用程度如何，例如，分析在所有声称源自该域的邮件中，有多少邮件实际上可追溯至该域。

与SPF和DKIM一样，DMARC也必须由发件人和收件人正确配置，特别是：

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

5.3.1. DMARC 记录

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

DMARC 记录由一系列键值对组成，这些键值对指定了若干元素，其中包括：

• v: DMARC 协议版本²⁰;
• p: 适用于未能通过 DMARC 验证的邮件的策略，可取以下任一值 无, 隔离, 拒绝;
• 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 验证的消息的处理策略，请求 严格 模式 (s) 用于验证 SPF 和 DKIM 域的匹配情况，并将汇总报告发送至该电子邮件地址 dmarc-reports@example.com 并将故障报告发送至该地址 dmarc-fail@example.com.

5.3.2. DMARC 策略

如前一段所述，DMARC 记录规定了接收方邮件服务器应对未通过 DMARC 验证的邮件采取的处理策略。可选策略如下：

• 无：发件人域未提供有关未通过 DMARC 验证的消息投递情况的任何信息；
• 隔离：发件人域指定，未能通过 DMARC 验证的邮件应被视为可疑邮件（例如，需接受进一步审查、被视为垃圾邮件或标记为可疑）；
• reject：发件人域指定应拒绝未能通过 DMARC 验证的消息。

5.3.3. 政策核查与申请流程

如果发件人和收件人的邮件服务器均正确配置了 DMARC 协议，则收件人邮件服务器在收到邮件时会检索 SPF 和 DKIM 记录以执行相关验证，同时还会执行 DMARC 验证（详见第 5.2.4 节开头部分）。如果邮件未能通过 DMARC 验证，则将执行 DMARC 记录中指定的策略（无, 隔离 或 拒绝) 被应用。

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

此外，收件人的邮件服务器可以发送：

• 寄至 rua DMARC 记录的字段，汇总来自发件人域的邮件的统计和摘要信息；
• 寄至 ruf DMARC 记录的字段，其中包含来自发件人域且未能通过 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（域名系统安全扩展）并非一种电子邮件安全协议，但出于电子邮件服务安全考虑，建议实施该协议。作为一种DNS协议扩展，DNSSEC通过在DNS记录中添加加密签名，从而确保DNS查询的完整性和真实性。 例如，得益于DNSSEC，与SPF、DKIM和DMARC记录相关的信息在传输过程中得到了保护，从而降低了被篡改的风险，进而提高了电子邮件服务的安全性。

» 返回顶部

附录 A：安全措施

国家网络安全边界（PSNC）

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

1. 有一份详细的更新文件，其中也涉及类别 ID.AM，至少包括以下内容：
   • a) 制定用于开发信息技术和工业控制系统配置的安全政策，并仅部署已获批准的配置；
   • b) 所采用的信息技术和工业控制系统配置清单，以及相关参考实践的引用；
   • c) 用于确保符合安全政策的各项流程、方法和技术。

云服务监管——面向公共行政的数字基础设施与服务

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

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

云服务监管——面向公共行政部门的云服务

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

1. 应参照应用安全相关规定制定政策和程序，以充分支持应用安全功能的规划、实施和维护，且这些政策和程序必须至少每年进行一次审查和更新 [IaaS, SaaS]。
2. 有一份详细的更新文件，其中也涉及类别 ID.AM，至少包括以下内容：
   • a) 制定用于开发信息技术和工业控制系统配置的安全政策，并仅部署已获批准的配置；
   • b) 所采用的信息技术和工业控制系统配置清单，以及相关参考实践的引用；
   • 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] 国家网络安全局，《电子邮件认证框架》。

» 返回顶部