Cybersecurity glossary
What is a TLSA Record?
Learn what a TLSA record is, how DANE uses DNSSEC-protected TLSA data to authenticate TLS services, and where TLSA matters most for SMTP and other protocols.
Definition
A TLSA record is a DNS resource record used by DANE to publish DNSSEC-protected information about the certificate, public key, or issuing authority that a TLS service is expected to use.
Why TLSA records matter
A TLSA record is the DNS object that makes DANE actionable. Instead of relying only on the default public CA trust store, a domain can publish certificate expectations for a specific service name, port, and transport such as _25._tcp.mail.example.com.
That matters most when operators want stronger, domain-controlled signals about transport authenticity. A TLSA record is not a generic TXT note; it is a typed, structured assertion whose value depends on correct owner naming, careful certificate lifecycle management, and working DNSSEC.
What a TLSA record contains
Service owner name
TLSA is published under a name that includes the port, transport, and hostname, such as `_443._tcp` or `_25._tcp` for the target service.
Usage field
The usage value tells the client whether the record constrains CA trust or binds directly to a certificate or public key.
Selector field
The selector says whether the TLSA data refers to the full certificate or only the subject public key information.
Matching data
The matching type and data express the certificate material either exactly or as a hash for easier publication and rotation.
How clients evaluate a TLSA record
Identify the service endpoint
The client determines which host, port, and transport it is about to authenticate, such as SMTP on port 25 or HTTPS on port 443.
Query the TLSA owner name
It looks up the TLSA record under the service-specific owner name rather than at the bare domain alone.
Validate the DNS answer with DNSSEC
Only authenticated DNS data should influence trust decisions, so unsigned or broken validation chains defeat the purpose.
Interpret usage, selector, and matching type
The client reads the rule set that explains what certificate material must appear during the TLS handshake.
Compare live TLS material to DNS data
When the server presents its certificate chain or key, the client checks whether it matches the DNSSEC-protected TLSA assertion.
Accept or reject the connection
If the live certificate satisfies the TLSA rule, the session proceeds; if not, the protocol-specific validation fails.
Four parts that define TLSA behavior
Operators often think of TLSA as a single blob of certificate data, but each field changes the trust meaning of the record.
| Element | What it means | Why it matters |
|---|---|---|
| Usage | Defines whether the record narrows CA trust or directly names acceptable end-entity material. | Choosing the wrong usage can make a valid service fail or make a weaker trust model look stronger than it is. |
| Selector | Chooses between matching the whole certificate or just the public key information. | This affects how disruptive certificate renewal is and how portable the published value remains. |
| Matching type | States whether the comparison uses exact bytes or a hash of the selected certificate material. | Hashed data is shorter to publish and easier to compare, but operators must hash the right input. |
| Certificate association data | Carries the actual certificate or hash value that the client will compare against the live service. | If this data lags behind certificate rotation, clients can reject otherwise healthy services. |
Deployment checks that prevent avoidable breakage
TLSA is unforgiving when DNS, certificates, and operational ownership drift apart.
- Sign the zone correctly and confirm that DNSSEC validation succeeds end to end before relying on TLSA data.
- Publish the record at the correct service owner name, including the right port and transport labels.
- Coordinate TLSA updates with certificate issuance and rollover so DNS assertions never trail the live service.
- Test with DANE-aware validators instead of assuming general browser behavior reflects your deployment.
- Document which team owns TLSA changes for mail, web, and any specialized TLS endpoints.
- Monitor DNSSEC failures because a broken trust chain can silently nullify an otherwise valid TLSA record.
- Use hashes carefully and verify the exact certificate field or public key material you are publishing.
- Cross-reference [MTA-STS](/glossary/mta-strict-transport-security-mta-sts) and [TLS-RPT](/glossary/smtp-tls-reporting-tls-rpt) if you are protecting SMTP.
Where TLSA helps, and where it does not
TLSA shines where clients actually implement DANE. In SMTP that can mean stronger server authentication than ordinary opportunistic TLS, especially when mail operators want DNSSEC-backed control over trust signals. It is not a universal browser-era shortcut. Limited client support, broken DNSSEC operations, or stale certificate associations can turn a theoretically strong control into an operational outage if teams publish TLSA records without validating the full chain of trust.
The practical takeaway
A TLSA record is the structured DNS assertion that DANE-aware clients use to decide what certificate or public key a TLS service should present. The practical key is to treat TLSA as production trust data: publish it at the right owner name, protect it with DNSSEC, coordinate it with certificate rotation, and deploy it only where your clients will actually evaluate it.
Related security terms
DNS-Based Authentication of Named Entities (DANE)
The protocol framework that gives TLSA records their meaning.
DNSSEC
TLSA data is only trustworthy when the DNS answer is validated with DNSSEC.
X.509 Certificate
TLSA records describe how a client should evaluate the certificate material presented by a service.
Public Key Infrastructure (PKI)
DANE and TLSA can complement or narrow the usual WebPKI trust model.
MTA Strict Transport Security (MTA-STS)
Another mail-security mechanism that solves a different part of SMTP transport trust.
Frequently asked questions
What is a TLSA record in simple terms?
A TLSA record lets a domain publish which certificate or public key a TLS service should use, and clients can trust that statement when it is protected by DNSSEC.
How is TLSA related to DANE?
TLSA is the DNS record type that DANE consumes. DANE is the overall validation model; TLSA is the data it reads.
Does a TLSA record work without DNSSEC?
Not safely. Without DNSSEC, an attacker could forge the DNS answer and make the TLSA statement meaningless.
Where are TLSA records commonly used?
They are often discussed for SMTP because mail transfer can benefit from stronger server-authentication signals even where browser-style CA assumptions are weak.
Does TLSA replace certificate authorities?
Not always. Some usage modes constrain public CA trust, while others bind directly to a specific certificate or key.
Do normal web browsers use TLSA broadly?
Broad browser support is limited, so TLSA is more commonly relevant in SMTP and specialized environments than in everyday web browsing.
References
Explore authoritative guidance and frameworks related to tlsa record.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.