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: Receiving servers can verify sender certificates

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 a]b2c3d4e5f6...

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: Sender should prefer DANE if it validates
2. Only MTA-STS: Use MTA-STS policy
3. Only DANE: Use DANE verification
4. Neither: Opportunistic TLS only

Most major email providers check both when available.

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:

dig +dnssec example.com

Look for the ad (authenticated data) flag in the response.

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

Google Workspace

Google publishes DANE records for their mail servers. As a Google Workspace user:

• You benefit from DANE when sending to DANE-enabled receivers
• You cannot publish TLSA records for Google's MX servers

Microsoft 365

Microsoft supports DANE verification when sending. For receiving:

• DANE support for Microsoft 365 custom domains is limited
• Check Microsoft documentation for current status

Other Providers

Check with your email provider for:

• DANE sending verification support
• DANE receiving (TLSA publishing) options

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 DNSSEC and certificate matching
3. Expiry monitoring: Alerts on upcoming certificate expirations
4. Security scoring: DANE configuration contributes to your security score

Record generation

The MX tab 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