DANE (DNS-based Authentication of Named Entities)

DANE uses DNSSEC to provide certificate authentication for email transport security, enabling encrypted and authenticated connections between mail servers.

How DANE Works

The Problem

Traditional TLS for email (STARTTLS) has vulnerabilities:

1. Opportunistic encryption: Falls back to unencrypted if TLS fails
2. No certificate verification: Accepts any certificate by default
3. Vulnerable to MITM: Attackers can downgrade or intercept connections

The Solution

DANE addresses these issues by:

1. Publishing certificates in DNS: TLSA records specify expected certificates
2. Using DNSSEC: Cryptographically signs DNS records
3. Enabling verification: Sending servers check that your mail server's certificate matches the TLSA record

Sender MTA                                  Receiver MTA
    │                                           │
    │  1. Query MX record                       │
    ├──────────────────────────────────────────►│
    │                                           │
    │  2. Query TLSA record (with DNSSEC)       │
    ├──────────────────────────────────────────►│
    │                                           │
    │  3. Connect with TLS                      │
    ├──────────────────────────────────────────►│
    │                                           │
    │  4. Verify certificate matches TLSA       │
    │                                           │

TLSA Record Format

TLSA records are published at:

_port._protocol.hostname

For SMTP (port 25):

_25._tcp.mail.example.com

Record Structure

_25._tcp.mail.example.com. IN TLSA 3 1 1 <certificate-hash>

Field	Position	Description
Usage	1st	How to use the certificate data
Selector	2nd	Which part of certificate to match
Matching Type	3rd	How to match (exact or hash)
Certificate Data	4th	The actual certificate data or hash

Usage Values

Value	Name	Description
0	PKIX-TA	CA constraint (must chain to this CA)
1	PKIX-EE	Certificate constraint (must be this cert)
2	DANE-TA	Trust anchor (domain-issued CA)
3	DANE-EE	Domain-issued end entity (recommended)

TIP

For email, 3 (DANE-EE) is recommended. It pins the exact certificate without requiring traditional CA validation.

Selector Values

Value	Name	Description
0	Full	Match entire certificate
1	SPKI	Match public key only (recommended)

TIP

1 (SPKI) is recommended because it survives certificate renewal if the same key is reused.

Matching Type Values

Value	Name	Description
0	Full	Exact match (no hashing)
1	SHA-256	SHA-256 hash (recommended)
2	SHA-512	SHA-512 hash

Example TLSA Records

Recommended configuration (3 1 1):

_25._tcp.mail.example.com. IN TLSA 3 1 1 a1b2c3d4e5f6...

Full certificate pin (3 0 1):

_25._tcp.mail.example.com. IN TLSA 3 0 1 1a2b3c4d5e6f...

When DANE Adds Value

Good Use Cases

✅ Use DANE when:

• You control your mail server infrastructure
• DNSSEC is already deployed for your domain
• You need cryptographic assurance of TLS connection authenticity
• Your receiving partners support DANE verification
• High-security environments requiring defense in depth

Limited Value

⚠️ DANE has limited value when:

• Using hosted email (Google Workspace, Microsoft 365)
• DNSSEC is not deployed
• Most email partners don't verify DANE
• MTA-STS already covers your requirements

DANE vs. MTA-STS

Feature	DANE	MTA-STS
Requires DNSSEC	Yes	No
Certificate pinning	Yes	No (uses CA trust)
Adoption by senders	Lower	Higher
Setup complexity	Higher	Lower
Hosted email support	Limited	Good

Recommendation: Most organizations should implement MTA-STS first. Add DANE if you have DNSSEC and need additional assurance.

DANE and MTA-STS Interaction

DANE and MTA-STS can work together:

1. Both present: A sender that supports both uses DANE when your TLSA records validate
2. Only MTA-STS: The sender applies the MTA-STS policy
3. Only DANE: The sender verifies the certificate against your TLSA records
4. Neither: Opportunistic TLS only

Support differs between providers: some large providers validate DANE, others only MTA-STS. Publishing both covers the most senders.

Implementation Steps

Prerequisites

Before implementing DANE:

• [ ] DNSSEC must be deployed and validated for your domain
• [ ] You control your mail server's TLS certificates
• [ ] You have a process for updating TLSA records during certificate rotation

Step 1: Verify DNSSEC

Check if DNSSEC is active for the zone that holds your MX host names:

delv mail.example.com

; fully validated means the chain of trust checks out. See DNSSEC.

Step 2: Generate TLSA Record

The quickest route is the MailShield TLSA Record Generator. Enter your domain and it connects to each of your MX hosts, reads the certificate they are actually serving, and gives you the record to publish. You do not need to find or paste a certificate, and because it reads the live certificate it can also tell you whether any TLSA records you already publish still match.

The same page has a second tool that builds a record from a certificate you paste, with full control over the usage, selector, matching type, port and transport. Use that one for a certificate that is not deployed yet, or for services other than SMTP on port 25.

