🔑 TLSA Lookup Tool

Check a domain's TLSA (DANE) records for any service — certificate usage, selector, matching type, and the associated data. Live, free, no signup.

✍️ Author: ToolsNovaHub • 📅 Last Updated: 23 August 2026
Examples: mail.protonmail.ch (SMTP)   www.huque.com (HTTPS)
🕒 Recent Lookups
No recent lookups yet.
Every DNS-based certificate mechanism before DANE relied entirely on the public Certificate Authority system — trust a CA, trust whatever it signs. TLSA records, the DNS record type behind DANE (DNS-Based Authentication of Named Entities), let a domain owner publish exactly which certificate or public key is valid for a given service directly in DNS, independently verifiable without asking any CA to vouch for it at all. This tool queries any hostname's TLSA records live for a chosen service; the reference below covers record syntax, the certificate usage modes, and where DANE is actually deployed in practice today.
⭐ ToolsNovaHub Pro Tip
If you're publishing DANE for SMTP, prefer certificate usage 3 (DANE-EE) with selector 1 (SPKI) and matching type 1 (SHA-256) pinned to your key's public key rather than the full certificate — it survives certificate renewal on the same key pair without requiring a DNS update every time.
⚠️ Common Beginner Mistake
Publishing a TLSA record on a zone that isn't DNSSEC-signed. An unsigned TLSA record provides no real protection — anything relying on DANE will typically either ignore it or, for strict implementations, fail closed, since the whole point is a chain of trust an attacker can't forge in transit.
📑 Table of Contents

🔍 What This Tool Checks

A TLSA record (RFC 6698) publishes a certificate or public-key association directly in DNS for a specific service on a specific host and port — the record type underlying DANE. This tool queries the live TLSA record for a hostname and service, decodes each field, and shows exactly what certificate association is being asserted. For DANE's architecture and how it relates to the public CA system, see What Is DANE?.

📋 TLSA Record Syntax

_25._tcp.mail.example.com.  3600  IN  TLSA  3 1 1 8bf1c86e...(hex)
_443._tcp.example.com.      3600  IN  TLSA  1 1 1 a4b9c3d0...(hex)

The record name always follows the pattern _port._protocol.hostname — not the bare domain — because a single host can run different certificates on different services. Each record has four fields, in order: certificate usage, selector, matching type, and the certificate association data itself (a hex-encoded hash or full certificate, depending on the matching type chosen).

🔑 Certificate Usage Field (0–3)

ValueNameMeaning
0PKIX-TAPins a CA in the chain; certificate must still validate through the public CA system
1PKIX-EEPins the exact end-entity certificate; must still chain to a trusted public CA
2DANE-TAPins a private/custom CA as trust anchor; no public CA chain required
3DANE-EEPins the exact end-entity certificate directly; no CA validation at all — DNSSEC is the sole trust anchor

Usage 3 (DANE-EE) is by far the most common in real-world SMTP deployments, since it works cleanly with self-signed or short-lived certificates and doesn't depend on any CA relationship remaining valid.

🎯 Selector Field

The selector determines what's actually being matched: 0 (Cert) matches the entire certificate, meaning the TLSA record must be updated every time the certificate is renewed — even on an identical key. 1 (SPKI) matches only the certificate's public key, which survives a routine renewal as long as the same key pair is reused, making it the more operationally convenient choice for most deployments.

📈 Matching Type Field

ValueTypeNotes
0FullThe complete certificate or key, unhashed; rarely used given record size
1SHA-256The standard, most widely used choice
2SHA-512Stronger hash, larger record, used less often in practice

⚙️ How This Tool Queries TLSA Data

1

You Enter a Hostname and Service

Pick a preset port/protocol (HTTPS, SMTP, etc.) or supply a custom prefix.

2

The Tool Builds the Query Name

Your hostname is combined with the service prefix into the required _port._proto.hostname form.

3

A TLSA Query Is Sent

