TLSA Lookup
DANE / TLSA certificate association records.
Enter a value above to run TLSA Lookup
e.g. _443._tcp.example.com
Quick answer
A TLSA lookup returns the DANE records that tie a domain's TLS certificate or public key to its DNS, so clients can confirm they are talking to the right server. The record names the port and protocol (e.g. _443._tcp) and pins the exact certificate or key expected there.
A TLSA lookup retrieves the DANE (DNS-Based Authentication of Named Entities) records that pin a specific certificate or public key to a service. Each record lives at a name like _25._tcp.mail.example.com and tells a connecting client exactly which certificate to expect over TLS. This tool queries those records so you can confirm your DANE setup is published correctly before mail servers start enforcing it.
DANE is most widely used to secure SMTP between mail servers, letting the receiving side prove its certificate through DNSSEC instead of relying solely on public certificate authorities.
How it works
A TLSA record is queried at a name built from the port, protocol, and hostname, for example _443._tcp.www.example.com for HTTPS or _25._tcp.mail.example.com for SMTP. The record has four parts: usage (0-3), selector (0 or 1), matching type (0-2), and the certificate association data. This tool resolves that name and returns each field so you can compare it against the certificate your server actually presents.
How to read the results
Read the record as usage, selector, matching type, then the hash. Usage 3 (DANE-EE) pins the server's own certificate and is the common choice for SMTP; usage 2 pins a private CA. Selector 0 covers the full certificate, 1 only the public key. Matching type 1 means SHA-256, the recommended value. The final hex string must match a digest of your live certificate exactly, or validation fails.
Common problems & fixes
The most frequent failure is a stale hash: you renewed the certificate but forgot to publish the new TLSA record, so the digest no longer matches. Always publish the new record before deploying the certificate, then remove the old one. DANE also requires a valid DNSSEC chain; without signed zones, clients ignore the record entirely. Check that the port, protocol, and hostname in the query name exactly match the service.
Frequently asked questions
- Do I need DNSSEC for TLSA records to work?
- Yes. DANE trusts TLSA records only when they are protected by a valid DNSSEC signature chain. Without DNSSEC, an attacker could forge or strip the records, so validating clients and mail servers treat an unsigned zone as if no TLSA record exists. Sign your zone first, then publish TLSA.
- What does the query name _25._tcp.mail.example.com mean?
- It encodes where the service listens. The first label is the port (25 for SMTP), the second is the transport protocol (_tcp), and the rest is the host running the service. For HTTPS you would query _443._tcp.www.example.com. The name must match the actual endpoint clients connect to.
- Which usage and matching type should I publish?
- For SMTP DANE the common, interoperable choice is usage 3 (DANE-EE), selector 1 (public key), matching type 1 (SHA-256), often written as 3 1 1. This pins your leaf key and survives certificate renewals as long as the key stays the same. Avoid matching type 0, which stores the full data unhashed.