基于 SMTP DNS 的命名实体身份验证 (DANE) 的工作原理

  • 项目

SMTP 协议是用于在邮件服务器之间传输邮件的main协议，默认情况下不安全。 传输层安全性 (TLS) 协议是在几年前引入的，用于支持通过 SMTP 加密传输消息。 它通常以机会主义方式使用，而不是作为一项要求，使许多电子邮件流量以明文形式显示，容易受到恶意行动者的拦截。 此外，SMTP 通过公共 DNS 基础结构确定目标服务器的 IP 地址，该基础结构容易受到欺骗和中间人 (MITM) 攻击。 此漏洞导致许多新标准被创建，以提高发送和接收电子邮件的安全性，其中一个标准是基于 DNS 的命名实体身份验证 (DANE) 。

用于 SMTP RFC 7672 的 DANE 使用域的 DNS 记录集中存在的传输层安全身份验证 (TLSA) 记录来向域及其邮件服务器发出信号， () 支持 DANE。 如果没有 TLSA 记录，邮件流的 DNS 解析将照常工作，而无需尝试任何 DANE 检查。 TLSA 记录安全地发出 TLS 支持信号，并发布域的 DANE 策略。 因此，发送邮件服务器可以使用 SMTP DANE 成功对合法接收邮件服务器进行身份验证。 此身份验证使其能够抵御降级和 MITM 攻击。 DANE 直接依赖于 DNSSEC，DNSSEC 使用公钥加密对 DNS 查找的记录进行数字签名。 DNSSEC 检查发生在递归 DNS 解析程序（为客户端进行 DNS 查询的 DNS 服务器）上。 DNSSEC 确保 DNS 记录不会被篡改，并且是真实的。

将域的 MX、A/AAAA 和 DNSSEC 相关资源记录作为 DNSSEC 的真实性返回到 DNS 递归解析程序后，发送邮件服务器将要求提供与 MX 主机条目或条目对应的 TLSA 记录。 如果 TLSA 记录存在，并使用另一个 DNSSEC 检查验证其真实性，则 DNS 递归解析程序会将 TLSA 记录返回到发送邮件服务器。

