DANE / TLSA Generator
Build your TLSA record
The MX host senders connect to. A TLSA record pins the certificate that this exact host must present.
The record is published at _25._tcp.mx1.acme-corp.com. Each MX host needs its own record.
Both are encoded into the record name, so a record on the wrong port is never looked up.
Port
Protocol
Record name
_25._tcp.mx1.acme-corp.com
SMTP DANE uses port 25 over TCP. Submission on 587 or 465 is not covered by this record.
Step 1 of 3
Finish the wizard to build your record
Work through the three steps above, then press Generate on the last step to produce your TLSA record.
Tool features
4 features
Real SPKI hashing
Parses the certificate and hashes the public key or the full DER, not a stand-in
100% client-side
The pasted certificate is never uploaded — hashing uses the browser's Web Crypto API
Prefill from live DNS
Reads the TLSA record already published on the host so you can roll a new key from it
Verify & export
Ready-made OpenSSL command plus zone file, JSON and branded PDF export
What is a TLSA record & how DANE works
A TLSA record is how DANE (RFC 6698) pins the certificate a mail server must present. It lives at _25._tcp.yourmailhost and carries four fields: certificate usage, selector, matching type, and a digest of the certificate or its public key.
Because the trust anchor is DNS itself, DANE only works inside a DNSSEC-signed zone — senders ignore unsigned TLSA records entirely. This generator computes the digest from your certificate locally in the browser and gives you the zone-file line plus the OpenSSL command to verify it against the live server.
Every field in the wizard — the host, the port, the certificate and the usage, selector and matching numbers — is explained one by one in TLSA Generator: Every Input Explained — the same copy behind every “What's this?” link above.
Usage
Which certificate is pinned. 3 (DANE-EE) pins the server certificate and skips CA validation.
Selector
What gets hashed: 1 hashes the public key and survives renewals; 0 hashes the whole certificate.
Matching type
The digest algorithm. 1 is SHA-256 and is what every implementation supports.
How to use this tool
1
Enter the mail server host
Use the MX hostname senders connect to, then set the port and protocol — usually 25 over TCP.
2
Paste the certificate
Paste the PEM block your server presents. The digest is computed in your browser and never uploaded.
3
Pick the parameters
3 1 1 (DANE-EE, SPKI, SHA-256) is the recommended combination for SMTP DANE.
4
Publish in a signed zone
Add the record to your DNSSEC-signed zone, then verify it with the OpenSSL command or the DANE Checker.
Related tools
4 tools
DANE / TLSA Checker
Check DANE TLSA records for every MX host, verify the DNSSEC chain, and match records against the live mail server certificate
DNSSEC Validator
Validate DNSSEC (DNS Security Extensions) configuration, check DNSKEY, DS, and RRSIG records
Certificate Decoder
Decode and analyze SSL certificate contents, properties, and metadata in detail
MTA-STS & TLS-RPT Generator
Generate an MTA-STS policy file and the _mta-sts and TLS-RPT DNS records to enforce and monitor TLS on inbound email
Frequently asked questions
6 Q&A
Yes. DNSSEC is the trust anchor for DANE. Senders that validate DANE ignore TLSA records in unsigned zones, so publishing a TLSA record without signing the zone achieves nothing.
No. The PEM block is parsed and hashed entirely in your browser using the Web Crypto API. Nothing is sent to a server.
The port and protocol are part of the record's name, not fields inside it. Server-to-server SMTP uses port 25 over TCP, so a mail DANE record lives at _25._tcp.yourmailhost.
Publish the new key's TLSA record alongside the old one, wait for at least the TTL so caches carry both, switch the server to the new certificate, then remove the old record after 2 × TTL.
Yes. DANE pins a specific server, so each MX hostname needs its own record published under its own name.