DANE TLSA Generator

How to use this DANE TLSA generator

Generating a correct TLSA record takes three inputs: your certificate, the right parameters, and a DNSSEC-enabled domain. Get any of these wrong and DANE fails silently.

Step 1: Configure TLSA parameters

Choose parameters based on your deployment scenario:

Recommended configuration for SMTP:

Step 2: Provide the certificate

Paste your certificate in PEM format:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQON...
-----END CERTIFICATE-----

How to obtain the certificate:

# From your mail server via STARTTLS
openssl s_client -connect mail.captaindns.com:25 -starttls smtp 2>/dev/null | openssl x509

# From a file on the server
cat /etc/letsencrypt/live/mail.captaindns.com/cert.pem

Step 3: Copy and publish

The generator produces a complete, ready-to-publish DNS record:

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4d

Copy the output and add it to your DNS zone. Ensure DNSSEC is active on the domain before publishing. Without DNSSEC, the TLSA record has no security value.

Step 4: Verify deployment

Run our DANE TLSA Checker to confirm the record is live, DNSSEC-signed, and matches your server certificate. Do not skip this step.

TLSA parameter guide

Choosing wrong parameters is the second most common DANE deployment error (after forgetting DNSSEC). This guide explains each field and when to use it.

Certificate Usage: which type to choose?

For SMTP (RFC 7672), only DANE-TA (2) and DANE-EE (3) are used. PKIX-TA (0) and PKIX-EE (1) exist in RFC 6698 but do not apply to opportunistic SMTP: MTAs rely on DNSSEC, not on PKIX validation.

By default, choose DANE-EE (3) with the SPKI (1) selector and SHA-256 (1) matching. It is the simplest and most robust option. DANE-TA (2) is an advanced choice subject to a chain constraint (see the deployment strategies).

Selector: Cert vs SPKI

SPKI (1) is recommended to reduce the frequency of DNS updates.

Matching Type: Full vs Hash

SHA-256 (1) is the standard. Full data (0) creates DNS records that exceed the 512-byte UDP limit, causing truncation and lookup failures. Avoid it for SMTP.

Prerequisite: DNSSEC

Publishing a TLSA record without DNSSEC wastes time. Every compliant MTA ignores unsigned TLSA records. Complete these steps first:

Verify DNSSEC

1. Check that your registrar supports DNSSEC
2. Enable DNSSEC signing at your DNS host
3. Add DS records at your registrar
4. Wait for propagation (can take 24-48h)

DNS providers with DNSSEC

Deployment strategies

Certificate renewal breaks DANE if you do not plan ahead. Choose a strategy that matches your automation level.

Scenario 1: Let's Encrypt with key reuse

The simplest approach for DANE-EE deployments. Reusing the private key keeps the SPKI hash constant.

# Generate with key reuse
certbot certonly --reuse-key -d mail.captaindns.com

# TLSA record (stable across renewals)
3 1 1 <sha256-spki>

Result: The TLSA record never changes. Zero DNS maintenance after initial setup.

Scenario 2: Let's Encrypt with DANE-TA (advanced option)

