DANE and TLSA Records: Pinning TLS Certificates in DNS for Stronger Email Security
DANE uses TLSA DNS records to pin TLS certificates, preventing CA compromise and MITM attacks on email. Learn how DANE works and when to deploy it.
What is DANE?
DNS-based Authentication of Named Entities (DANE) is a protocol that uses DNS to specify which TLS certificate a server should present. Instead of relying solely on the public Certificate Authority (CA) system, DANE lets domain owners publish a TLSA record in DNS that says: "When you connect to this server over TLS, you should see this specific certificate (or a certificate signed by this specific CA)."
DANE solves a fundamental weakness in the CA system: any of the hundreds of publicly trusted CAs can issue a certificate for any domain. If a single CA is compromised, hacked, or coerced, an attacker can obtain a valid certificate for your domain and intercept traffic. DANE eliminates this by tying trust to your DNS, not to the entire CA ecosystem.
How DANE works
DANE relies on two components working together:
-
DNSSEC -- DNS Security Extensions that cryptographically sign DNS records, ensuring they cannot be tampered with in transit. DANE without DNSSEC is meaningless because an attacker who can modify DNS responses can modify the TLSA record too. See our DNSSEC guide for details.
-
TLSA records -- DNS records published in the zone that specify the expected TLS certificate parameters.
A TLSA record looks like this:
_443._tcp.www.yourcompany.com. IN TLSA 3 1 1 a]b2c3d4e5f6...
The format is _port._protocol.hostname with four fields:
- Certificate Usage (3) -- how to use the certificate data (0-3)
- Selector (1) -- what part of the certificate to match (0 = full cert, 1 = public key only)
- Matching Type (1) -- how to match (0 = exact, 1 = SHA-256 hash, 2 = SHA-512 hash)
- Certificate Association Data -- the hash or certificate data to match against
Certificate usage values
| Value | Name | Meaning |
|---|---|---|
| 0 | PKIX-TA | Must chain to a specific CA and pass normal CA validation |
| 1 | PKIX-EE | Must be a specific end-entity cert and pass CA validation |
| 2 | DANE-TA | Must chain to a specific trust anchor (CA validation not required) |
| 3 | DANE-EE | Must be a specific end-entity cert (CA validation not required) |
Usage 3 (DANE-EE) is the most common because it provides the strongest guarantee: only this exact certificate is valid, regardless of what any CA says.
Where DANE is most useful: email
DANE's primary real-world deployment is in SMTP (email) rather than HTTPS. Here is why:
The SMTP encryption problem
When your mail server sends email to another mail server, it connects over SMTP and attempts to upgrade to TLS using STARTTLS. But STARTTLS is opportunistic by default -- if the TLS negotiation fails, the connection falls back to unencrypted. An attacker performing a man-in-the-middle attack can simply strip the STARTTLS response and force plaintext.
Even when STARTTLS succeeds, the sending server typically does not verify the receiving server's certificate (because there is no reliable way to know which certificate to expect). This means an attacker with any valid-looking certificate can intercept the encrypted connection.
How DANE fixes this
With DANE, the sending mail server:
- Looks up the MX record for the recipient's domain
- Looks up the TLSA record for the MX host
- Verifies the TLSA record is DNSSEC-signed
- Connects to the MX host and verifies its TLS certificate matches the TLSA record
- If the certificate does not match, refuses to deliver (no fallback to plaintext)
This provides authenticated, encrypted email delivery with no CA dependency.
Deploying DANE for your mail server
Prerequisites
- DNSSEC must be enabled for your domain -- DANE without DNSSEC provides no security
- Your mail server must have a valid TLS certificate (see TLS certificate chain issues)
- Your DNS provider must support TLSA records
Step 1: Enable DNSSEC
If your domain does not have DNSSEC, enable it first. This is a prerequisite, not optional.
Step 2: Generate the TLSA record
# Generate a TLSA record for your mail server's certificate
# Usage 3, Selector 1 (public key), Matching type 1 (SHA-256)
openssl x509 -in /etc/letsencrypt/live/mx1.yourcompany.com/cert.pem -noout -pubkey | \
openssl pkey -pubin -outform DER | \
openssl dgst -sha256 -binary | \
xxd -p -c 64
This outputs a hex string that becomes your TLSA record data.
Step 3: Publish the TLSA record
_25._tcp.mx1.yourcompany.com. IN TLSA 3 1 1 a1b2c3d4e5f6...your-hash-here
The record goes under _25._tcp. because SMTP uses port 25.
Step 4: Verify
# Check that the TLSA record is published and DNSSEC-signed
dig TLSA _25._tcp.mx1.yourcompany.com +dnssec
# Use a DANE validator
# https://dane.sys4.de/ (web-based DANE SMTP validator)
Certificate renewal considerations
When you renew your TLS certificate, the TLSA record must be updated. If you use selector 1 (public key) and your renewal keeps the same key pair, the TLSA record remains valid. If the key changes, you must update the TLSA record before deploying the new certificate.
Best practice: publish two TLSA records during certificate rotation -- one for the current certificate and one for the new one. Remove the old record after the new certificate is live and the DNS TTL has expired.
; Current certificate
_25._tcp.mx1.yourcompany.com. IN TLSA 3 1 1 current-cert-hash
; Next certificate (pre-published)
_25._tcp.mx1.yourcompany.com. IN TLSA 3 1 1 next-cert-hash
DANE adoption and support
DANE adoption is growing but not universal:
- Mail servers with DANE support: Postfix (built-in), Exim (built-in), Halon, PowerMTA
- Providers honouring DANE: Many European ISPs, government mail servers, and privacy-focused providers check DANE when sending
- Major providers: Gmail has been rolling out DANE support. Microsoft 365 supports outbound DANE verification
- Regions: DANE is particularly well-adopted in the Netherlands, Germany, and the Nordic countries, where government and ISP mandates have driven deployment
Even if not all senders check your DANE records yet, publishing them protects the connections that do check -- and adoption is increasing.
DANE vs MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) is an alternative to DANE that does not require DNSSEC. It uses an HTTPS-hosted policy file to declare that a domain's mail servers support TLS.
| Feature | DANE | MTA-STS |
|---|---|---|
| Requires DNSSEC | Yes | No |
| Certificate pinning | Yes | No (trusts any valid CA cert) |
| Prevents CA compromise | Yes | No |
| Easier to deploy | No (needs DNSSEC) | Yes |
| Supported by Gmail | Growing | Yes |
| Supported by Microsoft | Yes (outbound) | Yes |
If you can deploy DNSSEC, DANE provides stronger security. If DNSSEC is not feasible, MTA-STS is a worthwhile alternative. They can also be deployed together.
How SurfaceScan helps
SurfaceScan checks for TLSA records on all your mail servers and validates them against the actual TLS certificates being served. It detects missing TLSA records on DNSSEC-enabled domains (where DANE should be deployed), mismatched TLSA records that would cause delivery failures, and TLSA records published without DNSSEC (which provides no security). The Email Security section shows your DANE deployment status alongside SPF, DKIM, and DMARC.
Related articles
MX Record Security: Misconfigured Mail Routing and Its Risks
Misconfigured MX records can send your email to the wrong server or let attackers intercept it. Learn how to check, fix, and secure your mail routing.
TLS Certificate Chain Issues: Incomplete Chains, Wrong Intermediates, and How to Fix Them
Incomplete TLS certificate chains cause trust errors in some browsers but not others. Learn how to diagnose chain problems and fix them on Nginx and Apache.