Generate a DNS TLSA record from an X.509 certificate to enable DANE (TLS Authentication). Fill in the connection details below, paste your certificate, and we will build the record for you.

What is a TLSA record

A TLSA record is a DNS record used by DANE (DNS-Based Authentication of Named Entities) to bind a TLS certificate (or its public key) to the hostname and port of a service, such as a mail server. It lets clients verify the certificate they receive during a TLS handshake against what the domain owner has published in DNS, independent of the public CA system.

A TLSA record always lives under _port._transport.hostname and has four fields: usage, selector, matching-type, and the certificate association data. Use the form below to generate that data from your certificate, and the "Test record" tab to verify a record against a live server.

Hostname

The fully qualified hostname the certificate is issued for and served on — for example smtp.example.com or mail.example.com. This becomes part of the DNS record name (_port._transport.hostname).

Transport

Port

Common ports: 25 / 587 SMTP · 465 SMTPS · 443 HTTPS · 993 IMAPS

Usage

Defines the role of the certificate in the DANE chain. 3 — DANE-EE is the most common choice for mail servers and HTTPS: the record pins the server's own certificate or public key directly, with no dependency on the CA hierarchy. Usage 0 and 1 require the certificate to also pass normal PKIX (CA-based) validation, which makes them unsuitable for SMTP where clients may not check the CA chain.

0 — Certificate Authority Constraint (PKIX-TA) 1 — Service Certificate Constraint (PKIX-EE) 2 — Trust Anchor Assertion (DANE-TA) 3 — Domain Issued Certificate (DANE-EE)

Selector

Determines whether the TLSA record is based on the full certificate or only its public key. 1 — SPKI (Subject Public Key Info) is strongly recommended for most setups: because it only covers the public key and not the certificate metadata, the record remains valid across automatic renewals (e.g. Let's Encrypt every 90 days) as long as the same key pair is reused. Selector 0 (full certificate) requires you to update the DNS record every time the certificate is renewed.

0 — Full certificate (Cert) 1 — Subject Public Key (SPKI)

Matching type

How the certificate or public key data is encoded in the record. 1 — SHA2-256 is the standard choice and supported everywhere. SHA2-512 (type 2) offers a larger hash but is rarely needed. Type 0 (no hash, raw data) is almost never used in practice because the resulting record is large enough to be rejected by many DNS providers and resolvers.

0 — Full data (no hash) 1 — SHA2-256 hash 2 — SHA2-512 hash

Certificate in PEM (X.509) format — optional

Paste or upload your certificate here. If you leave this empty, we will connect to your server using the hostname, port, and connection mode below and fetch it automatically. Use the manual option if the server is not yet publicly reachable.

⚠ Only upload or paste your public certificate — the file that starts with -----BEGIN CERTIFICATE-----. Never paste a private key (-----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----). Your private key never needs to leave your server.

Choose file… drag a file here, or paste the certificate directly into the box below

Connection mode

Only relevant when no certificate is provided above — this tells us how to connect to your server to fetch it. Choose Direct TLS for services where TLS starts immediately (HTTPS on 443, IMAPS on 993, SMTPS on 465). Choose STARTTLS for services that start unencrypted and upgrade to TLS mid-session — this is standard for SMTP on port 25 and 587.

Direct TLS (e.g. 443, 465, 993, 995) STARTTLS — SMTP (e.g. 25, 587)

TLSA Record Generator

What is a TLSA record