Free Tool - No Signup Required

TLSA / DANE Record Generator

Paste a certificate or public key and generate a TLSA record for DANE. The hash is computed in your browser — nothing is uploaded.

Service

Host

Usually your MX hostname for SMTP DANE.

Port

Protocol is tcp.

Record name: _25._tcp.mail.example.com.

Usage

Selector

Matching type

Certificate or Public Key (PEM)

Paste a -----BEGIN CERTIFICATE----- block (for any selector) or a -----BEGIN PUBLIC KEY----- block (selector 1 only).

Your TLSA Record

Paste a certificate or public key and click Generate TLSA Record.

DANE requires DNSSEC on your zone. Without a valid DNSSEC chain, senders ignore this record and it provides no protection. Roll the TLSA record with certificate renewal (selector 1 survives renewal if you keep the same key).

How to add this record:

Ensure DNSSEC is enabled and valid on your zone
Add a TLSA record at _25._tcp.mail.example.com.
Enter usage, selector, matching-type, and the hex data (some panels take all four in one field)
Save, wait for propagation, then verify with a scan

Verify with IntoDNS.AI Check MTA-STS

DANE and TLSA, explained

DANE (DNS-based Authentication of Named Entities, RFC 6698) lets a domain assert which TLS certificate or public key a service is allowed to present, and publish that assertion in DNS rather than leaning entirely on the public Certificate Authority system. The assertion is a TLSA record, published at a name built from the port and protocol of the service — for SMTP that is_25._tcp.mail.example.com. A DANE-aware sender fetches that record and refuses to deliver unless the certificate it sees matches.

Every TLSA record carries three numbers followed by a hex value. Usage picks the trust model:3 (DANE-EE) pins the leaf certificate directly and needs no CA chain — it is the de facto standard for SMTP; 2 (DANE-TA) pins a private trust anchor; 1 and 0 additionally require validation against the public PKI. Selector picks what is hashed:1 the SubjectPublicKeyInfo (the public key) or0 the whole certificate. Matching-type picks how:1 SHA-256, 2 SHA-512, or0 the raw certificate bytes with no hash. The overwhelmingly common SMTP record is 3 1 1: DANE-EE, public key, SHA-256.

This generator does the hashing entirely in your browser. Paste a certificate (-----BEGIN CERTIFICATE-----) and it parses the DER, and for selector 1 it walks the X.509 structure to extract the SubjectPublicKeyInfo before hashing; paste a bare public key (-----BEGIN PUBLIC KEY-----) and the DER is already the SPKI. The SHA-256 or SHA-512 digest is produced with the Web Crypto API, so nothing is uploaded. Selector 0 (full certificate) requires a certificate, not a bare key, because there is no certificate to hash otherwise.

The single most important operational rule is to roll the TLSA record with your certificate. With selector 1 the record stays valid across renewals provided you reuse the same key pair, which is why it is recommended. With selector 0the hash changes on every renewal, so you must publish the new record before swapping the certificate or inbound mail will start failing. The safe sequence is always: publish the new TLSA record next to the old one, deploy the new certificate, confirm delivery, then remove the old record.

Finally, DANE is meaningless without DNSSEC. The whole point is that a sender can trust the TLSA record it fetched, and only DNSSEC provides that guarantee. If your zone is not signed, DANE-aware senders ignore the record. Pair DANE with MTA-STS and TLS-RPT for layered inbound transport security, and verify the result with the MTA-STS checker or a full scan on the IntoDNS.ai homepage.

TLSA record format

Field	Values	Meaning
Usage	0, 1, 2, 3	Trust model. 3 = DANE-EE (pin leaf, standard for SMTP).
Selector	0, 1	0 = full certificate, 1 = SubjectPublicKeyInfo (recommended).
Matching	0, 1, 2	0 = exact bytes, 1 = SHA-256 (standard), 2 = SHA-512.
Data	hex	The hash (or raw bytes) of the selected data, in hexadecimal.

Example: _25._tcp.mail.example.com. TLSA 3 1 1 a1b2c3… (DANE-EE, SPKI, SHA-256)

Frequently Asked Questions

What are DANE and TLSA records?

DANE (DNS-based Authentication of Named Entities, RFC 6698) lets you bind a TLS certificate or public key to a hostname through DNS instead of relying solely on public Certificate Authorities. The binding is published as a TLSA record at _<port>._<proto>.<host> — for example _25._tcp.mail.example.com. A sender that supports DANE looks up the TLSA record and only completes the connection if the presented certificate matches it.

What do usage, selector, and matching-type mean?

A TLSA record has three numeric fields before the hash. Usage (0–3) sets the trust model: 3 (DANE-EE) pins the leaf certificate directly and is the norm for SMTP. Selector (0 or 1) chooses what to hash: 0 the full certificate, 1 the public key (SubjectPublicKeyInfo). Matching-type (0, 1, 2) chooses how: 0 the raw bytes, 1 SHA-256, 2 SHA-512. The common SMTP record is 3 1 1 — DANE-EE, SPKI, SHA-256.

When should I use DANE?

The dominant real-world use is SMTP server-to-server (MTA-to-MTA) on port 25, where DANE protects inbound mail against TLS downgrade and man-in-the-middle attacks. Large providers, notably those running Postfix, check DANE for outbound mail. DANE for HTTPS (port 443) exists but has almost no browser support, so for the web you usually rely on CAA and the public PKI instead. Most people generating a TLSA record are hardening mail.

Do I need to update TLSA records when my certificate renews?

It depends on the selector. With selector 1 (SubjectPublicKeyInfo), the record stays valid across renewals as long as you keep the same key pair — so reuse the key on renewal and the record does not change. With selector 0 (full certificate), every renewal changes the certificate and therefore the hash, so you must publish the new TLSA record before switching the certificate. The safe pattern either way is to publish the new record alongside the old one, switch the certificate, then remove the old record.

Does DANE require DNSSEC?

Yes, absolutely. DANE's entire security model rests on DNSSEC: a sender must be able to trust that the TLSA record it fetched is authentic and unmodified. Without a valid DNSSEC chain on your zone, DANE-aware senders will ignore the TLSA record entirely, and it provides no protection. Some TLDs (for example .ai) do not support DNSSEC at the registry level, which means DANE cannot be used for domains under them.

Is my certificate processed privately?

Yes. The PEM you paste is parsed and hashed entirely in your browser using the Web Crypto API. Nothing is uploaded to IntoDNS.ai or any server. A certificate and its public key are public information anyway, but the computation still happens locally so you can use this tool offline once the page has loaded.