DANE: pins a service’s TLS certificate in DNSSEC-signed DNS.
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
- IANA: Resource Record (RR) TYPEs registry · checked 5 Oct 2026
- RFC 6698 · checked 5 Oct 2026