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.
Record Type
TLSA
Category
Security
Security
RFC
RFC 6698 / RFC 7671
RFC 6698 / RFC 7671
Email Relevant
Yes
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
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.