TLSA

TLSA records (RFC 6698, RFC 7671/7672) pin a certificate or its public key in DNS so that TLS clients can verify a server independently of certificate authorities (DANE). Paste a certificate and this generator computes the digest locally in your browser.

DNSSEC is a prerequisite. DANE only works in DNSSEC-signed zones – without validation, clients cannot trust the TLSA record. For the mail server check, a record that a sending MTA could use (usage 2 or 3) and that is not DNSSEC-authenticated is a failure; records that are unusable for SMTP anyway – usage 0/1, or a selector, matching type or digest length no client can use – are graded like a domain with no TLSA record at all. They are not entirely without effect, though: in a DNSSEC-signed zone RFC 7672 §2.2.3 still commits sending MTAs to STARTTLS, so plaintext delivery over that host is ruled out – authentication is not. Replace such records with usage 3 (DANE-EE) or 2 (DANE-TA) rather than simply deleting them.

For SMTP the record name is _25._tcp.<MX hostname> – the host is the MX host name (e.g. mx1.example.net), not the mail domain. For a key rollover, publish a second record for the new key alongside the old one and leave both in place for at least two TTLs of the TLSA RRset before the new certificate goes live. RFC 7671 §8.1 walks through exactly this sequence: records matching the future keys are added “at least two Times to Live (TTLs) or longer before the new chain is deployed”, so the obsolete RRset can age out of sender caches. Remove the old record only afterwards — a sender still holding the old RRset finds no match, and RFC 7672 §3.2 then bars delivery (“Messages MUST NOT be delivered via the SMTP server if authentication fails”).

Host name

The host name of the server for the selected port — e.g. www.example.com for HTTPS, mx1.example.com for SMTP, dns.example.com for DNS over TLS.

Certificate (PEM)

Paste the server certificate or the full chain; for DANE-TA (usage 2) the second block – the issuer – is used. Or use Load current record & certificate above to read it from your server.

Certificate to pin

After fetching, pick which certificate from the presented chain the record matches — leaf = DANE-EE (usage 3), a CA = DANE-TA (usage 2). Usage follows your choice. For DANE-TA, pin an intermediate: servers send intermediates but usually not the root, and DANE-TA requires the pinned certificate to be in the presented chain (RFC 7671 §5.2). To pin the root, use PKIX-TA (0) — it validates against the client's trust store — but PKIX usages are discouraged for SMTP (RFC 7672).

Usage

Two independent choices. PKIX (0/1) still requires the certificate to validate against a public CA — TLSA only adds a pin on top. DANE (2/3) replaces the public CA: the DNSSEC-signed record is the trust anchor, so a private or self-signed certificate works. TA (0/2) pins the issuing CA, so leaf certificates can rotate freely; EE (1/3) pins the certificate itself. For SMTP, RFC 7672 recommends DANE-EE (3) or DANE-TA (2).

Selector

Matching type

Port

Any port works for the record itself. The live certificate fetch works on 25, 443, 465, 587, 853, 990, 993 and 995 only — for any other port, paste the certificate below.

Protocol

The transport label in the record name (_port._proto), RFC 6698 §3. Almost always tcp. The live-certificate fetch is tcp only — for udp/sctp, paste the certificate to build the record.

Records are built in your browser; “Load current record & certificate” has our server look up DNS and open a TLS connection to read the certificate. Record Studio · Verify the result with the domain security check