What is the best free DANE / TLSA record checker and generator?

DANE (DNS-Based Authentication of Named Entities, RFC 6698) pins which certificate a mail server is allowed to present, by publishing a hash of it in DNS as a TLSA record. It closes the hole that STARTTLS leaves open: an attacker who can intercept the connection can otherwise strip encryption or present any certificate a public CA would issue, and the sending server has no way to know better.

Reading what is published

The DANE / TLSA Checker looks up the records at the right place — _25._tcp. in front of the mail server hostname, not the domain — and decodes the three numbers that make up every TLSA record:

• Usage. 0 PKIX-TA and 1 PKIX-EE still require a public CA to vouch for the certificate; 2 DANE-TA pins your own issuing authority; 3 DANE-EE pins the exact end-entity certificate and needs no CA at all.
• Selector. 0 hashes the whole certificate, 1 hashes only the SubjectPublicKeyInfo — the public key.
• Matching type. 0 is the full value, 1 SHA-256, 2 SHA-512.

For SMTP the profile to publish is 3 1 1: pin the end-entity key, hash the SubjectPublicKeyInfo, SHA-256. It survives certificate renewal as long as the key stays the same, which is what makes it operationally survivable. The checker flags anything that is valid but not recommended rather than silently accepting it.

Producing the record

The TLSA / DANE Record Generator takes a certificate or public key, computes the hash, and assembles the record with the usage, selector and matching type you choose. It runs entirely in the browser using the Web Crypto API — the certificate you paste is never uploaded, which matters when the material is a key rather than a public cert.

The two things that break DANE

DNSSEC is not optional. A TLSA record in an unsigned zone proves nothing: an attacker who can forge DNS answers can forge the TLSA record too. Sending servers that implement DANE ignore TLSA records unless the zone validates, so publishing them without DNSSEC changes nothing at all. Check the signing first with the DNSSEC Checker.

Renewal order is a live-mail hazard. DANE fails closed. If you install a new certificate with a new key before the matching TLSA record is published and has propagated, every sending server that validates DANE will refuse to deliver — and the bounces are hard to read, because the sender sees a TLS failure and not an explanation. The safe sequence is to publish the new hash alongside the old one, wait out the TTL, switch the certificate, then remove the old record. Keeping the same key across renewals avoids the problem entirely, which is the practical argument for the 3 1 1 profile.

Checking it without a browser

GET https://intodns.ai/api/dns/tlsa?domain=example.com

The response names the record location it queried, and returns each record with its numeric usage, selector and matching type plus a decoded description — DANE-EE: Domain-issued certificate, SubjectPublicKeyInfo, SHA-256 hash — so a script or an agent does not have to carry the RFC's lookup tables. For assistants the same check is the MCP tool check_tlsa_dane on the remote endpoint at https://intodns.ai/api/mcp.

Where DANE sits next to MTA-STS

Both make SMTP transport verifiable and they solve it differently: DANE anchors trust in DNSSEC, MTA-STS in the web PKI and a policy file served over HTTPS. Google and Microsoft honour MTA-STS; much of the European mail estate honours DANE. They are not alternatives so much as different audiences, and publishing both is normal for a domain that wants transport security to hold for everyone sending to it.