SMTP 协议是用于在邮件服务器之间传输邮件的主要协议。 默认情况下，它不安全。 传输层安全性 (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 分钟后针对同一目标域的 DNS 查询开始，然后在 15 分钟之后，然后在接下来的 24 小时内每隔一小时查询一次。 如果身份验证在重试 24 小时后继续失败，消息将过期，并且会生成包含错误详细信息的 NDR 并将其发送给发件人。
DANE 的组件是什么？
TLSA 资源记录
使用 TLS 身份验证 (TLSA) 记录将服务器的 X.509 证书或公钥值与包含记录的域名相关联。 只有在域上启用 DNSSEC 时，才能信任 TLSA 记录。 如果使用 DNS 提供程序托管域，则它们可能会在配置域时提供 DNSSEC 作为设置。 有关 DNSSEC 区域签名的详细信息，请参阅 DNSSEC 概述。
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 哈希。
建议的 TLSA 记录配置是什么？
根据 SMTP DANE 的 RFC 实现指南，使用 TLSA 记录，其中“证书使用情况”字段设置为 3，“选择器”字段设置为 1，并将“匹配类型”字段设置为 1。
使用 SMTP DANE Exchange Online邮件流
以程图中所示，使用 SMTP DANE Exchange Online的邮件流过程通过 DNSSEC 验证域和资源记录的安全性、目标邮件服务器上的 TLS 支持，以及目标邮件服务器的证书是否与其关联的 TLSA 记录的预期证书匹配。
只有两种情况，SMTP DANE 失败会导致电子邮件被阻止：
目标域表示 DNSSEC 支持，但一条或多条记录返回为“不真实”。
目标域的所有 MX 记录都具有 TLSA 记录，并且目标服务器的证书都不符合 TSLA 记录数据的预期，或者目标服务器不支持 TLS 连接。
相关技术
| 技术 | 其他信息 |
|---|---|
| 邮件传输代理 - 严格的传输安全 (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 验证电子邮件，设置步骤 |
使用 DNSSEC 的入站 SMTP DANE
先决条件
在开始之前，请确保满足以下先决条件：
- 将域添加为“接受的域”，并确保Microsoft 365 管理中心中的域状态为“正常”。 本文档假定域的 MX 记录设置为优先级 0 或 10，并且没有“回退”或辅助 MX 记录。 如果有回退 MX 记录，请与Exchange Online管理员密切合作，确保正确执行更改。
- 若要获得该功能的全部安全优势，请为域启用 DNSSEC。
- Exchange Online PowerShell 的访问权限以及运行 Exchange Online PowerShell 中所述的 cmdlet 的权限。
注意
若要为使用第三方网关的域启用 DNSSEC，请按照第三方网关上步骤 3 末尾的说明执行步骤 1 到 3。
使用 DNSSEC 设置入站 SMTP DANE
注意
DNS 记录预配和更新可能需要一些时间才能完成。 由于多层缓存，DNS 更改可能需要比预期更长的时间才能可见。
若要使用 DNSSEC 设置入站 SMTP DANE，请执行以下步骤：
将现有 MX 记录的 TTL 更新为尽可能低的 TTL (但不低于 30 秒) 。 然后，等待上一个 TTL 过期，然后再继续作。 例如，如果现有 MX 记录的 TTL 为 3,600 秒 (1 小时) 更改，则需要等待 1 小时才能继续执行步骤 2。
连接到 Exchange Online PowerShell。
警告
如果使用 MTA-STS，则需要将策略模式设置为“测试”，并更新 MTA-STS txt 记录中的 ID。 (可以使用 UTC 中的当前时间作为新策略 ID.) 然后等待策略的“max_age”过期，然后继续作。 例如，如果现有 STS 策略的“max_age”为 3,600 秒 (1 小时) 更改策略，则需要等待 1 小时才能继续。
对于要使用 DNSSEC 启用 SMTP DANE 的域，请运行以下命令， (将“域”替换为所选域的名称（例如，contosotest.com) ）：在域上启用 DNSSEC：
Enable-DnssecForVerifiedDomain -DomainName <DomainName>注意
此命令可能需要几分钟才能执行。
成功执行的示例输出
结果 DnssecMxValue ErrorData 成功 contosotest-com.o-v1.mx.microsoft 成功响应提供域的 MX 值。 此值是新 MX 记录指向使用 DNSSEC 启用的域的名称。 例如，
contosotest-com.o-v1.mx.microsoft。获取“DnssecMxValue”值，转到托管域的 DNS 注册机构，使用步骤 3 中返回的值添加新的 MX 记录，将 TTL 设置为 (但不低于 30 秒) 的可能值，并将新 MX 记录的优先级设置为 20。
注意
如果使用第三方电子邮件网关，并且想要将此值用作第三方电子邮件网关向其发送入站邮件的新Exchange Online目标主机，请转到第三方的管理门户，更新第三方用于发送到Exchange Online的目标智能主机，然后验证“通过 DNSSEC 测试工作的邮件流 (请确保在测试输入期间选择“DNSSEC 验证”，而不是Microsoft远程连接分析器：测试输入“中的”DANE 验证 [包括 DNSSEC]) ”。 如果邮件按预期方式流动，则无需继续执行以下步骤。 如果要为此域启用 SMTP DANE，请跳到步骤 7。
警告
如果使用 MTA-STS，请确保策略模式设置为“测试”。 然后，删除包含旧版 MX 记录信息的当前 mx 行，并将新的 FQDN 作为新 mx 行添加到 MTA-STS 策略文件。 然后，更新策略中的策略 ID 和 MTA-STS TXT 记录， (可以使用 UTC 中的当前时间作为新策略 ID) 。
通过展开“测试https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input步骤”并验证以 mx.microsoft 结尾的邮件交换器是否已成功测试，验证新 MX 是否通过入站 SMTP Email测试 () 工作。 可能需要重试此测试，具体取决于 DNS 缓存。
成功输出示例
将指向 mail.protection.outlook.com 的旧版 MX 的优先级从当前优先级更改为 30;更改在步骤 3 中创建的 MX 记录的优先级，使其设置为优先级 0 (最高优先级) 。
删除以“mail.protection.outlook.com”、“mail.eo.outlook.com”或“mail.protection.outlook.de”结尾的旧 MX 记录。 然后，将以 mx.microsoft 结尾的 MX 记录的 TTL 更新为 3,600 秒。 （可选）可以使用 DNSSEC 测试 (确保你在测试输入期间选择“DNSSEC 验证”，而不是在 远程连接分析器中选择“DANE 验证 [包括 DNSSEC]) ”来确认一切按预期工作。 可能需要重试此测试，具体取决于 DNS 缓存和 TTL。
旧版 MX 记录上的 TTL 过期后，成功的输出将如下所示：
如果要在 DNSSEC 启用完成后为同一域启用 SMTP DANE，请运行以下命令 [将 (DomainName) 替换为所选域的名称，例如，contosotest.com] ：
Enable-SmtpDaneInbound -DomainName <DomainName>结果 ErrorData 成功 通过使用所选的在线工具和 Microsoft 远程连接分析器：测试输入，验证 TLSA 记录是否已传播 (可能需要 15-30 分钟) 。
完成 DNSSEC 启用并 (TLSA) 由 Exchange Online 预配 SMTP DANE 记录后，将显示成功的输出，如以下屏幕截图所示：
Exchange Online托管多个 TLSA 记录，以提高 SMTP DANE 验证成功的可靠性。 预计某些 TLSA 记录未通过验证。 只要一条 TLSA 记录通过验证，SMTP DANE 就配置正确，并且电子邮件使用 SMTP DANE 进行保护。
警告
如果使用 MTA-STS，在验证策略是否有效且邮件按预期流动后，请将策略模式设置为“强制实施”并更新 MTA-STS txt 记录中的 ID。 (可以使用 UTC 中的当前时间作为新策略 ID。)
限制
病毒式或自助注册域：DNSSEC 入站 SMTP DANE 目前不支持设置为“自助服务”的域。
onmicrosoft.com 域：DNSSEC 入站 SMTP DANE 当前不支持租户的“onmicrosoft.com”域。 我们正在调查对 onmicrosoft.com 域的入站 SMTP DANE 和 DNSSEC 的支持;但是，ETA 未知。
第三方网关：如果在接受租户邮件的入站路径上使用第三方电子邮件网关，则执行某些处理，然后将其中继到Exchange Online，则仅当第三方网关支持使用 DNSSEC 验证的 SMTP DANE 时，才能使用此功能保护从第三方网关中继到Exchange Online的电子邮件。 如果处于此配置中，则需要使用 Exchange PowerShell 通过 DNSSEC 设置入站 SMTP DANE。
其他第三方与邮件流的集成：某些客户在出站路径上使用第三方网关，其中电子邮件通过连接器发送到第三方，第三方执行一些处理，然后重新提交到Exchange Online，然后Exchange Online最后发送电子邮件。 这些客户在启用该功能时可能需要与第三方提供商合作，以免出现中断。 将电子邮件提交回Exchange Online时，第三方中继需要使用 DNS 查找，并使用在启用功能期间创建的新 MX 记录主机名 -> contoso-com. (子域) .mx.microsoft。
完全委托的域：DNSSEC 入站 SMTP DANE 支持Microsoft主机并使用 NS 委派的域，以便Microsoft的名称服务器对域具有权威性。 我们打算为这些域使用 DNSSEC 支持入站 SMTP DANE;但是，ETA 未知。
调试使用 DNSSEC 启用入站 SMTP DANE 时出现的问题
Enable/Disable-DnssecForVerifiedDomain 和 Enable/Disable-SmtpDane 入站的问题
DomainNotFoundDNSSEC) (消息 ：“由于 AAD 中不存在域 contoso.com DNSSEC 启用/禁用失败。
邮件 (SMTP DANE) ：- 由于 AAD 中不存在域 contoso.com，SMTP DANE 启用/禁用失败。”
- “SMTP DANE 启用/禁用失败，因为域 contoso.com 在接受域列表中找不到。”
原因：在接受域列表中找不到提供的域。
作 () 采取：转到Microsoft 365 管理中心，并确保使用租户验证域。 如果域在Microsoft 365 管理中心正常，请转到 Exchange 管理员中心，并确保域已添加为“接受域”。
DNSSEC
结果 DnssecMxValue ErrorData 错误 ErrorCode： 'DomainNotFound' ErrorDetails 'DNSSEC 启用失败... SMTP DANE
结果 ErrorData 错误 ErrorCode： 'DomainNotFound' ErrorDetails 'SMTP DANE 启用... - 由于 AAD 中不存在域 contoso.com，SMTP DANE 启用/禁用失败。”
DnsSecOperationFailed消息 (DNSSEC) ：'由于 AdditionalErrorDetails，DNSSEC 启用/禁用失败。 请稍后重试该作。
SMTP DANE) (消息 ：由于 AdditionalErrorDetails，SMTP DANE 启用/禁用失败。 稍后重试该作。
原因：尝试创建正确的 DNS 区域和/或记录失败。
要执行的作 () ：尝试重新运行 cmdlet。DNSSEC
结果 DnssecMxValue ErrorData 错误 ErrorCode： 'DnssecOperationFailed' ErrorDetails 'DNSSEC 启用失败... SMTP DANE
结果 ErrorData 错误 ErrorCode： 'DnssecOperationFailed' ErrorDetails 'SMTP DANE 启用... PartitionNotFoundSMTP DANE) (消息 ：“由于域 contoso.com 没有分区，SMTP DANE 启用/禁用失败。
原因：未为域启用 DNSSEC。
要执行的作 () ：确保使用已启用 DNSSEC 的域。结果 ErrorData 错误 ErrorCode： 'PartitionNotFound' ErrorDetails 'SMTP DANE 启用 DomainNotSupportedDNSSEC) (消息 ：“指定的域是 onmicrosoft 域：contoso-com.onmicrosoft.com”。”
邮件 (SMTP DANE) ：“指定的域是 onmicrosoft 域：contoso-com.onmicrosoft.com”。”
原因：域是初始域或 MOERA 域。 目前不支持这些域。
作 () ：确保使用不以“onmicrosoft.com”结尾的域。DNSSEC
结果 DnssecMxValue ErrorData 错误 ErrorCode： 'DomainNotSupported' ErrorDetails 'The specified domain ... SMTP DANE
结果 ErrorData 错误 ErrorCode： 'DomainNotSupported' ErrorDetails 'The specified domain ...
Get-DnssecStatusForVerifiedDomain 问题
消息：“EG001：无法检索域 [{domain}] 的 DNSSEC 功能状态。”
原因：在 Exchange Online 中验证域的配置时，域未添加到Exchange Online。 如果认为已将此域添加到 Exchange Online，请重试运行 cmdlet，因为此问题可能是暂时的。
要执行的作 () ：重试 cmdlet。 如果继续失败，请转到Microsoft 365 管理中心并完成此域的设置过程。消息：“EG002：域 [{domain}] 未验证组织的域。”
原因：在 Exchange Online 中验证域的配置时，域已添加到Exchange Online但未验证。
要执行的作 () ：转到Microsoft 365 管理中心并完成此域的设置和验证过程。消息：获取 [{domain}] 域的 MX 记录时发生 DNS 查询错误。
原因：在 DNS 验证期间，查询域时发生一般 DNS 故障。
要执行的作 () ：重试运行 cmdlet。 可能需要查看尝试使用 DNSSEC 使用 SMTP DANE 启用的域的配置。消息：“找不到域 [{domain}]。
原因：在 DNS 验证期间，查询域时发生 NXDOMAIN 失败。
要执行的作 () ：在验证域的 MX 记录配置后重试运行 cmdlet。 对于某些 DNS 提供程序，DNS 传播最多可能需要 48 小时。消息：找到“ED003：域 [{domain}]。 找不到真实的 MX 记录。”
原因：在 DNSSEC 验证期间，找不到解析为 DNSSEC 保护的 A 记录的 MX 记录 (MX 记录) 的“主机名”值的 A 记录。
要执行的作 () ：在验证域的 MX 记录配置后重试运行 cmdlet。 对于某些 DNS 提供程序，DNS 传播最多可能需要 48 小时。消息：“EX002：MX 记录的值与预期的值不匹配。
原因：在 MX 验证期间，找不到与预期记录匹配的 MX 记录。
要采取的作 () ：查看域中的 MX 记录。 确保一条 MX 记录与运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain后输出的预期记录匹配。消息：“EX003：MX 记录的优先级与预期的优先级不匹配。
原因：在 MX 验证期间，找到了预期的 MX 记录，但其优先级未设置为 0。
要执行的作 () ：设置 MX 记录 (，其中包含运行Enable-DnssecForVerifiedDomain时返回的值或Get-DnssecStatusForVerifiedDomain) 为优先级 0。消息：“EX004：存在与预期相同首选项的不同 MX 记录。
原因：在 MX 验证期间，优先级最高的 MX 记录不是预期的 MX 记录。
要执行的作 () ：如果已完成 使用 DNSSEC 设置入站 SMTP DANE 的步骤 1 到步骤 4，则通过切换 MX 记录的优先级，使预期的 MX) 为 0 (最高优先级，验证配置，然后删除旧 MX 记录来完成步骤 5 和 6。消息：“EX005：有一条不同于预期的 MX 记录的首选项。
原因：在 MX 验证期间，域的 MX 记录与预期的 MX 记录不匹配。
要执行的作 () ：如果已完成 使用 DNSSEC 设置入站 SMTP DANE 的步骤 1 到 5，则通过删除旧版 MX 记录来完成步骤 6。消息：“EX006：有一条不同于预期的 MX 记录，其首选项高于预期记录。
原因：在 MX 验证期间，其他 MX 记录的首选项高于预期。
要执行的作 () ：将旧版 MX 记录 (以 mail.protection.outlook.com、 mail.eo.outlook.com 或 mail.protection.outlook.de) 结尾设置为优先级 20。消息：“EX007：未找到 MX 记录。
原因：在 MX 验证期间，找不到与预期记录匹配的 MX 记录。
要采取的作 () ：查看域中的 MX 记录。 确保一条 MX 记录与运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain后输出的预期记录匹配。消息：“EX008：找到正确的 MX 记录，但首选项低于预期。
原因：在 MX 验证期间，预期的 MX 记录具有错误的优先级。
作 () ：设置 MX 记录 (，其中包含运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain) 优先级 0 时返回的值。消息：“EX009：找到的正确 MX 记录，但首选项高于预期。
原因：在 MX 验证期间，预期的 MX 记录具有错误的优先级。
作 () ：设置 MX 记录 (，其中包含运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain) 优先级 0 时返回的值。消息：“EX010：搜索域 [{domain}] 的 MX 记录时出现未知错误。”
原因：在 MX 验证期间，发生一般 DNS 错误。
要执行的作 () ：在验证域的 MX 记录配置后重试运行 cmdlet。 对于某些 DNS 提供程序，DNS 传播最多可能需要 48 小时。消息：“EX012：找不到域 [{domain}]的 MX 记录”。
原因：在 MX 验证期间，找不到与预期记录匹配的 MX 记录。
要采取的作 () ：查看域中的 MX 记录。 确保一条 MX 记录与运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain后输出的预期记录匹配。消息：“EX013：域 [{domain}] 的预期 MX 记录未知。
原因：在 MX 验证期间，找不到与预期记录匹配的 MX 记录。
要采取的作 () ：查看域中的 MX 记录。 确保一条 MX 记录与运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain后输出的预期记录匹配。消息：“ES001：模式为”强制“时策略中缺少预期的 MX 记录。
原因：在 MTA-STS 验证期间，找不到与预期记录匹配的 mx 值。
要执行的作 () ：设置要 测试的 MTA-STS 策略模式;然后，添加在 MTA-STS 策略中以行 (运行Enable-DnssecForVerifiedDomain或Get-DnssecStatusForVerifiedDomain) 时返回的 mxhostname 值。消息：'ES002：找不到与策略进行比较的预期 MX 记录。 首先为域 [{domain}] 启用 DNSSEC 功能。
原因：已找到 MTA-STS，但域的 DNSSEC 状态不可检索。
要执行的作 () ：完成 使用 DNSSEC 设置入站 SMTP DANE 中的步骤。
使用 DNSSEC 缓解入站 SMTP DANE 的邮件流问题
启用具有 DNSSEC 的入站 SMTP DANE 后，邮件流问题主要有三种情况：
- SMTP DANE 验证失败的问题：有关如何缓解此问题的信息，请参阅 缓解 SMTP DANE 验证失败。
- DNSSEC 验证失败的问题：有关如何缓解此问题的信息，请参阅 缓解 DNSSEC 验证失败。
- MX 值问题：有关如何缓解此问题的信息，请参阅 使用 MX 值缓解问题。
缓解 SMTP DANE 验证失败
若要减轻 SMTP DANE 验证的影响，请运行以下命令：
Disable-SmtpDaneInbound -DomainName <DomainName>
缓解 DNSSEC 验证失败
若要缓解 DNSSEC 验证失败带来的任何影响，需要通过 DNS 提供程序 (contoso.com) 禁用域上的 DNSSEC。
注意
如果禁用 DNSSEC 无法解决问题，则问题可能出在 MX 值上。
通过 DNS 提供程序在域上禁用 DNSSEC。 然后，向 DNS 提供商开具支持票证，了解如何安全地为域重新启用 DNSSEC。
缓解 MX 值的问题
确保 MX 值与Microsoft 365 管理中心 - 设置 ->> 域中的值匹配。
选择域，选择 “DNS 记录”，然后运行 “检查运行状况”。
确保 MX 记录显示为 正常;如果没有，请将值更新为管理中心中提供的值。
转到 DNS 注册机构并查找域的 MX 记录。 主机名值为：
<MX token>.<subdomain>.mx.microsoft使用以下主机名值创建第二条 MX 记录，并将优先级设置为 20：
<MX token>.mail.protection.outlook.com注意
将“MX 令牌”值替换为在步骤 4 中找到的域的当前 MX 记录中的 MX 令牌。 例如，contosotest.com 的 MX 令牌是 contosotest-com。
请确保在步骤 5 中创建的 MX 记录正常工作。
重要
确保第二条 MX 记录正常工作的一种方法是使用 Microsoft远程连接分析器。
- 输入域 (例如，contoso.com) 进入测试;然后选择“ 执行测试”。
- 打开 “测试步骤”。
- 打开测试“admin@ (域) ”域的入站 SMTP 邮件流的测试步骤。
- 在 “尝试检索域” (域) “的 DNS MX 记录下打开”其他详细信息”。
- 确认 (MX 令牌) .mail.protection.outlook.com MX 记录正常。
如果邮件流适用于 MX token.mail.protection.outlook.com MX 记录，请运行以下命令：
Disable-DnssecForVerifiedDomain -DomainName <DomainName>删除与以下值匹配的 DNSSEC MX 记录：
<MX token>.<subdomain>.mx.microsoft请确保在步骤 5 中创建的 MX 记录是唯一的 MX 记录，并将其设置为优先级 0 (最高优先级) 。
Exchange Online客户如何将出站 SMTP DANE 与 DNSSEC 配合使用？
作为Exchange Online客户，无需执行任何作即可为出站电子邮件配置这种增强的电子邮件安全性。 我们为你构建了这种增强的电子邮件安全性，并且它默认为所有Exchange Online客户启用。 当目标域播发对 DANE 的支持时，Exchange Online使用此安全性。 若要获得使用 DNSSEC 和 DANE 检查发送电子邮件的好处，请与你交换电子邮件的业务合作伙伴沟通，告知他们需要实现 DNSSEC 和 DANE，以便他们能够使用这些标准接收电子邮件。
使用 SMTP DANE 发送电子邮件疑难解答
目前，使用 Exchange Online 发送电子邮件时，DANE 有四个错误代码。 Microsoft正在主动更新此错误代码列表。 可以在以下代码中看到错误：
通过“邮件跟踪详细信息”视图的 Exchange 管理员中心门户。
由于 DANE 或 DNSSEC 故障未发送消息时生成的NDR。
远程连接分析器工具 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 疑难解答
此错误通常表示目标邮件服务器存在问题。 收到消息后：
- 检查是否正确输入了目标电子邮件地址。
- 提醒目标电子邮件管理员你收到了此错误代码，以便他们能够确定目标服务器是否已正确配置为使用 TLS 接收消息。
- 重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
排查 4/5.7.322 证书过期问题
发送电子邮件服务器必须提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订，通常每年续订一次。 收到消息后：
- 提醒目标电子邮件管理员你收到了此错误代码，并提供错误代码字符串。
- 留出时间来续订目标服务器证书，并更新 TLSA 记录以引用新证书。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
排查 4/5.7.323 tlsa 无效问题
此错误代码与 TLSA 记录配置错误相关，只能在返回 DNSSEC 验证 TLSA 记录后生成。 在 DANE 验证期间，许多方案都发生在记录返回后，这可能会导致代码生成。 Microsoft正在积极处理此错误代码涵盖的方案，以便每个方案都有一个特定的代码。 目前，以下一种或多种方案可能会导致生成错误代码：
- 目标邮件服务器的证书与正版 TLSA 记录所需的证书不匹配。
- 正确的 TLSA 记录配置错误。
- 目标域受到攻击。
- 任何其他 DANE 失败。
收到消息后：
- 提醒目标电子邮件管理员你收到了此错误代码，并向他们提供错误代码字符串。
- 允许目标电子邮件管理员有时间查看其 DANE 配置和电子邮件服务器证书的有效性。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
排查 4/5.7.324 dnssec 无效问题
当目标域指示其为 DNSSEC-authentic 但Exchange Online无法将其验证为 DNSSEC-authentic 时，Exchange Online会生成此错误代码。
收到消息后：
- 提醒目标电子邮件管理员你收到了此错误代码，并向他们提供错误代码字符串。
- 让目标电子邮件管理员有时间查看其域的 DNSSEC 配置。 然后，重试发送电子邮件，并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
使用 SMTP DANE 排查接收电子邮件的问题
目前，接收域的管理员可以使用以下两种方法来验证和排查 DNSSEC 和 DANE 配置问题，以接收来自Exchange Online的电子邮件：
- 采用 RFC8460 中引入的 SMTP TLS-RPT (传输层安全报告 )
- 使用远程连接分析器工具 Microsoft远程连接分析器
TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 是一种报告机制，供发件人向目标域管理员提供有关这些目标域的 DANE 和 MTA-STS 成功和失败的详细信息。 若要接收 TLS-RPT 报告，只需在域的 DNS 记录中添加 TXT 记录，其中包含要将报表发送到的电子邮件地址或 URI。 Exchange Online以 JSON 格式发送 TLS-RPT 报告。
下表显示了记录的示例：
| 类型 | 域名 | TTL | 记录 |
|---|---|---|---|
| TXT | _smtp._tls.microsoft.com | 3600 | v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report |
第二种方法是使用远程连接分析器Microsoft远程连接分析器，它可以对 DNS 配置执行与在服务外部发送电子邮件时Exchange Online相同的 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 接收电子邮件进行故障排除。
此错误通常表示目标邮件服务器存在问题。 远程连接分析器测试与邮件服务器的连接。 通常有两种方案生成此代码：
- 目标邮件服务器根本不支持安全通信，必须使用非加密的普通通信。
- 目标服务器配置不正确，忽略 STARTTLS 命令。
收到消息后：
- 检查电子邮件地址。
- 找到与错误语句关联的 IP 地址，以便可以标识与该语句关联的邮件服务器。
- 检查邮件服务器的设置，确保它配置为侦听 SMTP 流量， (通常端口 25 和 587) 。
- 等待几分钟，然后使用远程连接分析器工具重试测试。
- 如果仍然失败，请尝试删除 TLSA 记录并再次使用远程连接分析器工具运行测试。
- 如果没有失败，则此消息可能指示用于接收邮件的邮件服务器不支持 STARTTLS。 可能需要升级到支持 STARTTLS 才能使用 DANE 的一个。
排查 4/5.7.322 证书过期问题
注意
这些步骤适用于电子邮件管理员使用 SMTP DANE 对从 Exchange Online 接收电子邮件进行故障排除。
发送电子邮件服务器必须提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订，通常每年续订一次。 收到消息后：
- 检查与错误语句关联的 IP 地址，以便可以标识它关联的邮件服务器。 在标识的电子邮件服务器上找到过期的证书。
- 登录到证书提供程序的网站。
- 选择过期的证书，并按照说明续订并支付续订费用。
- 提供商验证购买后，请下载新证书。
- 将续订的证书安装到其关联的邮件服务器。
- 使用新证书的数据更新邮件服务器的关联 TLSA 记录。
- 等待适当时间后，请使用远程连接分析器工具重试测试。
排查 4/5.7.323 tlsa 无效问题
注意
这些步骤适用于电子邮件管理员使用 SMTP DANE 对从 Exchange Online 接收电子邮件进行故障排除。
此错误代码与 TLSA 记录配置错误相关。 只有在返回 DNSSEC 验证 TLSA 记录后，才能生成错误代码。 但是，在 DANE 验证期间，许多方案在返回记录后发生，这可能会导致代码生成。 Microsoft正在积极处理此错误代码涵盖的方案，以便每个方案都有一个特定的代码。 目前，以下一种或多种方案可能会导致生成错误代码：
- 错误配置了身份验证 TLSA 记录。
- 证书尚未生效，或已针对将来的时间窗口进行配置。
- 目标域受到攻击。
- 任何其他 DANE 失败。
收到消息后：
- 检查与错误语句关联的 IP 地址，以标识邮件服务器。
- 标识与邮件服务器关联的 TLSA 记录。
- 验证 TLSA 记录的配置，确保它向发送方发出信号以执行首选 DANE 检查，并确保 TLSA 记录中包含正确的证书数据。
- 如果需要更新记录是否存在差异，请等待几分钟，然后使用远程连接分析器工具重新运行测试。
- 在邮件服务器上找到证书。
- 检查证书有效的时间范围。 如果设置为在未来日期开始有效，则需要在当前日期续订它。
- 登录到证书提供程序的网站。
- 选择过期的证书，并按照说明续订并支付续订费用。
- 提供商验证购买后，可以下载新证书。
- 将续订的证书安装到其关联的邮件服务器。
排查 4/5.7.324 dnssec 无效问题
注意
这些步骤适用于电子邮件管理员使用 SMTP DANE 对从 Exchange Online 接收电子邮件进行故障排除。
当目标域指示其 DNSSEC 验证，但Exchange Online无法将其验证为 DNSSEC-authentic 时，Exchange Online会生成此错误代码。 本部分对排查 DNSSEC 问题并不全面，重点介绍域以前通过 DNSSEC 身份验证但现在未通过的方案。
注意
如果Exchange Online从针对目标域的 TLSA 查询上的 DNS 服务器收到 SERVFAIL 响应，也会生成此错误代码。
收到消息后：
- 如果使用 DNS 提供程序（如 GoDaddy），请向 DNS 提供程序发出错误警报，以便他们能够进行故障排除和配置更改。
- 如果要管理自己的 DNSSEC 基础结构，许多 DNSSEC 错误配置可能会生成此错误消息。 如果区域以前通过 DNSSEC 身份验证，请检查以下常见问题：
- 当父区域包含一组指向子区域中不存在的内容的 DS 记录时，信任链断开。 DS 记录的此类指针可能会导致子区域通过验证解析程序被标记为虚假。
- 通过查看子域的 RRSIG 密钥 ID 并确保它们与父区域中发布的 DS 记录中的密钥 ID 匹配来解决。
- 域的 RRSIG 资源记录无效，已过期，或者其有效期尚未开始。
- 通过使用有效的时间跨度为域生成新签名来解决。
- 当父区域包含一组指向子区域中不存在的内容的 DS 记录时，信任链断开。 DS 记录的此类指针可能会导致子区域通过验证解析程序被标记为虚假。
发送出站电子邮件时，如果接收域已启用 DNSSEC，Exchange Online查询与域中 MX 条目关联的 TLSA 记录。 如果未发布 TLSA 记录，则 TLSA 查找的响应必须为 NOERROR (此域) 或 NXDOMAIN 请求类型的记录， (没有此类域) 。 如果未发布 TLSA 记录，DNSSEC 需要此响应;否则，Exchange Online将缺少响应解释为 SERVFAIL 错误。 根据 RFC 7672，SERVFAIL 响应是不可信的;因此，目标域未通过 DNSSEC 验证。 Exchange Online延迟此电子邮件并出现以下错误：
450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records
如果电子邮件发件人报告邮件的回执
如果使用 DNS 提供程序（如 GoDaddy），请向 DNS 提供程序发出错误警报，以便他们能够对 DNS 响应进行故障排除。 如果要管理自己的 DNSSEC 基础结构，则问题可能出在 DNS 服务器本身或网络上。
常见问题
作为Exchange Online客户，我是否可以选择不使用 DNSSEC 和 DANE？
我们坚信 DNSSEC 和 DANE 可显著提高我们服务的安全性，并使所有客户受益。 在过去的一年里，我们努力降低此部署对 365 Microsoft客户的潜在影响的风险和严重性。 我们会积极监视和跟踪部署，以确保在部署时将负面影响降到最低。因此，租户级异常或选择退出不可用。 如果遇到与启用 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 攻击和降级攻击。