TLSA · type 52

DANE: pins a service’s TLS certificate in DNSSEC-signed DNS.

Short answer

A TLSA record at _port._protocol.<host> publishes which certificate or key a TLS service should present. It only means something in a DNSSEC-signed zone, because the signature is what makes it trustworthy.

Type
TLSA
Code
52
Defined in
RFC 6698
IANA description
TLSA
Field: Usage
e.g. 3 = the server’s own key
Field: Selector
1 = public key
Field: Matching type
1 = SHA-256
Field: Data
Hash

How it works

Its main use today is mail: SMTP DANE (RFC 7672) lets sending servers require TLS to your MX and verify it against the TLSA record, as an alternative or complement to MTA-STS.

Example

_25._tcp.mail.example.com.  3600  IN  TLSA  3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B5…

Example uses reserved documentation names and addresses (RFC 2606, RFC 5737, RFC 3849).

Common mistakes

  • Renewing a certificate with a new key without publishing the new TLSA first, which breaks DANE-verified delivery.

How to check yours

TLSA only works when the zone is signed and the parent publishes a DS record, so check DNSSEC first. A sending server that supports DANE and finds a TLSA record that doesn’t match your certificate must not deliver, which is stronger than MTA-STS but also less forgiving of mistakes during certificate renewals.

For email

SMTP DANE for your MX hosts.

Related record types

Sources

Sources

  1. IANA: Resource Record (RR) TYPEs registry · checked 5 Oct 2026
  2. RFC 6698 · checked 5 Oct 2026