TLSA record
A DNS record that pins a TLS certificate to a hostname via DANE. Lets clients verify the cert via DNSSEC instead of the public CA system.
TLSA records publish information about a TLS certificate inside DNS, so a client can verify the cert by checking DNS instead of the public CA system. This pattern is called DANE (DNS-Based Authentication of Named Entities), defined in RFC 6698.
_443._tcp.example.com. TLSA 3 1 1 ABCDEF...
The four fields:
- Usage (3) — what the record describes. 3 = "Domain-issued certificate, full chain." Most common.
- Selector (1) — what hash is over. 1 = public key.
- Matching type (1) — hash function. 1 = SHA-256.
- The hash value.
Why DANE / TLSA exists
The public CA system has known failure modes: any of ~100 trusted CAs could issue a cert for your domain. DANE lets you declare "the cert at port 443 should match this specific key, and no other," published in DNS and protected by DNSSEC.
Where it's actually used
Email servers, mostly. SMTP MTAs check TLSA records for opportunistic TLS verification. Major mail providers (Google Mail, ProtonMail) honor them.
For web (HTTPS), DANE is supported by approximately zero major browsers. Chrome removed support in 2011 and hasn't added it back. Firefox never had it. So TLSA records on web hostnames are decoration.
Why most SaaS don't have one
Requires DNSSEC (high effort, low adoption). Only helps SMTP (modest benefit unless you operate mail at scale). Browsers ignore it. For SaaS custom domains, this is in the "things to know exist but not implement" bucket.