收到正版 TLSA 记录后，发送邮件服务器将建立与真实 TLSA 记录关联的 MX 主机的 SMTP 连接。 发送邮件服务器将尝试设置 TLS，并将服务器的 TLS 证书与 TLSA 记录中的数据进行比较，以验证连接到发件人的目标邮件服务器是否是合法的接收邮件服务器。 如果身份验证成功，将使用 TLS) (传输消息。 当身份验证失败或目标服务器不支持 TLS 时，Exchange Online将在 15 分钟后、15 分钟后、之后 15 分钟、接下来的 24 小时内每小时重试整个验证过程。 如果身份验证在重试 24 小时后继续失败，消息将过期，并且将生成包含错误详细信息的 NDR 并将其发送给发送方。

提示

如果你不是 E5 客户，请使用为期 90 天的 Microsoft Purview 解决方案试用版来探索其他 Purview 功能如何帮助组织管理数据安全性和合规性需求。 立即从Microsoft Purview 合规门户试用中心开始。 了解有关 注册和试用条款的详细信息。

DANE 的组件是什么？

TLSA 资源记录

TLS 身份验证 (TLSA) 记录用于将服务器的 X.509 证书或公钥值与包含该记录的域名相关联。 只有在域上启用了 DNSSEC 时，才能信任 TLSA 记录。 如果使用 DNS 提供程序托管域，则 DNSSEC 可能是配置域时提供的设置。 若要详细了解 DNSSEC 区域签名，请访问此链接：DNSSEC 概述 |Microsoft Docs。

TLSA 记录示例：

TLSA 记录示例

TLSA 记录类型有四个唯一的可配置字段：

证书用法字段：指定发送电子邮件服务器应如何验证目标电子邮件服务器的证书。

值 首字母缩略词 说明
01 PKIX-TA 使用的证书是 X.509 信任链中的信任定位点公共 CA。
11 PKIX-EE 选中的证书是目标服务器;DNSSEC 检查必须验证其真实性。
2 DANE-TA 使用 X.509 树中的服务器的私钥，该密钥必须由信任链中的信任定位点进行验证。 TLSA 记录指定用于验证域的 TLS 证书的信任定位点。
3 DANE-EE 仅与目标服务器的证书匹配。

1 Exchange Online遵循 RFC 实现指南，即当使用 SMTP 实现 DANE 时，不应使用证书使用字段值 0 或 1。 将证书使用情况字段值为 0 或 1 的 TLSA 记录返回到Exchange Online时，Exchange Online会将其视为不可用。 如果发现所有 TLSA 记录都不可用，Exchange Online发送电子邮件时不会执行 0 或 1 的 DANE 验证步骤。 相反，由于存在 TLSA 记录，Exchange Online将强制使用 TLS 发送电子邮件、在目标电子邮件服务器支持 TLS 时发送电子邮件或删除电子邮件，并在目标电子邮件服务器不支持 TLS 时生成 NDR。

在示例 TLSA 记录中，“证书使用情况字段”设置为“3”，因此证书关联数据 ('abc123...xyz789') 将仅针对目标服务器的证书进行匹配。

选择器字段：指示应检查目标服务器的证书的哪些部分。

值 首字母缩略词 说明
0 证书 使用完整证书。
1 SPKI (使用者公钥信息) 使用证书的公钥以及用于标识公钥的算法。

在示例 TLSA 记录中，选择器字段设置为“1”，因此将使用目标服务器证书的公钥和用于标识公钥的算法来匹配证书关联数据。

匹配类型字段：指示证书将在 TLSA 记录中表示的格式。

值 首字母缩略词 说明
0 完整 TSLA 记录中的数据是完整的证书或 SPKI。
1 SHA-256 TSLA 记录中的数据是证书或 SPKI 的 SHA-256 哈希。
2 SHA-512 TSLA 记录中的数据是证书或 SPKI 的 SHA-512 哈希。

在示例 TLSA 记录中，“匹配类型字段”设置为“1”，因此证书关联数据是目标服务器证书中使用者公钥信息的 SHA-256 哈希

证书关联数据：指定用于与目标服务器证书匹配的证书数据。 此数据取决于选择器字段值和匹配类型值。

在示例 TLSA 记录中，证书关联数据设置为“abc123”。xyz789'。 由于示例中的“选择器字段”值设置为“1”，因此它将引用目标服务器证书的公钥以及标识为与之一起使用的算法。 由于示例中的“匹配类型”字段值设置为“1”，因此它将从目标服务器证书引用使用者公钥信息的 SHA-256 哈希。

Exchange Online客户如何使用 SMTP DANE 出站？

作为Exchange Online客户，无需执行任何操作即可为出站电子邮件配置此增强的电子邮件安全性。 此增强的电子邮件安全性是我们为你构建的，它默认为所有Exchange Online客户启用，并在目标域播发对 DANE 的支持时使用。 若要获得使用 DNSSEC 和 DANE 检查发送电子邮件的好处，请与你交换电子邮件的业务合作伙伴沟通，告知他们需要实现 DNSSEC 和 DANE，以便他们能够使用这些标准接收电子邮件。

Exchange Online客户如何使用 SMTP DANE 入站？

目前，Exchange Online不支持入站 SMTP DANE。 不久的将来将提供对入站 SMTP DANE 的支持。

根据 SMTP DANE 的 RFC 实现指南，建议使用由“证书使用情况”字段设置为 3、“选择器”字段设置为 1、“匹配类型”字段设置为 1 组成的 TLSA 记录。

使用 SMTP DANE Exchange Online邮件流

使用 SMTP DANE 进行Exchange Online的邮件流流程（如下图所示）通过 DNSSEC 验证域和资源记录的安全性、目标邮件服务器上的 TLS 支持，以及目标邮件服务器的证书是否与其关联的 TLSA 记录的预期证书匹配。

只有两种情况，SMTP DANE 失败会导致电子邮件被阻止：

  • 目标域发出 DNSSEC 支持信号，但一个或多个记录返回为“不真实”。

  • 目标域的所有 MX 记录都具有 TLSA 记录，并且目标服务器的证书都不符合 TSLA 记录数据的预期，或者目标服务器不支持 TLS 连接。

使用 SMTP DANE 交换联机邮件流

技术 其他信息
邮件传输代理 - 严格的传输安全 (MTA-STS) 提供一种机制，用于设置域策略，指定目标电子邮件服务器是否支持 TLS 以及无法协商 TLS 时应执行的操作（例如停止传输），帮助阻止降级和中间人攻击。 有关Exchange Online即将推出的入站和出站 MTA-STS 支持的详细信息将在今年晚些时候发布。

Microsoft Ignite 2020 Exchange Online交通新闻 - Microsoft Tech Community

rfc8461 (ietf.org)
发件人策略框架 (SPF) 使用 IP 信息来确保目标电子邮件系统信任从自定义域发送的邮件。 发件人策略框架 (SPF) 如何防止欺骗
域密钥标识邮件 (DKIM) 使用 X.509 证书信息来确保目标电子邮件系统信任从自定义域出站发送的邮件。 如何在自定义域中使用 DKIM 发送电子邮件
基于域的邮件身份验证、报告和符合性 (DMARC) 与发件人策略框架和域密钥标识邮件配合使用，对邮件发件人进行身份验证，并确保目标电子邮件系统信任从域发送的邮件。 使用 DMARC 验证电子邮件，设置步骤

使用 SMTP DANE 排查发送电子邮件问题

目前，使用 Exchange Online 发送电子邮件时，DANE 有四个错误代码。 Microsoft 正在积极更新此错误代码列表。 错误将在以下位置可见：

  1. 通过“邮件跟踪详细信息”视图的 Exchange 管理员中心门户。
  2. 由于 DANE 或 DNSSEC 故障未发送消息时生成的NDR。
  3. 远程连接分析器工具 Microsoft 远程连接分析器。
NDR 代码 说明
4/5.7.321 starttls-not-supported：目标邮件服务器必须支持 TLS 才能接收邮件。
4/5.7.322 证书已过期：目标邮件服务器的证书已过期。
4/5.7.323 tlsa-invalid：域未通过 DANE 验证。
4/5.7.324 dnssec-invalid：目标域返回了无效的 DNSSEC 记录。

注意

目前，当域发出支持 DNSSEC 但 DNSSEC 检查失败的信号时，Exchange Online不会生成 4/5.7.324 dnssec 无效错误。 它生成一个泛型 DNS 错误：

4/5.4.312 DNS query failed

我们正在积极努力纠正这一已知限制。 如果收到此错误声明，请导航到 Microsoft 远程连接分析器，针对生成 4/5.4.312 错误的域执行 DANE 验证测试。 结果将显示是 DNSSEC 问题还是其他 DNS 问题。

4/5.7.321 starttls-not-supported 疑难解答

此错误通常表示目标邮件服务器存在问题。 收到消息后：

  1. 检查是否已正确输入目标电子邮件地址。
  2. 提醒目标电子邮件管理员你收到了此错误代码，以便他们能够确定目标服务器是否已正确配置为使用 TLS 接收消息。
  3. 重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。

排查 4/5.7.322 证书过期问题

必须向发送电子邮件服务器提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订，通常每年续订一次。 收到消息后：

  1. 提醒目标电子邮件管理员你收到了此错误代码，并提供错误代码字符串。
  2. 留出时间来续订目标服务器证书，并更新 TLSA 记录以引用新证书。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。

排查 4/5.7.323 tlsa 无效问题

此错误代码与 TLSA 记录配置错误相关，只能在返回 DNSSEC 验证 TLSA 记录后生成。 在 DANE 验证期间，有许多方案在返回记录后发生，这可能会导致生成代码。 Microsoft 正在积极处理此错误代码涵盖的方案，以便每个方案都有一个特定的代码。 目前，以下一种或多种方案可能会导致生成错误代码：

  1. 目标邮件服务器的证书与每个身份验证 TLSA 记录的预期证书不匹配。
  2. 错误配置了身份验证 TLSA 记录。
  3. 目标域受到攻击。
  4. 任何其他 DANE 失败。

收到消息后：

  1. 提醒目标电子邮件管理员你收到了此错误代码，并向他们提供错误代码字符串。
  2. 允许目标电子邮件管理员有时间查看其 DANE 配置和电子邮件服务器证书的有效性。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。

排查 4/5.7.324 dnssec 无效问题

当目标域指示其为 DNSSEC 身份验证，但Exchange Online无法将其验证为 DNSSEC-authentic 时，将生成此错误代码。

收到消息后：

  1. 提醒目标电子邮件管理员你收到了此错误代码，并向他们提供错误代码字符串。
  2. 让目标电子邮件管理员有时间查看其域的 DNSSEC 配置。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。

使用 SMTP DANE 排查电子邮件接收问题

目前，接收域的管理员可以使用两种方法来验证 DNSSEC 和 DANE 配置并对其进行故障排除，以使用这些标准从Exchange Online接收电子邮件。

  1. 采用 RFC8460 中引入的 SMTP TLS-RPT (传输层安全报告 )
  2. 使用远程连接分析器工具 Microsoft 远程连接分析器

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 是一种报告机制，供发件人向目标域管理员提供有关这些目标域的 DANE 和 MTA-STS 成功和失败的详细信息。 若要接收 TLS-RPT 报告，只需在域的 DNS 记录中添加 TXT 记录，其中包含要向其发送报表的电子邮件地址或 URI。 Exchange Online将以 JSON 格式发送 TLS-RPT 报告。

示例记录：

示例记录

第二种方法是使用远程连接分析器 Microsoft 远程连接分析器，它可以对 DNS 配置执行相同的 DNSSEC 和 DANE 检查，Exchange Online在服务外部发送电子邮件时会执行。 此方法是使用这些标准从Exchange Online接收来自配置中的错误的最直接方法。

排查错误时，可能会生成以下错误代码：

NDR 代码 说明
4/5.7.321 starttls-not-supported：目标邮件服务器必须支持 TLS 才能接收邮件。
4/5.7.322 证书已过期：目标邮件服务器的证书已过期。
4/5.7.323 tlsa-invalid：域未通过 DANE 验证。
4/5.7.324 dnssec-invalid：目标域返回了无效的 DNSSEC 记录。

注意

目前，当域发出支持 DNSSEC 但 DNSSEC 检查失败的信号时，Exchange Online不会生成 4/5.7.324 dnssec 无效错误。 它生成一个泛型 DNS 错误：

4/5.4.312 DNS query failed

我们正在积极努力纠正这一已知限制。 如果收到此错误声明，请导航到 Microsoft 远程连接分析器，针对生成 4/5.4.312 错误的域执行 DANE 验证测试。 结果将显示是 DNSSEC 问题还是其他 DNS 问题。

4/5.7.321 starttls-not-supported 疑难解答

注意

这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。

此错误通常表示目标邮件服务器存在问题。 远程连接分析器正在测试连接的邮件服务器。 通常有两种生成此代码的方案：

  1. 目标邮件服务器根本不支持安全通信，必须使用非加密的普通通信。
  2. 目标服务器配置不正确，忽略 STARTTLS 命令。

收到消息后：

  1. 检查电子邮件地址。
  2. 找到与错误语句关联的 IP 地址，以便可以标识与该语句关联的邮件服务器。
  3. 检查邮件服务器的设置，确保它配置为侦听 SMTP 流量， (通常端口 25 和 587) 。
  4. 等待几分钟，然后使用远程连接分析器工具重试测试。
  5. 如果仍然失败，请尝试删除 TLSA 记录，并再次使用远程连接分析器工具运行测试。
  6. 如果没有失败，则此消息可能指示用于接收邮件的邮件服务器不支持 STARTTLS，并且可能需要升级到一个支持 STARTTLS 的邮件服务器才能使用 DANE。

排查 4/5.7.322 证书过期问题

注意

这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。

必须向发送电子邮件服务器提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订，通常每年续订一次。 收到消息后：

  1. 检查与错误语句关联的 IP，以便可以标识它关联的邮件服务器。 在标识的电子邮件服务器上找到过期的证书。
  2. 登录到证书提供程序的网站。
  3. 选择过期的证书，并按照说明续订并支付续订费用。
  4. 提供商验证购买后，可以下载新证书。
  5. 将续订的证书安装到其关联的邮件服务器。
  6. 使用新证书的数据更新邮件服务器的关联 TLSA 记录。
  7. 等待适当时间后，请使用远程连接分析器工具重试测试。

排查 4/5.7.323 tlsa 无效问题

注意

这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。

此错误代码与 TLSA 记录配置错误相关，只能在返回 DNSSEC 验证的 TSLA 记录后生成。 但是，在 DANE 验证期间，有许多方案在返回记录后发生，这可能会导致生成代码。 Microsoft 正在积极处理此错误代码涵盖的方案，以便每个方案都有一个特定的代码。 目前，以下一种或多种方案可能会导致生成错误代码：

  1. 错误配置了身份验证 TLSA 记录。
  2. 证书尚未在将来的时间范围内有效/配置。
  3. 目标域受到攻击。
  4. 任何其他 DANE 失败。

收到消息后：

  1. 检查与错误语句关联的 IP，以标识它关联的邮件服务器。
  2. 标识与标识的邮件服务器关联的 TLSA 记录。
  3. 验证 TLSA 记录的配置，确保它向发送方发出信号以执行首选 DANE 检查，并且 TLSA 记录中包含正确的证书数据。
    1. 如果必须对记录进行任何差异更新，请等待几分钟，然后使用远程连接分析器工具重新运行测试。
  4. 在标识的邮件服务器上找到证书。
  5. 检查证书有效的时间范围。 如果设置为在未来日期开始有效，则需要在当前日期续订它。
    1. 登录到证书提供程序的网站。
    2. 选择过期的证书，并按照说明续订并支付续订费用。
    3. 提供商验证购买后，可以下载新证书。
    4. 将续订的证书安装到其关联的邮件服务器。

排查 4/5.7.324 dnssec 无效问题

注意

这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。

当目标域指示其为 DNSSEC-authentic，但Exchange Online无法将其验证为 DNSSEC-authentic 时，将生成此错误代码。 本部分不会全面解决 DNSSEC 问题，重点介绍域以前通过 DNSSEC 身份验证但现在未通过的方案。

收到消息后：

  1. 如果使用 DNS 提供程序（例如 GoDaddy），请向 DNS 提供程序发出错误警报，以便他们能够进行故障排除和配置更改。
  2. 如果要管理自己的 DNSSEC 基础结构，则有许多 DNSSEC 错误配置可能会生成此错误消息。 如果区域以前通过 DNSSEC 身份验证，检查一些常见问题：
    1. 当父区域包含一组指向子区域中不存在的内容的 DS 记录时，信任链断开。 DS 记录的此类指针可能会导致子区域通过验证解析程序被标记为虚假。
      • 通过查看子域 RRSIG 密钥 ID 并确保它们与父区域中发布的 DS 记录中的密钥 ID 匹配来解决。
    2. 域的 RRSIG 资源记录无效，已过期，或者其有效期尚未开始。
      • 通过使用有效的时间跨度为域生成新签名来解决。

注意

如果Exchange Online从 DNS 服务器接收来自目标域的 TLSA 查询的 SERVFAIL 响应，也会生成此错误代码。

发送出站电子邮件时，如果接收域已启用 DNSSEC，我们会查询与域中 MX 条目关联的 TLSA 记录。 如果未发布 TLSA 记录，则 TLSA 查找的响应必须为 NOERROR (此域) 或 NXDOMAIN 请求类型的记录， (没有此类域) 。 如果未发布 TLSA 记录，DNSSEC 需要此响应;否则，Exchange Online将缺少响应解释为 SERVFAIL 错误。 根据 RFC 7672，SERVFAIL 响应是不可信的;因此，目标域未通过 DNSSEC 验证。 然后，此电子邮件将延迟，并出现以下错误：

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

如果电子邮件发件人报告邮件的回执

如果使用的是 DNS 提供程序（例如 GoDaddy），请向 DNS 提供程序发出错误警报，以便他们能够对 DNS 响应进行故障排除。 如果要管理自己的 DNSSEC 基础结构，则可能是 DNS 服务器本身或网络出现问题。

常见问题

作为Exchange Online客户，我是否可以选择不使用 DNSSEC 和/或 DANE？

我们坚信 DNSSEC 和 DANE 将显著提升我们服务的安全地位，并使所有客户受益。 在过去的一年里，我们一直在努力降低此部署对 Microsoft 365 客户的潜在影响的风险和严重性。 我们将积极监视和跟踪部署，以确保在部署推出时将负面影响降到最低。因此，租户级异常或选择退出将不可用。 如果遇到与启用 DNSSEC 和/或 DANE 相关的任何问题，则本文档中介绍的用于调查失败的不同方法将帮助你确定错误的来源。 在大多数情况下，问题出在外部目标方，你需要告知这些业务合作伙伴需要正确配置 DNSSEC 和 DANE 才能使用这些标准接收来自Exchange Online的电子邮件。

DNSSEC 与 DANE 的关系如何？

DNSSEC 通过应用公钥基础结构向 DNS 解析添加信任层，以确保响应 DNS 查询时返回的记录是真实的。 DANE 确保接收邮件服务器是真实 MX 记录的合法和预期的邮件服务器。

MTA-STS 与用于 SMTP 的 DANE 之间有何区别？

DANE 和 MTA-STS 用途相同，但 DANE 需要 DNSSEC 进行 DNS 身份验证，而 MTA-STS 依赖于证书颁发机构。

为什么机会性 TLS 不够？

如果两个终结点都同意支持，则机会性 TLS 将加密两个终结点之间的通信。 但是，即使 TLS 对传输进行加密，也可能在 DNS 解析过程中欺骗域，使其指向恶意参与者的终结点，而不是域的真实终结点。 此欺骗是电子邮件安全性中的一个差距，可通过使用 DNSSEC 实现 MTA-STS 和/或 SMTP DANE 来解决。

为什么 DNSSEC 不够？

对于邮件流方案，DNSSEC 无法完全抵御中间人攻击并将 (从 TLS 降级为明文) 攻击。 添加 MTA-STS 和 DANE 以及 DNSSEC 提供了一种全面的安全方法来挫败 MITM 攻击和降级攻击。

查找并修复添加域或 DNS 记录之后出现的问题

DNSSEC 概述 |Microsoft Docs

使用 DMARC 验证电子邮件、设置步骤 - Office 365 |Microsoft Docs

如何在自定义域中对电子邮件使用 DKIM - Office 365 |Microsoft Docs

发件人策略框架 (SPF) 如何防止欺骗 - Office 365 |Microsoft Docs

Microsoft Ignite 2020 Exchange Online交通新闻 - Microsoft Tech Community

rfc8461 (ietf.org)