To do it yourself, extract the hash with openssl:

# For the public key (selector 1) with SHA-256 (matching type 1)
openssl x509 -in cert.pem -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p -c 256

Step 3: Publish TLSA Record

Add the record to your DNS:

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 <hash-from-step-2>

Step 4: Test Configuration

Using dig:

dig TLSA _25._tcp.mail.example.com +dnssec

Using online validators:

• DANE SMTP Validator tools
• Hardenize (https://hardenize.com)

Step 5: Monitor

• Monitor for DNSSEC validation issues
• Set reminders for certificate renewal
• Update TLSA records before certificates expire

Certificate Rotation

WARNING

DANE requires careful certificate rotation planning. Publishing new TLSA records before certificate rollover is critical.

Rotation Process

1. Generate new certificate (with same or new key)
2. Calculate new TLSA hash
3. Publish both old and new TLSA records:

_25._tcp.mail.example.com. IN TLSA 3 1 1 <old-hash>
_25._tcp.mail.example.com. IN TLSA 3 1 1 <new-hash>

4. Wait for DNS propagation (at least 2x TTL)
5. Deploy new certificate
6. Remove old TLSA record (after old cert expires)

Automation

Consider automating TLSA updates with certificate management tools:

• Let's Encrypt with DANE plugins
• Certificate management systems with DNS API integration

Testing and Validation

Manual Testing

Check TLSA record:

dig TLSA _25._tcp.mail.example.com +short

Test with OpenSSL:

openssl s_client -connect mail.example.com:25 -starttls smtp

Online Validators

• Hardenize: Comprehensive email security test including DANE
• Internet.nl: Dutch internet standards test
• DANE SMTP Validator: Specialized DANE testing

Common Validation Errors

Error	Cause	Solution
No TLSA record found	Record not published or wrong name	Verify record exists at correct location
DNSSEC validation failed	DNSSEC not configured or broken	Fix DNSSEC chain
Certificate mismatch	Hash doesn't match current cert	Update TLSA record with current hash
Usage/selector mismatch	Wrong TLSA parameters	Verify parameters match your setup

DANE for Hosted Email

With hosted email, your MX host names live in the provider's DNS zone, so only the provider can publish TLSA records for them. You can't add DANE for those hosts yourself.

• Microsoft 365 offers inbound DANE for domains that use its DNSSEC-signed MX host names (ending in mx.microsoft). Check Microsoft's documentation for the current setup.
• Other providers: ask whether they publish TLSA records for their MX hosts, and whether they validate DANE when sending.

MailShield's TLSA generator (below) names your provider and shows whether it already publishes TLSA records for your MX hosts.

Best Practices

Do

✅ Deploy DNSSEC before DANE
✅ Use parameters 3 1 1 (DANE-EE, SPKI, SHA-256)
✅ Plan certificate rotation carefully
✅ Monitor DNSSEC validation status
✅ Test after any DNS or certificate changes

Don't

❌ Deploy DANE without DNSSEC
❌ Forget to update TLSA records before certificate rollover
❌ Use short TTLs that cause validation issues
❌ Ignore DANE validation failures in monitoring

MailShield and DANE

MailShield monitors your DANE configuration:

1. TLSA record detection: Identifies published TLSA records
2. Validation checks: Verifies that the records match the certificate each MX host serves
3. Expiry monitoring: The Certificate expiry alert warns you 14 days before an MX certificate expires
4. Security scoring: DANE is worth 5 points for domains that send and receive mail and 10 for receive-only domains. See Security Score

Record generation

The Checks → MX page of each domain includes a TLSA record generator built from the certificate your mail servers are currently serving. It tells you which hosts can use DANE and which cannot, and why:

• Unsigned zone: TLSA records only work if the zone holding the record is DNSSEC-signed. This is the zone of the MX hostname, which is often not the same zone as your domain, so MailShield checks it separately.
• Provider-managed hosts: If your mail is handled by a provider such as Microsoft 365 or Google Workspace, TLSA records have to live in that provider's zone. MailShield names the provider and reports whether they already publish TLSA records for the host.
• Different certificates per address family: If a host serves one certificate over IPv4 and another over IPv6, a single TLSA record can only match one of them, so publishing one would break delivery over the other.

Rollover warnings

Because a 3 1 1 record pins your public key, MailShield warns you before a renewal breaks delivery rather than only after:

• Single pin nearing expiry: If a host publishes exactly one TLSA record and its certificate expires within 30 days, you are alerted. A renewal that generates a new key would break inbound mail the moment it is installed.
• Live mismatch: If the published records no longer match the served certificate, DANE-validating senders are already refusing delivery, and this is reported as a critical finding.

Related Topics

• MTA-STS - Alternative/complementary transport security
• TLS-RPT - Reporting for TLS failures
• DNSSEC - Required prerequisite for DANE