Do I need DNSSEC for DANE?

Yes, absolutely. The TLSA record's authenticity depends on DNSSEC validation; an unsigned record can be forged by anyone able to spoof DNS, which defeats the entire mechanism.

Does DANE work for websites?

Not in practice. No mainstream browser implements it, so DANE's real deployment is SMTP, where it prevents downgrade of opportunistic TLS between mail servers.

Which usage and selector should I choose?

For mail, DANE-EE (usage 3) with selector 1 (SubjectPublicKeyInfo) and matching type 1 (SHA-256) is the common, robust combination — it survives certificate renewal when the key is reused.

What happens if my TLSA record is wrong?

Validating senders refuse to deliver. It fails closed by design, which is why overlapping records during rotation is not optional.

TLS & Email🌐 YAS server-sideAPI availableadvanced

DANE / TLSA

Validates TLSA records (DANE) against a host's actual TLS certificate.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

DANE / TLSA — pin the certificate in DNS

Fetches _443._tcp.<domain> TLSA records and hashes the live certificate to verify each one.

What does this tool do?

Validates TLSA records (DANE) against a host's actual TLS certificate.

Why would I use it?

You are implementing DANE for mail or web.
You want to verify TLSA records match the served certificate.
You are auditing DNSSEC+DANE deployments.

Real-life example

Input

example.com:443

Output

TLSA 3 1 1 <hash> — MATCHES certificate

The record's fingerprint is compared with the live cert.

Input → Process → Output → Next

Input: Enter host and port.
Process: YAS fetches TLSA records and the TLS certificate, then compares.
Output: Match / mismatch with details.
Next action: Publish or fix TLSA records to match your certificate.

Common mistakes

Using DANE without DNSSEC (records are unsigned and vulnerable).
Wrong usage/selector/matching type numbers.
Forgetting that mail uses port 25 SMTP TLS, not 443.

What the result means

A match means clients can authenticate the cert via DNS.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/dane-tlsa

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/dane-tlsa" \
  -H "Content-Type: application/json" \
  -d '{"input":"example.com","port":443,"proto":"tcp"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/dane-tlsa", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "example.com",
  "port": 443,
  "proto": "tcp"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/dane-tlsa", json={"input":"example.com","port":443,"proto":"tcp"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	Hostname, e.g. example.com
port	integer	No (default 443)	Service port (default 443)
proto	string	No (default "tcp")	tcp \| udp

Success response

{ "result": { "records": [{ "raw": "3 1 1 abc...", "usage": 3, "selector": 1, "matchingType": 1, "match": true }], "cert": { "subject": "...", "expiresInDays": 120 } } }

Validate DANE TLSA records (_port._tcp.domain) against the live TLS certificate.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How DANE / TLSA works

DANE publishes a TLSA record in DNS that pins which certificate or public key a service must present, removing the assumption that any of hundreds of public CAs may issue for your domain. The record name encodes port, protocol and host (_25._tcp.mail.example.com) and carries four fields: certificate usage, selector, matching type and the association data — typically a SHA-256 digest of the certificate or its public key.

DANE is only meaningful with DNSSEC. Without a validated chain of trust, an attacker who can spoof DNS can also spoof the TLSA record, and the pin proves nothing. This dependency is why DANE has seen strong adoption in SMTP — where opportunistic TLS was otherwise trivially downgradable — and almost none in the browser world.

When to use it: real-world scenarios

Securing SMTP between mail servers

Inter-server SMTP TLS is opportunistic and downgradable by default. DANE lets a sending server require a specific certificate, which is its principal real-world deployment.

Pinning without depending on the CA ecosystem

DANE-EE usage pins your own certificate, so a mis-issuance by any public CA cannot be used against your service.

Meeting a jurisdictional mail security requirement

Several European government and healthcare frameworks require DANE for inbound mail; a valid TLSA record is the evidence.

Verifying a record before a certificate rotation

Publishing the new digest alongside the old before switching avoids the outage that a single-record rollover guarantees.

Pro tips

Publish both old and new TLSA records during a rotation and keep them overlapping for at least the record TTL. This is the entire discipline of operating DANE safely.
Use selector 1 (public key) rather than 0 (full certificate) so a renewal with the same key does not require a DNS change.
DANE without DNSSEC is decorative. Sign the zone first and confirm validation before publishing TLSA records.
Monitor from outside: a stale TLSA record silently blocks inbound mail from DANE-validating senders while everything else looks healthy.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Requires a DNSSEC-signed zone; without it the records carry no security value.
Browsers do not implement DANE, so it does not protect ordinary HTTPS traffic.
A mismatched record causes hard failure for validating senders — an outage, not a warning.
Adoption outside SMTP remains minimal, limiting practical benefit for other protocols.

Frequently asked questions

Do I need DNSSEC for DANE?: Yes, absolutely. The TLSA record's authenticity depends on DNSSEC validation; an unsigned record can be forged by anyone able to spoof DNS, which defeats the entire mechanism.
Does DANE work for websites?: Not in practice. No mainstream browser implements it, so DANE's real deployment is SMTP, where it prevents downgrade of opportunistic TLS between mail servers.
Which usage and selector should I choose?: For mail, DANE-EE (usage 3) with selector 1 (SubjectPublicKeyInfo) and matching type 1 (SHA-256) is the common, robust combination — it survives certificate renewal when the key is reused.
What happens if my TLSA record is wrong?: Validating senders refuse to deliver. It fails closed by design, which is why overlapping records during rotation is not optional.

Related tools

TLS Analyzer DNSSEC Check