What is a TLSA record?

`TLSA` TLS Authentication (DANE)

TLSA records enable DANE, pinning the TLS certificate of your mail server directly in DNS. Learn how it works and why DNSSEC is required.

Published May 10, 2026 · Last verified August 7, 2026 · Maintained by TamingDNS

Record Type
TLSA

Category
Security

RFC
RFC 6698 / RFC 7671

Email Relevant
Yes

Format
TLSA <usage> <selector> <matching-type> <certificate-data>

Example
TLSA 3 1 1 <sha256-of-public-key>

TTL Guidance
3600-86400 s; lower (300 s) before rotating certificates

💬 What This Record Does

TLSA records are part of DANE (DNS-based Authentication of Named Entities). They allow you to publish the fingerprint or public key of your mail server's TLS certificate directly in DNS, so sending servers can verify the certificate without relying solely on the public CA system. For SMTP, TLSA records are published at _25._tcp.<mx-hostname> and tell connecting servers which certificate to expect. DANE requires DNSSEC; without it, the TLSA record itself could be forged.

Common Uses

Pinning your mail server's TLS certificate for SMTP connections (DANE-SMTP)
Providing defence in depth alongside MTA-STS for inbound TLS enforcement
Meeting high-assurance email security requirements

⚠️ Watch Out For

TLSA records are completely useless without DNSSEC. An attacker could forge them without DNSSEC signatures.
When you renew or rotate your TLS certificate, you must update the TLSA record before the old certificate expires.
DANE-SMTP support varies. Postfix, Exim, and many MTAs support it, but not all do.

📋 Complete Example Records

Whole records in zone-file form: name, TTL, class, type, then the data. Most DNS panels ask for the pieces separately. Look them up live with the DNS Lookup tool.

_25._tcp.mail.ietf.org.  3600  IN  TLSA  3 1 1 38A88126A15AE8E643CE9447C3CE9A874EA0E05255D07EE12227809EDBE5C7F1

DANE-EE, SubjectPublicKeyInfo, SHA-256, the combination RFC 7672 §3.1 recommends for SMTP. This is ietf.org's own live record; your digest comes from your own certificate and will differ.

_25._tcp.mail.example.com.  3600  IN  TLSA  2 0 1 0000000000000000000000000000000000000000000000000000000000000000

DANE-TA(2), Cert(0), SHA2-256(1), which RFC 7672 §3.1 gives as the second choice. It pins the issuing authority's whole certificate rather than the server's public key.

_25._tcp.mail.example.com.  3600  IN  TLSA  3 1 1 1111111111111111111111111111111111111111111111111111111111111111
_25._tcp.mail.example.com.  3600  IN  TLSA  3 1 1 2222222222222222222222222222222222222222222222222222222222222222

Both keys published during a rollover. Add the incoming one alongside the current one, wait out the TTL, then swap the certificate and drop the old record.

_25._tcp.mail.example.com.  3600  IN  TLSA  1 1 1 3333333333333333333333333333333333333333333333333333333333333333

Usage 1, which RFC 7672 §3.1.3 says SHOULD NOT be published for port 25. The PKIX usages do not fit opportunistic DANE, and client treatment of them is undefined.