DANE/TLSA 记录检测工具
向多个公共 DNS 解析器查询域名邮件服务器（MX 主机）发布的 TLSA 记录，检测是否已配置 DANE 证书锁定。
使用提示
- TLSA 记录并不位于普通域名下，而是位于特殊名称 `_25._tcp.{MX 主机名}` 下，这就是为什么直接查询域名本身找不到 TLSA 记录的原因。
- 「未配置 DANE」并非异常。DANE 是邮件加密的额外防护层，目前大多数邮件服务器仍未启用。
- DANE 的可信度依赖于该域名的 TLSA 记录本身受到 DNSSEC 签名链的保护。即使找到了 TLSA 记录，也建议配合姊妹工具「DNSSEC 验证检测工具」确认该域名是否已启用 DNSSEC。
- 如果存在多个 MX 主机，本工具会按优先级（数值越小优先级越高）检测最多 3 个主机。
- 如果各解析器结果不一致，可能是记录刚刚更新、缓存尚未统一所致。请稍后重新检测。
常见问题
「未配置 DANE」本身并不危险，目前绝大多数邮件服务器仍在没有 DANE 的情况下运行。不过，若条件允许，作为防范 STARTTLS 中间人攻击的措施，值得考虑启用。
两者的目标都是强制邮件传输使用 TLS 加密，但信任基础不同：MTA-STS 依赖证书颁发机构（CA）的验证链，DANE 依赖 DNSSEC 签名链。如果已经启用了 DNSSEC，DANE 是自然的选择；否则先部署 MTA-STS 更为现实。两者也可以同时使用。
Usage 指定验证方式（是否仍需 CA 验证，或直接锁定证书本身），Selector 指定对完整证书还是仅公钥部分进行哈希，Matching Type 指定哈希算法（如 SHA-256、SHA-512）。不同组合适用于不同的运维模式。
为确保完整保护，建议所有可能被选为投递目标的 MX 主机都配置 TLSA 记录。若只有部分主机配置了记录，投递到未配置主机的邮件将得不到保护。
本工具仅确认 TLSA 记录是否已发布这一表层状态，不会验证证书关联数据是否与服务器实际证书一致。如需严格验证，请配合专业工具使用。
闲话 ― 用「证书」而非仅靠「不被窃听」来保护邮件加密
SMTP（邮件传输协议）的加密方式 STARTTLS 长期存在一个弱点：多数邮件服务器采用「机会性加密」（Opportunistic TLS），即对方不支持加密时便退回明文传输，这为「STRIPTLS 攻击」打开了大门——中间人攻击者可以悄悄剥除 STARTTLS 指令，使连接在双方都未察觉的情况下降级为明文。
DANE（基于 DNS 的命名实体认证，RFC 6698）通过在 DNS 中发布 TLSA 记录来应对这一问题。预先将邮件服务器的证书（或其公钥哈希）锁定在 DNS 中，发送方服务器便可验证所连接的主机是否确实提供了预期的证书。与普通 SSL/TLS 证书验证不同，DANE 完全不依赖证书颁发机构（CA）的信任链，只信任 DNSSEC 签名链。
DANE 的弱点在于，只有当域名本身经过 DNSSEC 签名时才能生效。若未启用 DNSSEC，则无法排除 TLSA 记录本身在传输过程中被篡改的可能，DANE 的保证也就失去意义。因此 DANE 的普及程度与 DNSSEC 的普及程度密切相关，欧洲部分注册局（如 .nl、.cz）已率先推广采用。