基于 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 并将其发送给发送方。
TLS 身份验证 (TLSA) 记录用于将服务器的 X.509 证书或公钥值与包含该记录的域名相关联。 只有在域上启用了 DNSSEC 时,才能信任 TLSA 记录。 如果使用 DNS 提供程序托管域,则 DNSSEC 可能是配置域时提供的设置。 若要详细了解 DNSSEC 区域签名,请访问此链接:DNSSEC 概述 |Microsoft Docs。
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 哈希。
根据 SMTP DANE 的 RFC 实现指南,建议使用由“证书使用情况”字段设置为 3、“选择器”字段设置为 1、“匹配类型”字段设置为 1 组成的 TLSA 记录。
使用 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 验证电子邮件,设置步骤 |
在开始之前,请确保满足以下先决条件:
- 必须在Microsoft 365 管理中心将域添加为“接受域”,并且域状态必须为“正常”。 文档假定域的 MX 记录设置为优先级 0 或 10,并且没有“回退”或辅助 MX 记录。 如果有回退 MX 记录,则需要与Exchange Online管理员密切合作,以确保正确执行更改。
- 若要获得该功能的全部安全优势,请确保已为域启用 DNSSEC。
- 必须有权访问Exchange Online PowerShell,并有权运行 Exchange Online PowerShell 中所述的 cmdlet
- 如果要在任何 smarthost 配置或任何连接器中引用使用 DNSSEC 入站 SMTP DANE 保护的域,则需要在执行步骤之前将 smarthost 名称切换为
tenantname.mail.protection.outlook.com
。
备注
如果要为使用第三方网关的域启用 DNSSEC,可以按照步骤 1 到步骤 3(在第三方网关上步骤 3 末尾的注释)执行此操作。
警告
如果要为“接受域 contoso.com
”配置具有 DNSSEC 的入站 SMTP DANE,而业务合作伙伴正在使用终结点的连接器 contoso-com.mail.protection.outlook.com
,则需要与合作伙伴合作,以便他们更新其连接器以引用 tenantname.onmicrosoft.com
终结点或 tenantname.mail.protection.outlook.com
终结点,然后再使用 DNSSEC 配置入站 SMTP DANE。 否则,在完成启用后,业务合作伙伴的连接器邮件将失败。 完成启用后,合作伙伴可以使用新 contoso-com.<random>.mx.microsoft
终结点重新建立原始连接器。
备注
DNS 记录预配和更新可能需要一些时间才能完成。 由于多层缓存,DNS 更改可能需要比预期更长的时间才能可见。
若要使用 DNSSEC 设置入站 SMTP DANE,请执行以下步骤:
将现有 MX 记录的 TTL 更新为尽可能低的 TTL (但不低于 30 秒) 。 然后,等待上一个 TTL 过期,然后再继续操作。 例如,如果现有 MX 记录的 TTL 在更改前为“3600 秒”或“1 小时”,则需要等待 1 小时才能继续执行步骤 2。
连接到 Exchange Online PowerShell。
警告
如果使用 MTA-STS,则需要将策略模式设置为“测试”,并更新 MTA-STS txt 记录中的 ID。 (可以使用 UTC 中的当前时间作为新策略 ID.) 然后等待策略的“max_age”过期,然后继续操作。 例如,如果现有 STS 策略的“max_age”是在更改策略前 3600 秒 或 1 小时 ,则需要等待“1 小时”才能继续操作。
对于要使用 DNSSEC 启用 SMTP DANE 的域,需要首先通过运行以下命令在域上启用 DNSSEC, (将“域”替换为所选域的名称,例如,contosotest.com) :
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 更新为 3600 秒。 (可选)可以使用 DNSSEC 测试 (确保你在测试输入期间选择“DNSSEC 验证”,而不是在 远程连接分析器中选择“DANE 验证 [包括 DNSSEC]) ”来确认一切按预期工作。 可能需要重试此测试,具体取决于 DNS 缓存和 TTL。
旧版 MX 记录上的 TTL 过期后,成功的输出将如下所示:
如果要在 DNSSEC 启用完成后为同一域启用 SMTP DANE,请运行以下命令 [将 (DomainName) 替换为所选域的名称,例如,contosotest.com] :
Enable-SmtpDaneInbound -DomainName <DomainName>
结果 ErrorData 成功 通过使用所选的在线工具和 Microsoft 远程连接分析器:测试输入,验证 TLSA 记录是否已传播 (可能需要 15-30 分钟) 。
完成 DNSSEC 启用并Exchange Online预配了 SMTP DANE 记录 (TLSA) 后,将显示成功的输出,如以下屏幕截图所示:
Exchange Online托管多个 TLSA 记录,以提高 SMTP DANE 验证成功的可靠性。 预计某些 TLSA 记录可能无法通过验证。 只要有 1 条 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) 只能使用此功能保护从第三方网关中继到Exchange Online如果第三方网关支持具有 DNSSEC 验证的 SMTP DANE 的电子邮件。 此配置中的客户需要使用 Exchange PowerShell 通过 DNSSEC 设置入站 SMTP DANE。
- 与邮件流的其他第三方集成:出站路径上有第三方网关的客户,其中电子邮件通过连接器发送给第三方,第三方执行一些处理,然后重新提交到Exchange Online,然后Exchange Online最终发送电子邮件。 这些客户在启用该功能时可能需要与第三方提供商合作,以免中断。 将电子邮件提交回Exchange Online时,第三方中继需要使用 DNS 查找,并使用在启用功能期间创建的新 MX 记录主机名 -> contoso-com. (子域) .mx.microsoft。 第三方不应使用旧的 MX 记录主机名 -> contoso-com.mail.protection.outlook.com,因为Exchange Online会在启用功能后大约 2 天内 (48) 小时内删除 A 记录,一旦我们达到 GA。
- 完全委托的域:DNSSEC 入站 SMTP DANE 支持由 Microsoft 托管并使用 NS 委派的域,以便Microsoft的名称服务器对域具有权威性。 我们打算为这些域使用 DNSSEC 支持入站 SMTP DANE;但是,ETA 未知。
DomainNotFound
DNSSEC) (消息 :“由于 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 启用... PartitionNotFound
SMTP DANE) (消息 :“由于域 contoso.com 没有分区,SMTP DANE 启用/禁用失败。
原因:未为域启用 DNSSEC。
要执行的操作 () :确保使用已启用 DNSSEC 的域。结果 ErrorData 错误 ErrorCode: 'PartitionNotFound' ErrorDetails 'SMTP DANE 启用 DomainNotSupported
DNSSEC) (消息 :“指定的域是 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 ...
消息:“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 后,邮件流问题主要有 3 种情况:
- SMTP DANE 验证失败的问题:有关如何缓解此问题的信息, 请缓解 SMTP DANE 验证失败。
- DNSSEC 验证失败的问题:有关如何缓解此问题的信息,请参阅 缓解 DNSSEC 验证失败。
- MX 值问题:有关如何缓解此问题的信息,请参阅 使用 MX 值缓解问题。
若要减轻 SMTP DANE 验证的影响,请运行以下命令:
Disable-SmtpDaneInbound -DomainName <DomainName>
若要缓解 DNSSEC 验证失败带来的任何影响,需要通过 DNS 提供程序 (contoso.com) 禁用域上的 DNSSEC。
备注
如果禁用 DNSSEC 无法解决问题,则可能是 MX 值出现问题。
通过 DNS 提供程序在域上禁用 DNSSEC 后,向 DNS 提供商开具支持票证,以确定如何安全地为域重新启用 DNSSEC。
确保 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客户,无需执行任何操作即可为出站电子邮件配置此增强的电子邮件安全性。 此增强的电子邮件安全性是我们为你构建的,它默认为所有Exchange Online客户启用,并在目标域播发对 DANE 的支持时使用。 若要获得使用 DNSSEC 和 DANE 检查发送电子邮件的好处,请与你交换电子邮件的业务合作伙伴沟通,告知他们需要实现 DNSSEC 和 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 问题。
此错误通常表示目标邮件服务器存在问题。 收到消息后:
- 检查是否已正确输入目标电子邮件地址。
- 提醒目标电子邮件管理员你收到了此错误代码,以便他们能够确定目标服务器是否已正确配置为使用 TLS 接收消息。
- 重试发送电子邮件,并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
必须向发送电子邮件服务器提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订,通常每年续订一次。 收到消息后:
- 提醒目标电子邮件管理员你收到了此错误代码,并提供错误代码字符串。
- 留出时间来续订目标服务器证书,并更新 TLSA 记录以引用新证书。 然后,重试发送电子邮件,并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
此错误代码与 TLSA 记录配置错误相关,只能在返回 DNSSEC 验证 TLSA 记录后生成。 在 DANE 验证期间,有许多方案在返回记录后发生,这可能会导致生成代码。 Microsoft正在积极处理此错误代码所涵盖的方案,以便每个方案都有一个特定的代码。 目前,以下一种或多种方案可能会导致生成错误代码:
- 目标邮件服务器的证书与每个身份验证 TLSA 记录的预期证书不匹配。
- 错误配置了身份验证 TLSA 记录。
- 目标域受到攻击。
- 任何其他 DANE 失败。
收到消息后:
- 提醒目标电子邮件管理员你收到了此错误代码,并向他们提供错误代码字符串。
- 允许目标电子邮件管理员有时间查看其 DANE 配置和电子邮件服务器证书的有效性。 然后,重试发送电子邮件,并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
当目标域指示其为 DNSSEC 身份验证,但Exchange Online无法将其验证为 DNSSEC-authentic 时,将生成此错误代码。
收到消息后:
- 提醒目标电子邮件管理员你收到了此错误代码,并向他们提供错误代码字符串。
- 让目标电子邮件管理员有时间查看其域的 DNSSEC 配置。 然后,重试发送电子邮件,并在 Exchange 管理员中心门户中查看邮件的邮件跟踪详细信息。
目前,接收域的管理员可以使用以下两种方法来验证和排查 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 配置执行相同的 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 问题。
备注
这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。
此错误通常表示目标邮件服务器存在问题。 远程连接分析器正在测试连接的邮件服务器。 通常有两种生成此代码的方案:
- 目标邮件服务器根本不支持安全通信,必须使用非加密的普通通信。
- 目标服务器配置不正确,忽略 STARTTLS 命令。
收到消息后:
- 检查电子邮件地址。
- 找到与错误语句关联的 IP 地址,以便可以标识与该语句关联的邮件服务器。
- 检查邮件服务器的设置,确保它配置为侦听 SMTP 流量, (通常端口 25 和 587) 。
- 等待几分钟,然后使用远程连接分析器工具重试测试。
- 如果仍然失败,请尝试删除 TLSA 记录,并再次使用远程连接分析器工具运行测试。
- 如果没有失败,则此消息可能指示用于接收邮件的邮件服务器不支持 STARTTLS,并且可能需要升级到一个支持 STARTTLS 的邮件服务器才能使用 DANE。
备注
这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。
必须向发送电子邮件服务器提供未过期的有效 X.509 证书。 X.509 证书必须在过期后续订,通常每年续订一次。 收到消息后:
- 检查与错误语句关联的 IP,以便可以标识它关联的邮件服务器。 在标识的电子邮件服务器上找到过期的证书。
- 登录到证书提供程序的网站。
- 选择过期的证书,并按照说明续订并支付续订费用。
- 提供商验证购买后,可以下载新证书。
- 将续订的证书安装到其关联的邮件服务器。
- 使用新证书的数据更新邮件服务器的关联 TLSA 记录。
- 等待适当时间后,请使用远程连接分析器工具重试测试。
备注
这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。
此错误代码与 TLSA 记录配置错误相关,只能在返回 DNSSEC 验证的 TSLA 记录后生成。 但是,在 DANE 验证期间,有许多方案在返回记录后发生,这可能会导致生成代码。 Microsoft正在积极处理此错误代码所涵盖的方案,以便每个方案都有一个特定的代码。 目前,以下一种或多种方案可能会导致生成错误代码:
- 错误配置了身份验证 TLSA 记录。
- 证书尚未在将来的时间范围内有效/配置。
- 目标域受到攻击。
- 任何其他 DANE 失败。
收到消息后:
- 检查与错误语句关联的 IP,以标识它关联的邮件服务器。
- 标识与标识的邮件服务器关联的 TLSA 记录。
- 验证 TLSA 记录的配置,确保它向发送方发出信号以执行首选 DANE 检查,并且 TLSA 记录中包含正确的证书数据。
- 如果必须对记录进行任何差异更新,请等待几分钟,然后使用远程连接分析器工具重新运行测试。
- 在标识的邮件服务器上找到证书。
- 检查证书有效的时间范围。 如果设置为在未来日期开始有效,则需要在当前日期续订它。
- 登录到证书提供程序的网站。
- 选择过期的证书,并按照说明续订并支付续订费用。
- 提供商验证购买后,可以下载新证书。
- 将续订的证书安装到其关联的邮件服务器。
备注
这些步骤适用于电子邮件管理员对使用 SMTP DANE 从Exchange Online接收电子邮件进行故障排除。
当目标域指示其为 DNSSEC-authentic,但Exchange Online无法将其验证为 DNSSEC-authentic 时,将生成此错误代码。 本部分不会全面解决 DNSSEC 问题,重点介绍域以前通过 DNSSEC 身份验证但现在未通过的方案。
备注
如果Exchange Online从 DNS 服务器接收来自目标域的 TLSA 查询的 SERVFAIL 响应,也会生成此错误代码。
收到消息后:
- 如果使用 DNS 提供程序(例如 GoDaddy),请向 DNS 提供程序发出错误警报,以便他们能够进行故障排除和配置更改。
- 如果要管理自己的 DNSSEC 基础结构,则有许多 DNSSEC 错误配置可能会生成此错误消息。 如果区域以前通过 DNSSEC 身份验证,检查一些常见问题:
- 当父区域包含一组指向子区域中不存在的内容的 DS 记录时,信任链断开。 DS 记录的此类指针可能会导致子区域通过验证解析程序被标记为虚假。
- 通过查看子域 RRSIG 密钥 ID 并确保它们与父区域中发布的 DS 记录中的密钥 ID 匹配来解决。
- 域的 RRSIG 资源记录无效,已过期,或者其有效期尚未开始。
- 通过使用有效的时间跨度为域生成新签名来解决。
- 当父区域包含一组指向子区域中不存在的内容的 DS 记录时,信任链断开。 DS 记录的此类指针可能会导致子区域通过验证解析程序被标记为虚假。
发送出站电子邮件时,如果接收域已启用 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 服务器本身或网络出现问题。
我们坚信 DNSSEC 和 DANE 将显著提升我们服务的安全地位,并使所有客户受益。 在过去的一年里,我们一直努力降低此部署对 365 Microsoft客户的潜在影响的风险和严重性。 我们将积极监视和跟踪部署,以确保在部署推出时将负面影响降到最低。因此,租户级异常或选择退出将不可用。 如果遇到与启用 DNSSEC 和/或 DANE 相关的任何问题,则本文档中介绍的用于调查失败的不同方法将帮助你确定错误的来源。 在大多数情况下,问题出在外部目标方,你需要告知这些业务合作伙伴需要正确配置 DNSSEC 和 DANE 才能使用这些标准接收来自Exchange Online的电子邮件。
DNSSEC 通过应用公钥基础结构向 DNS 解析添加信任层,以确保响应 DNS 查询时返回的记录是真实的。 DANE 确保接收邮件服务器是真实 MX 记录的合法和预期的邮件服务器。
DANE 和 MTA-STS 用途相同,但 DANE 需要 DNSSEC 进行 DNS 身份验证,而 MTA-STS 依赖于证书颁发机构。
如果两个终结点都同意支持,则机会性 TLS 将加密两个终结点之间的通信。 但是,即使 TLS 对传输进行加密,也可能在 DNS 解析过程中欺骗域,使其指向恶意参与者的终结点,而不是域的真实终结点。 此欺骗是电子邮件安全性中的一个差距,可通过使用 DNSSEC 实现 MTA-STS 和/或 SMTP DANE 来解决。
对于邮件流方案,DNSSEC 无法完全抵御中间人攻击并将 (从 TLS 降级为明文) 攻击。 添加 MTA-STS 和 DANE 以及 DNSSEC 提供了一种全面的安全方法来挫败 MITM 攻击和降级攻击。
使用 DMARC 验证电子邮件、设置步骤 - Office 365 |Microsoft Docs
如何在自定义域中对电子邮件使用 DKIM - Office 365 |Microsoft Docs
发件人策略框架 (SPF) 如何防止欺骗 - Office 365 |Microsoft Docs
Microsoft Ignite 2020 Exchange Online交通新闻 - Microsoft Tech Community