DANE Record Checker - Free TLSA Record Lookup

Instantly look up TLSA records for any domain, check your DANE DNS configuration, and verify certificate usage fields - free, no signup required.

Domain Port Protocol

Looking up TLSA records…

Query Name

-

Summary

Checks

Note: Certificate hash matching requires a live TLS handshake and is not performed by this tool. DNSSEC status is verified via the AD flag in DNS responses.

Free DANE lookup · no signup required

How to Use the DANE Record Checker

Enter your domain name (e.g. powerdmarc.com) - without https://

Set the port and protocol for the service to check. Use 25 / TCP for SMTP email, 443 / TCP for HTTPS

Click Check DANE - the tool resolves your MX records, looks up TLSA records on the correct mail host, and validates all field values

What Is DANE?

DANE (DNS-Based Authentication of Named Entities) is an internet security protocol defined in RFC 6698 that uses DNSSEC-signed TLSA records to bind TLS certificates to domain names. Rather than trusting any certificate authority (CA) to vouch for a certificate, DANE lets domain owners publish the expected certificate directly in DNS - secured by DNSSEC.

DANE is most widely deployed for SMTP email security, where it prevents attackers from intercepting email in transit using fraudulent certificates. It can also secure HTTPS, XMPP, SIP, and any other TLS-based protocol.

→ What is DANE? Full technical guide

Certificate pinning via DNS

Publishes the expected certificate fingerprint in DNS so connecting clients can verify it independently of CAs.

MITM attack prevention

Prevents man-in-the-middle attacks by making it impossible to intercept connections with rogue certificates.

Secure SMTP email delivery

Ensures receiving mail servers present the exact TLS certificate expected - enforcing encrypted email delivery.

Downgrade attack prevention

Stops attackers from forcing mail servers into plaintext or weaker encryption during SMTP negotiation.

How Does DANE Work?

DANE works by publishing a TLSA record in DNS that describes the expected TLS certificate for a service. When a client connects, it retrieves the TLSA record via DNSSEC and compares it against the certificate presented during the TLS handshake.

Publish TLSA record - Domain owner creates a TLSA record at _port._protocol.domain with the expected certificate parameters

DNSSEC-validated DNS lookup - The connecting client performs a DNSSEC-validated query to retrieve and authenticate the TLSA record

TLS handshake comparison - The presented certificate is compared against the TLSA record's certificate association data

Enforce or reject - If the certificate matches, the connection proceeds; if not, it is rejected to prevent misuse

What Is a TLSA Record?

A TLSA record is the DNS record type used by DANE. It stores a TLS certificate fingerprint (or full certificate) at a specific DNS name tied to a port and protocol, so any connecting client can retrieve and verify it via DNSSEC before completing the TLS handshake.

TLSA records follow this naming convention:

_[port]._[protocol].[hostname] → e.g. _25._tcp.mail.example.com. IN TLSA 3 1 1 ab12cd34…

For SMTP, the TLSA record lives on the MX hostname - not the root domain. This is why this tool automatically resolves your domain's MX records first, then checks TLSA on the correct host.

Understanding TLSA Record Fields

A record like 3 1 1 <hash> means DANE-EE, SubjectPublicKeyInfo, SHA-256 - the most commonly recommended configuration for SMTP DANE.

Field	Values	Meaning
Certificate Usage	0 = PKIX-TA · 1 = PKIX-EE · 2 = DANE-TA · 3 = DANE-EE	Which certificate in the chain to match, and whether PKIX CA validation is also required
Selector	0 = Full Certificate · 1 = SubjectPublicKeyInfo	Whether to match the full certificate or just the public key
Matching Type	0 = Exact · 1 = SHA-256 · 2 = SHA-512	How the certificate data is encoded in the record
Certificate Data	Hex-encoded hash or full certificate bytes	The fingerprint or certificate to match against what the server presents

Common DANE DNS Configuration Issues

Most DANE failures come down to a handful of recurring misconfigurations. Here's what to look for when your DANE record check returns unexpected results.

Issue	Cause	Impact
No TLSA record found	DANE not published for this port/protocol, or checked on the wrong hostname	DANE cannot be enforced; connections rely solely on CA trust
DNSSEC not enabled	TLSA records without DNSSEC can be spoofed in transit	DANE clients reject or ignore the TLSA record entirely
Certificate mismatch after renewal	TLS certificate renewed but TLSA record not updated to match	Legitimate connections rejected; mail delivery fails
Invalid Usage/Selector/Matching fields	Out-of-range or unsupported field values in the TLSA record	Validation always fails even when the certificate is correct
Missing rollover record	Only one TLSA record published during a certificate transition	Downtime if the old record is removed before DNS has propagated the new one

Best practices for DANE records

Publish rollover TLSA records

Always keep a second TLSA record for your upcoming certificate ready before renewing, to avoid delivery failures.

Enable DNSSEC first

DANE only works when DNSSEC is active. Publish your TLSA records only after DNSSEC is confirmed working.

Update TLSA before cert renewal

Add the new TLSA record to DNS before renewing the certificate so propagation completes in time.

Monitor TLSA records continuously

Catch certificate/TLSA mismatches automatically before they cause email delivery failures.

Frequently Asked Questions

What is a TLSA record?

A TLSA record is a DNS record type (type 52) used by DANE to associate a TLS certificate or public key with a specific domain, port, and protocol. It stores a certificate fingerprint secured by DNSSEC, so connecting clients can verify the certificate during the TLS handshake without relying on a certificate authority.

What is DANE in DNS?

DANE (DNS-Based Authentication of Named Entities) is a security protocol that publishes TLS certificate information directly in DNS using TLSA records, protected by DNSSEC. It removes the dependency on third-party certificate authorities by letting domain owners specify exactly which certificate should be trusted for their services.

What port and protocol should I use for email DANE?

For SMTP email delivery between mail servers, use port 25 with TCP. The TLSA record is published at _25._tcp.[mx-hostname]. Note that for email, TLSA records must be on the MX hostname — not the root domain. Use port 443 / TCP for HTTPS.

Can I use DANE and MTA-STS together?

Yes, and it’s recommended. DANE enforces TLS using DNSSEC-pinned certificates while MTA-STS enforces TLS via an HTTPS-hosted policy. Using both maximises coverage — DANE protects against rogue CAs, while MTA-STS covers sending servers that don’t support DANE.

Do I need DNSSEC for DANE to work?

Yes — DNSSEC is a hard requirement for DANE. Without DNSSEC, anyone could publish a fake TLSA record pointing to a malicious certificate, making the whole validation pointless. DNSSEC cryptographically signs your DNS records so resolvers can verify they haven’t been tampered with.

What is the difference between DANE-TA (usage 2) and DANE-EE (usage 3)?

DANE-TA (Trust Anchor, usage 2) matches an intermediate or root CA certificate — any certificate signed by that CA will pass validation. DANE-EE (End Entity, usage 3) matches the server’s own certificate or public key directly. For SMTP, usage 3 with selector 1 (public key) and matching type 1 (SHA-256) is the recommended configuration per RFC 7672.