With DANE-TA (usage 2), the pinned certificate - or a certificate it signed - MUST be present in the TLS chain sent by the server (RFC 7671 section 5). But MTAs generally do NOT send the root certificate: pin the intermediate actually served (for example Let's Encrypt R10/R11), not the ISRG Root X1.

# Pin the intermediate actually sent by the server (e.g. R10/R11)
2 1 1 <sha256-spki-of-the-intermediate>

Warning: if you pin a root (ISRG Root X1), configure the server to include that certificate in the TLS chain, otherwise DANE-TA validation fails. When in doubt, prefer DANE-EE (3) + SPKI (1), which has no such chain constraint.

Result: No DNS updates needed as long as the intermediate stays unchanged in the chain.

Scenario 3: Rotation with dual records

Publish both records before rotating the certificate. Requires coordination but works with any key strategy.

_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <current-cert-hash>
_25._tcp.mail.captaindns.com.  TLSA  3 1 1 <future-cert-hash>

After rotation: Remove the old hash. Allow at least one TTL period before cleanup.

DNS publication by provider

Cloudflare

1. Go to your domain's DNS settings
2. Add a record:
   • Type: TLSA
   • Name: _25._tcp.mail
   • Usage: 3
   • Selector: 1
   • Matching Type: 1
   • Certificate: Your SHA-256 hash

AWS Route 53

1. Open the hosted zone
2. Create a record:
   • Name: _25._tcp.mail.captaindns.com
   • Type: TLSA
   • Value: 3 1 1 <hash>
   • TTL: 3600

OVH / Generic format

1. Go to the DNS zone
2. Add an entry:
   • Subdomain: _25._tcp.mail
   • Type: TLSA
   • Target: 3 1 1 <hash>
   • TTL: 3600

Best practices and common pitfalls

DANE is strict: a misconfiguration blocks incoming mail. Avoid these classic pitfalls.

• DNSSEC is mandatory: without a signed and validated zone, resolvers ignore the TLSA record and DANE becomes completely inoperative. This is the number one mistake.
• Additive rotation: publish the NEW TLSA record IN ADDITION to the old one, wait for DNS propagation and TTL expiry, then remove the old one only after the old certificate is decommissioned. Never delete the old one before the new one has propagated.
• Publish-then-deploy: publish and let the TLSA record propagate BEFORE switching the certificate on the server, never the other way around.
• SPKI survives renewal: with the SPKI (1) selector, as long as the same key is reused, the record stays valid after renewal, which reduces DNS updates. The Cert (0) selector forces a republish on every renewal.
• Match the served certificate: the TLSA record must match the certificate actually presented by the MX. A hostname/certificate mismatch causes validation to fail.

Complete email security with DANE

DANE protects one layer of email transport. Full protection requires three complementary protocols working together.

1. DANE (Certificate authentication via DNS)

Verifies the recipient server identity through DNSSEC-signed TLSA records. Prevents certificate forgery and MitM attacks.

• Use this generator to create your TLSA record
• Verify DANE deployment

2. MTA-STS (TLS enforcement via HTTPS)

Enforces TLS without requiring DNSSEC. Protects against senders that do not support DANE.

• Generate an MTA-STS policy
• Check MTA-STS

3. TLS-RPT (Failure reporting)

Collects TLS connection failure reports from both DANE and MTA-STS. Essential for detecting misconfigurations.

• Generate a TLS-RPT record
• Check TLS-RPT

Recommended deployment order

1. Enable DNSSEC on the domain
2. Publish TLSA records (DANE) - use this generator
3. Configure TLS-RPT to receive failure reports immediately
4. Add MTA-STS as a fallback for non-DANE senders
5. Monitor TLS-RPT reports weekly to catch certificate rotation issues

FAQ - Frequently asked questions

Q: How do I create a DANE TLSA record?

A: Use our generator: select the usage type (DANE-EE recommended), selector (SPKI for stability), matching type (SHA-256), and paste your PEM certificate. The tool generates the complete DNS record ready to publish.

Q: Which certificate usage should I choose for DANE?

A: For most SMTP deployments, DANE-EE (3) with SPKI selector and SHA-256 matching is recommended. For easier certificate rotation, use DANE-TA (2) with your CA certificate.

Q: Should I use the full certificate or a hash?

A: Always use a SHA-256 hash. Full data (matching type 0) creates very large DNS records with UDP truncation risks. SHA-256 produces a compact 64-character string.

Q: What is the SPKI selector?

A: The SPKI selector (1) hashes only the public key of the certificate. The TLSA record remains valid when you renew with the same key pair, unlike the Cert selector (0) which changes on every renewal.

Q: How do I deploy a DANE TLSA record?

A: 1) Enable DNSSEC, 2) Add the TLSA at _25._tcp.yourmailserver, 3) Wait for DNS propagation, 4) Verify with our DANE TLSA Checker. The record must be DNSSEC-signed.

Q: How do I handle Let's Encrypt renewals with DANE?

A: Two strategies: DANE-TA (usage 2) with the Let's Encrypt CA certificate automatically survives renewals. DANE-EE (usage 3) with SPKI selector and --reuse-key in Certbot works too.

Complementary tools

Useful resources

• RFC 6698 - DANE TLSA (original specification)
• RFC 7671 - Updates to DANE (operational updates)
• RFC 7672 - SMTP Security via DANE (DANE for SMTP)
• Certbot - Reuse Key (key reuse for DANE)
• Microsoft - DANE with DNSSEC (Exchange Online guide)