A TLSA 记录 将TLS服务与证书或公钥数据相关联。它不是一个 TXT记录，替代 MX记录 或每个发件人使用的证据 DANE。对于SMTP ，相关的发现和强制行为由RFC 7672定义。
以MX服务主机名开头
参考： RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
对于 TCP 端口 25 上的服务 mx.example.com，传统的 TLSA 所有者是 _25._tcp.mx.example.com。从实际SMTP交换主机名派生名称，而不是自动从可见的发件人域或区域顶点派生。检查部署打算保护的每个MX端点以及 DNSSEC 沿发现路径的状态。
TLSA 数据字段是证书使用情况， 选择器，匹配类型和关联数据。对于这个简单的非别名路由，显示的所有者就足够了；别名需要RFC 7672 §2.2 中经过身份验证的 TLSA 基域处理。通常推荐的SMTP DANE配置文件是 3 1 1：DANE-EE 使用、SubjectPublicKeyInfo 选择和 SHA-256 匹配。这些数字是有意义的协议选择，而不是任意证书文本的通用前缀。 RFC 7672和RFC 7671描述了支持的用法和操作注意事项；将不受支持的组合排除在部署方案之外。
导出确切的字节
参考： RFC 6698 §2.1.2, RFC 6698 §2.1.3.
对于本地 PEM 证书文件 证书.pem，在 Bash shell 中首先启用 设置-o管道故障;然后是一个可重复的 SPKI 摘要管道 openssl x509 -in cert.pem -pubkey -noout | openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256。要求每个阶段都取得成功。当选择选择器 1 时，对 DER 公钥表示进行哈希处理，而不是对 PEM 文本、显示的指纹或整个证书进行哈希处理。
构造 _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST，用实际摘要替换 HEXDIGEST。这是一个模板，而不是可发布的记录。通过受控的方式获取预期SMTP端点提供的证书 STARTTLS 检查并比较其选定的字节。本地文件可能与服务器实际提供的证书不同。
在旧关联退役之前测试关键更改
参考： RFC 7672 §4, RFC 7671 §8.
合成装置 A 使用带有密钥 A 的测试证书和从 A 派生的 TLSA 关联。预期的字节比较是匹配的。夹具 B 使用密钥 B 提供证书，同时仅保留 A 的关联；预期的比较是不匹配的。夹具 C 为计划的转换发布可接受的关联，并在淘汰 A 之前根据 B 验证预期端点。
计时必须考虑缓存的 TLSA 数据和所有活动服务器实例。使用相同公钥更新的证书可以保持相同 3 1 1 关联，而新的密钥会改变它。成功的摘要比较是本地加密检查，而不是SMTP DANE互操作性结果。实时DNSSEC和SMTP测试仍然是单独的证据要求。
验证传输而不是仪表板标签
参考： RFC 7672 §2.2, RFC 7672 §3.
使用 DNSSEC 验证路径建立可用的 TLSA 数据，然后测试实际的SMTP握手以及与支持 DANE 的实施的关联。保留DNS答案、验证跟踪、证书链、选定的关联和发件人的结果。支持的发件人不应默默地将失败的所需DANE身份验证视为成功的安全传递。不要声称通用传输保护：发件人支持和准确的经过身份验证的发现结果很重要。
观察关联和发现检查
参考： RFC 4035 §5.
保留的 2026 年 11 月 7 日签署的固定装置经过检查但未重新运行以进行本次审查，它通过固定的父级、经过身份验证的 DS 和子级 DNSKEY 来验证 TLSA RRset。单独的环回TLS服务实际上提供了测试证书 A，然后提供了 B。从每个收到的握手证书中提取 SPKI 会产生 A 与 A 的匹配、B 与 A 单独不匹配、A/B 重叠期间 B 匹配以及 A 退出后 B 匹配。记录记录时间戳、环回端点、 TLS协议和摘要。这验证了单独的加密成分；该服务是普通TLS ，而不是SMTP STARTTLS ，并且没有声称集成DANE邮件客户端或实时DNS解析器测试。