The DANE TLSA Record Generator is a three-step wizard, and each step is made of input cards with a What's this? link in the corner. This article is the long-form version of those pop-ups: one section per card, in wizard order, with the same control rendered inline. Where a card offers a choice, select an option in the preview and the explanation for that specific value appears underneath.
_25._tcp.mx1.acme-corp.com. IN TLSA 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9…
│ │ │ │ │ │ └── the digest — step 2 (your certificate)
│ │ │ │ │ └── matching type — step 3
│ │ │ │ └── selector — step 3
│ │ │ └── certificate usage — step 3
│ │ └── mail server hostname — step 1
│ └── protocol — step 1
└── port — step 1Mail server hostname
Step 1. DANE pins a certificate to a specific server, not to a domain — so this field is the MX hostname senders actually connect to, not the domain in your email addresses.
If acme-corp.com publishes two MX records, you need two TLSA records — one under each host, each pinning the certificate that host actually presents. There is no record at the domain level and no inheritance.
The host must also live in a DNSSEC-signed zone. That is often a different zone from the mail domain: if your MX points at mx.provider.example, the TLSA record belongs to the provider's zone and only they can publish it.
Look up existing queries the host and reports whether its zone is signed. When a record is already published, a second card offers to prefill the parameters in step 3:
Port and protocol
Neither of these is a field inside the record — they are part of its name, written as _port._protocol in front of the hostname. The card shows the resulting name as you type.
Server-to-server SMTP delivery happens on port 25 over TCP, so that is what a mail DANE record uses. A record published under the wrong port is not wrong so much as invisible — nothing ever queries that name, and delivery proceeds as if DANE were not deployed.
Ports 587 and 465 are submission ports used by mail clients. They are a separate concern with a separate record, and pinning them does nothing for server-to-server delivery. The protocol toggle offers udp for completeness; SMTP never uses it.
Certificate
Step 2. Paste the certificate your mail server presents on the port above — the PEM block that starts with -----BEGIN CERTIFICATE-----. Its hash becomes the association data at the end of the record.
The parsing and hashing happen entirely in the page: the PEM is decoded to DER, the SubjectPublicKeyInfo is extracted when the selector is SPKI, and the digest is computed with the browser's crypto API. Nothing is uploaded, which matters because the same paste box is the obvious place to drop a certificate you would rather not send anywhere.
You can skip the step. The wizard then generates the record with a clearly-labelled placeholder digest and gives you the OpenSSL pipeline that computes the real one from the live server:
openssl s_client -starttls smtp -connect mx1.acme-corp.com:25 < /dev/null 2>/dev/null \
| openssl x509 -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -hexCertificate usage
Step 3 sets the three numbers at the front of the record. The first, usage, decides which certificate is being pinned and whether the sender must also validate it through the public CA system. Select a value to see what it means.
Selector
The second number says what part of the certificate gets hashed. In the wizard this card sits beside the matching-type card covered in the next section. It is the field that decides how painful your certificate renewals will be.
With selector 1, renewal is a non-event as long as you reuse the key pair — most ACME clients can be told to do exactly that. With selector 0, every renewal is a coordinated rollover: publish the new record, wait for the TTL, then deploy the certificate.
Matching type
The third number picks the digest algorithm that produces the association data at the end of the record.
A fourth value, 0, means “no hash — the full certificate data is in the record”. It is legal, produces an enormous DNS record, and is not offered here for good reason.
| Combination | Means | Verdict |
|---|---|---|
3 1 1 | Server key, SHA-256, no CA validation | The SMTP standard — use this |
3 0 1 | Full server certificate, SHA-256 | Works, but breaks on every renewal |
2 1 1 | Private CA key, SHA-256 | Only if you run your own CA |
1 1 1 | Server key plus public CA validation | Extra failure modes, no extra security |
The wizard notices when your selection is not 3 1 1 and offers a one-click button to switch back to it. That is not a nag — it is the combination the overwhelming majority of DANE- capable senders expect, and the one with the fewest ways to fail.
What the wizard does with your answers
Pressing Generate assembles the owner name from the host, port and protocol, puts the three numbers in front of the digest, and produces the zone-file line to paste into your DNS, the OpenSSL command that recomputes the same digest from the live server, and a checklist covering DNSSEC, the parameter choices and whether the digest came from a real certificate or the placeholder.
Publish it in the signed zone, then confirm the deployment with the DANE Checker before you rely on it.
Frequently Asked Questions
1. Can I publish a TLSA record without DNSSEC?
You can put it in the zone, but no sender will act on it. DANE’s entire trust model is that DNSSEC guarantees the record is genuine; in an unsigned zone an attacker could remove it, so implementations correctly ignore it.
2. Do I need a certificate from a public CA?
Not with usage 3. DANE-EE tells the sender to trust the certificate because DNSSEC vouches for the digest, so a self-signed certificate is fine — which is often simpler to control than a CA-issued one on a mail server.
3. What happens when I renew the certificate?
With 3 1 1 and the same key pair, nothing — the public key digest is unchanged. With a new key, or with selector 0, publish the new TLSA record alongside the old one, wait for the old record’s TTL to pass, deploy the certificate, then remove the stale record. Two records at the same name are valid and a match against either one succeeds, which is what makes that rollover safe.
4. Should I deploy DANE or MTA-STS?
Both, if you can. They defend the same attack from different trust roots — DANE via DNSSEC, MTA-STS via the public CA system and HTTPS. A sender implements one or the other, so publishing both covers more of your inbound mail than either alone.
5. Why is my record showing a placeholder digest?
Because no certificate was pasted in step 2. The result panel labels it clearly and marks the record as not ready to publish — run the OpenSSL command it gives you, then paste the real certificate or the digest before adding anything to your zone.