The tool queries a public DNS resolver for TLSA (type 52) records against that exact name.

4

Each Field Is Parsed and Labeled

Usage, selector, matching type, and the association data are decoded and shown in plain language.

🔒 Why This Result Is Meaningless Without DNSSEC

A TLSA record on an unsigned zone provides no real security value — a network-position attacker could strip or forge it undetected. This tool shows whatever TLSA records exist regardless of DNSSEC status, since validating DNSSEC is a separate step. Pair a check here with our DNSSEC Checker before relying on any result operationally.

🔧 Troubleshooting

⚠️ No TLSA records returned
Confirm you queried the correct _port._proto prefix for the service (e.g. _25._tcp for SMTP), not the bare domain — a bare-domain query always comes back empty.
⚠️ Mail delivery failing after a certificate renewal
If the record uses selector 0 (full certificate), it must be updated to match the new certificate — this is the most common DANE-related delivery failure. Selector 1 (SPKI) survives renewal if the key pair is reused.
⚠️ TLSA record present but not being honored by senders
Verify the zone is actually DNSSEC-signed and validating with our DNSSEC Checker — an unsigned or broken chain causes DANE-aware clients to ignore the record.
⚠️ Expecting browser HTTPS enforcement
No major browser checks DANE/TLSA for ordinary web browsing — deployment has concentrated almost entirely on SMTP. Don't rely on a published HTTPS TLSA record as your only protection.

Verify DNSSEC signing status with DNSSEC Checker. Check an existing certificate directly with SSL Certificate Checker. See which CAs are authorized to issue at all with CAA Lookup, verify mail authentication with SPF Lookup and DKIM Lookup, and check general DNS records with DNS Lookup.

📚 Want the full picture on DANE? Read: What Is DANE? → · Setting it up for mail? DANE for SMTP: Implementation Guide →

ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.

📋 Related Tools & Guides Comparison

ResourceTypeLink
DNSSEC CheckerSecurityOpen Tool →
SSL Certificate CheckerSecurityOpen Tool →
CAA LookupSecurityOpen Tool →
What Is DANE?GuideRead Guide →
DANE for SMTPGuideRead Guide →
🔗 Continue exploring: DNSSEC Checker · SSL Certificate Checker · CAA Lookup · DNS Lookup · SPF Lookup · DKIM Lookup · DMARC Lookup · SMTP Tester · SMTP Banner Checker · What Is DANE · DANE for SMTP · CAA Records

FAQ

TLSA records aren't published at the bare domain — they live at a special name like _443._tcp.example.com, because a single domain can run different certificates on different services.
No — no major browser validates DANE/TLSA for the web natively. DANE adoption for HTTPS has been almost entirely on the server/mail side, chiefly SMTP.
They provide no real security benefit. A TLSA record's entire value depends on DNSSEC proving it wasn't forged or stripped in transit — without that, an attacker can simply remove it.
Usage 1 (PKIX-EE) pins the exact end-entity certificate while still requiring it to chain to a trusted public CA. Usage 3 (DANE-EE) pins the certificate directly and skips CA validation entirely.
Yes — with certificate usage 3 (DANE-EE), DNSSEC-signed DNS itself is the trust anchor, so no public CA chain is required at all.
Supporting TLS and publishing DANE are separate steps. TLSA records must be deliberately added to DNS and signed with DNSSEC; TLS support alone doesn't create them.
No — they solve a similar problem differently. HPKP was browser-enforced and is now deprecated; DANE is DNS-published and enforced by the connecting mail server or client, not the browser.
No — DANE for SMTP support varies by provider. Major implementers include large European providers and mail platforms that explicitly support RFC 7672; not all do.
Yes — completely free, no signup, unlimited queries, with results parsed and shown clearly for every record found.
Only if using selector 0 (full certificate) with usage 1 or 3 and the new certificate differs — otherwise the old TLSA record breaks validation until updated. Selector 1 (SPKI) pinned to a stable key survives a certificate renewal on the same key pair.