0=PKIX-TA, 1=PKIX-EE (public CA required + pinned), 2=DANE-TA, 3=DANE-EE (skip PKIX, trust the binding alone). Most SMTP DANE is Usage 3.
TLSA (DANE) Record Lookup — DNSSEC-backed certificate pinning in DNS.
Query TLSA records to inspect DANE (DNS-Based Authentication of Named Entities) deployments. TLSA publishes a cryptographic binding to a specific TLS certificate or public key in DNS, so clients can verify the cert without depending on the public CA ecosystem. Widely used for SMTP DANE (RFC 7672). Meaningless without DNSSEC — this tool checks the DNSSEC chain of trust before treating the TLSA as valid.
Look up a TLSA record
TLSA names follow `_port._proto.host` — e.g., `_25._tcp.mail.example.com` for SMTP DANE.
What the TLSA lookup shows
0=full cert, 1=subject public key. Selector 1 (SPKI pinning) survives cert renewal with the same key — the common recommendation.
0=exact bytes, 1=SHA-256, 2=SHA-512. SHA-256 is standard.
The actual bytes or hash the resolver compares against. Hex-encoded — 64 chars for SHA-256, 128 for SHA-512.
TLSA without DNSSEC is meaningless. This tool checks the DS chain and refuses to validate TLSA on unsigned zones.
Fetches the actual cert on the port and confirms the TLSA hash matches. Mismatch = broken DANE deployment.
When to check TLSA
- SMTP DANE deployment verification Rolling out DANE for inbound mail? Confirm TLSA + DNSSEC are both correct. Broken DANE = sending servers may skip you, silently dropping mail.
- Cert-renewal safety check After renewing a cert, verify the TLSA still matches (if you're pinning cert bytes) or is still valid (if you're pinning SPKI). Automation matters — a mismatched TLSA breaks every DANE-aware sender.
- European deliverability audit DANE adoption is highest in Europe (Germany especially) — mail.de, GMX, T-Online all check TLSA. If you send to European recipients, DANE support boosts deliverability.
- Compliance evidence Some sectors (finance, healthcare in Germany, Dutch government) now mandate DANE for outbound and inbound mail. This tool provides evidence of correct deployment.
- Zero-trust cert pinning For high-value services, TLSA pins the cert (or SPKI) in DNS — anyone spoofing DNS still can't spoof the cert without also compromising the pinned key.
Common questions
- What is a TLSA record? The DNS record type used by DANE (DNS-Based Authentication of Named Entities). Publishes a cryptographic binding to a specific TLS cert or key in DNS. Requires DNSSEC to be meaningful.
- What is DANE used for? The main real-world use is SMTP DANE (RFC 7672) — mail servers verify each other's certs against TLSA records, replacing the trust-on-first-use model of opportunistic TLS. Also used for HTTPS but adoption is rare in browsers.
- What do the TLSA numeric fields mean? Four fields: Usage (trust anchor type), Selector (full cert vs SPKI), Matching Type (SHA-256/SHA-512), and Data (the hash). Common SMTP DANE pattern: `3 1 1` (DANE-EE + SPKI + SHA-256).
- Do I need DNSSEC for TLSA? Yes — TLSA without DNSSEC is worthless. Anyone who can spoof DNS answers could publish fake TLSA records. The whole trust model is 'trust DNS because DNS is signed'.
- How do I add TLSA for my mail server? 1) Enable DNSSEC. 2) Generate the TLSA hash from your live cert (`openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum`). 3) Publish `_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 <hash>`. 4) Automate the update on cert renewal.
Related tools
See the actual cert the TLSA should pin.
Verify the DNSSEC chain that TLSA depends on.
The other half of cert-issuance hardening.
The MX target is what SMTP DANE-checks — start there.