TLSA Record (TLSA resource record)

A TLSA record lives at a name built from the port and transport protocol, such as _25._tcp.mail.example.com or _443._tcp.example.com, and has four fields. Certificate usage: 0 (PKIX-TA) and 1 (PKIX-EE) add constraints on top of normal CA validation, 2 (DANE-TA) names a trust anchor, and 3 (DANE-EE) matches the server's own certificate or key without any CA check. Selector: 0 for the full certificate, 1 for the SubjectPublicKeyInfo. Matching type: 0 for exact data, 1 for SHA-256, 2 for SHA-512. The last field is the association data itself. TLSA only has meaning when signed with DNSSEC, as part of DANE.

Why it matters

The parameters decide how painful certificate renewal will be. The widely recommended 3 1 1 (DANE-EE, public key, SHA-256) matches only the key, so renewing a certificate with the same key needs no DNS change. If your ACME client generates a new key on every renewal, as certbot does by default unless --reuse-key is set, the record must be updated first, or validating senders will refuse to deliver mail. The safe rollover is to publish the new key's hash alongside the old one, wait for DNS caches to expire, and only then switch keys.

Example

# selector 1 + matching type 1: SHA-256 of the public key
openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 | awk '{print $2}'

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 <64 hex characters from the command above>

The TLSA generator builds the record from a certificate.

Common misconceptions

• The TLSA record must change at every renewal. With selector 1 and an unchanged key, it does not.
• TLSA records work without DNSSEC. Validating clients ignore TLSA data that is not DNSSEC-signed.
• One TLSA record covers the whole domain. The owner name includes port and protocol, so each service, and each MX host, needs its own record.