DANE & TLSA Records Guide [2026]

What Is DANE (DNS-Based Authentication of Named Entities)?

DANE (DNS-Based Authentication of Named Entities) is a protocol that publishes TLS certificate information directly in DNS, secured by DNSSEC. For email, DANE lets receiving servers verify your mail server’s certificate without relying on traditional certificate authorities (CAs).

Unlike the standard Web PKI model where hundreds of CAs can issue certificates for any domain, DANE gives you precise control: you pin your exact certificate (or CA) in DNS, and only that certificate will be trusted. This eliminates CA compromise risks and prevents man-in-the-middle attacks that exploit TLS downgrade vulnerabilities.

DANE for email is defined in RFC 7672 (SMTP Security via Opportunistic DNS-Based Authentication of Named Entities Using DANE). The underlying TLSA record format comes from RFC 6698.

Why DANE Matters: Certificate Pinning for Email

The traditional CA model has a fundamental weakness: any trusted CA can issue a certificate for your domain. If a CA is compromised, misconfigured, or coerced by an attacker, they could obtain a fraudulent certificate for mail.yourdomain.com and intercept your email traffic.

DANE solves this with certificate pinning: you publish a cryptographic fingerprint of your mail server’s certificate in DNS. When a sending server connects via TLS, it retrieves your TLSA record through DNSSEC, verifies your certificate matches the published fingerprint, and refuses delivery if verification fails.

This provides two critical protections:

1. CA bypass: With DANE-EE (end-entity) mode, you can use a self-signed certificate. No CA is involved, eliminating CA compromise risk entirely.
2. Mandatory TLS: If a valid TLSA record exists, TLS becomes mandatory. Attackers cannot downgrade to plaintext SMTP.

DANE also solves the same TLS downgrade problem as MTA-STS, but uses a fundamentally different trust model.

How DANE Works (RFC 7672)

When a mail server wants to send email to your domain, here’s what happens:

1. MX lookup: The sender queries your domain’s MX records to find your mail server hostname (e.g., mail.example.com).
2. TLSA lookup: The sender performs a DNSSEC-validated query for _25._tcp.mail.example.com. to retrieve your TLSA record.
3. TLS connection: The sender connects to your mail server on port 25 and initiates STARTTLS.
4. Certificate verification: Your server presents its TLS certificate. The sender verifies it matches the TLSA record constraints.
5. Delivery decision: If verification succeeds, mail is delivered. If it fails, delivery is refused (no fallback to plaintext).

The MX hostname’s TLSA record is checked, not the envelope domain’s. If your MX record points to mail.yourdomain.com, you publish the TLSA record at _25._tcp.mail.yourdomain.com, not _25._tcp.yourdomain.com.

The TLSA Record: Field-by-Field Breakdown

A TLSA record is published at _port._protocol.hostname in DNS. For SMTP on port 25:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 abc123...

The record contains four fields:

Usage Field (Certificate Usage)

The usage field determines how the certificate is verified:

• 0 (PKIX-TA): Certificate must chain to the specified trust anchor (CA) AND be valid per PKIX rules. Not recommended for email.
• 1 (PKIX-EE): Certificate must match the specified end-entity certificate AND be valid per PKIX rules.
• 2 (DANE-TA): Certificate must chain to the specified trust anchor (CA). PKIX validation is skipped.
• 3 (DANE-EE): Certificate must match the specified end-entity certificate. PKIX validation is skipped. This is the most common configuration for email and allows self-signed certificates.

For email, usage 3 (DANE-EE) is recommended. It pins your exact certificate or public key, doesn’t require a trusted CA, and gives you complete control.

Selector Field

The selector determines what certificate data is matched:

• 0 (Full certificate): Match the entire X.509 certificate (DER-encoded).
• 1 (SubjectPublicKeyInfo): Match only the public key. Recommended because it survives certificate renewal as long as the key pair stays the same.

Recommendation: Use selector 1 to match the public key. This lets you renew your certificate (updating expiry, organization name, etc.) without updating the TLSA record, as long as you keep the same key pair.

Matching Type

The matching type specifies how the certificate data is represented:

• 0 (No hash): Full certificate or key data (DER-encoded). Not recommended due to DNS record size limits.
• 1 (SHA-256): SHA-256 hash of the certificate or key. Recommended.
• 2 (SHA-512): SHA-512 hash of the certificate or key. Stronger but larger DNS record.

Recommendation: Use matching type 1 (SHA-256). It’s widely supported, fits comfortably in DNS, and provides sufficient collision resistance.

Certificate Data

The final field is the hex-encoded hash (or full data if matching type is 0) of the certificate or public key, depending on the selector.

TLSA Record Examples

Here are real-world TLSA configurations:

Example 1: DANE-EE with SHA-256 Public Key (Recommended)

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b566 64c5d3d6

• Usage 3 (DANE-EE): Certificate must match exactly; no CA verification.
• Selector 1: Match the public key only.
• Matching 1: SHA-256 hash.
• Data: SHA-256 hash of the server’s public key.

This is the most common configuration for SMTP. It allows self-signed certificates, pins the public key (so certificate renewals don’t break DANE as long as you keep the same key), and uses SHA-256 for a compact record.

To generate this record from your certificate:

openssl x509 -in /etc/ssl/certs/mail.example.com.crt -noout -pubkey | \
openssl pkey -pubin -outform DER | \
openssl dgst -sha256 -binary | \
xxd -p -u -c 32

Example 2: DANE-TA with CA Public Key

_25._tcp.mail.example.com. 3600 IN TLSA 2 1 1 d4de20d05e66fc53fe1a50882c78db2852f1cdbc2d05f8f0e7e0c0c3 dffdb3c3

• Usage 2 (DANE-TA): Certificate must chain to the specified CA.
• Selector 1: Match the CA’s public key.
• Matching 1: SHA-256 hash.
• Data: SHA-256 hash of the CA’s public key.

This configuration is useful if you use an internal CA or want to pin a specific trusted CA (like Let’s Encrypt) instead of trusting all CAs. Any certificate issued by that CA will be accepted.

Example 3: Full Certificate Match (Not Recommended)

_25._tcp.mail.example.com. 3600 IN TLSA 3 0 0 308202a4308201...

• Usage 3: DANE-EE (exact match).
• Selector 0: Full certificate.
• Matching 0: No hash (full DER-encoded certificate).

This pins the full certificate. You must update the TLSA record every time you renew your certificate, even if the key doesn’t change. DNS record size can also become an issue. Avoid this unless you have a specific reason.

DANE and DNSSEC: Why Both Are Required

DANE’s security depends entirely on DNSSEC. Without DNSSEC, an attacker can perform a man-in-the-middle attack by:

1. Intercepting the TLSA DNS query.
2. Returning a forged TLSA record matching their fraudulent certificate.
3. Intercepting the TLS connection with their certificate.

The sending server would accept the connection because the (forged) TLSA record matches the (fraudulent) certificate.

DNSSEC prevents this by cryptographically signing DNS records. When a DANE-aware mail server queries your TLSA record, it:

1. Validates the DNSSEC chain of trust from the root zone to your domain.
2. Verifies the TLSA record’s signature using your DNSSEC public key (published in a DNSKEY record).
3. Rejects the record if DNSSEC validation fails.

All conforming DANE implementations ignore unsigned TLSA records. If you publish a TLSA record without DNSSEC, it will be invisible to DANE-aware senders.

Setting up DNSSEC requires support from your DNS hosting provider and domain registrar. Both must support DNSSEC signing and DS record publication. This is the primary barrier to DANE adoption — DNSSEC requires coordination between your registrar and DNS host, and not all providers offer it yet. Check with both before planning a DANE deployment. If DNSSEC is not available, MTA-STS provides TLS enforcement without DNSSEC.

How to Set Up DANE for Email

Here’s a step-by-step guide to implementing DANE for your mail server:

1. Enable DNSSEC on Your Domain

Before you can use DANE, your domain must have DNSSEC enabled. Check with your DNS hosting provider and domain registrar:

• DNS hosting provider: Must support DNSSEC signing (e.g., Cloudflare, Route 53, Google Cloud DNS).
• Domain registrar: Must support publishing DS records in the parent zone.

Most modern DNS providers auto-sign records when you enable DNSSEC. You’ll need to copy the DS record from your DNS provider and add it to your domain registrar’s control panel.

Verify DNSSEC is working:

dig +dnssec yourdomain.com

Look for the ad (authenticated data) flag in the response and a RRSIG record.

2. Generate Your TLSA Record

Get your mail server’s TLS certificate and extract the public key hash, or use our TLSA record generator to create one without the command line:

# For DANE-EE 3 1 1 (SHA-256 of public key)
openssl x509 -in /path/to/mail.example.com.crt -noout -pubkey | \
openssl pkey -pubin -outform DER | \
openssl dgst -sha256 -binary | \
xxd -p -u -c 32

This outputs a hex string like:

0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

3. Publish the TLSA Record in DNS

Add a TLSA record to your DNS zone at _25._tcp.<your-mx-hostname>:

_25._tcp.mail.yourdomain.com. 3600 IN TLSA 3 1 1 0c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6

Replace mail.yourdomain.com with your actual MX hostname. The TTL (3600 seconds / 1 hour) is recommended; shorter TTLs are fine during testing.

4. Configure Your Mail Server

Ensure your mail server:

• Supports STARTTLS on port 25.
• Presents the certificate matching the TLSA record.
• Preferably validates DANE on outbound mail (so you benefit from others’ DANE configurations).

For Postfix, enable DANE with:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

5. Test Your DANE Configuration

Use a DANE validation tool to verify:

# Using swaks (Send Mail Swiss Army Knife)
swaks --to [email protected] --from [email protected] \
  --server mail.yourdomain.com --tls --tls-verify-name

# Or use an online DANE checker
# (Link to DMARCguard's TLSA checker when available)

Check TLS-RPT reports from receiving domains to identify DANE failures.

DANE vs MTA-STS: When to Use Which

DANE and MTA-STS solve the same problem (TLS downgrade attacks) with different trust models:

When to Use DANE

• You already have DNSSEC enabled or are willing to deploy it.
• You want cryptographic certificate pinning without CA dependencies.
• You prefer self-signed certificates (common for internal or high-security mail servers).
• You send to or receive from organizations that validate DANE (banks, governments, EU entities under NIS2).

When to Use MTA-STS

• Your DNS provider or registrar doesn’t support DNSSEC.
• You want faster deployment (MTA-STS requires only HTTPS, no DNSSEC).
• You use certificates from a public CA (Let’s Encrypt, DigiCert) and don’t need pinning.
• You need broader sender support (Gmail, Yahoo, Outlook all validate MTA-STS).

Can You Use Both?

Yes, and many organizations do. DANE-aware senders will use DANE; those that don’t will fall back to MTA-STS. This provides defense-in-depth:

• DANE for senders that validate it (stronger security).
• MTA-STS for everyone else (broader compatibility).

Both DANE and MTA-STS failures are reported via TLS-RPT, giving you visibility into TLS issues.

DANE and the NIS2 Directive

The EU NIS2 Directive (effective October 2024) requires “essential entities” and “important entities” to implement “appropriate technical measures” for email security. While NIS2 doesn’t explicitly mandate DANE, it recommends transport security measures including:

• Mandatory TLS for email (via MTA-STS or DANE).
• Certificate validation (DANE’s primary purpose).
• DNSSEC for DNS integrity (DANE’s prerequisite).

Organizations subject to NIS2 should implement MTA-STS at minimum. DANE provides additional defense-in-depth and may be required depending on your national implementing legislation. If your domain already has DNSSEC, adding DANE is straightforward and strongly recommended.

Outside the EU, industries like finance and healthcare increasingly require transport security. See how DANE fits into PCI DSS 4.0 email requirements for payment card environments. DANE is recognized by NIST, CISA, and the UK NCSC as a best practice for high-security email.

Provider Support for DANE

DANE support varies by mail server software and hosting provider:

Mail Server Software

Email Hosting Providers

Most major email hosting providers (Gmail, Google Workspace, Microsoft 365) do not publish DANE/TLSA records for their mail servers. They rely on MTA-STS instead. However:

• Google Workspace: Does not validate DANE on inbound mail but will accept DANE-protected connections.
• Microsoft 365 / Exchange Online: Validates DANE on inbound mail (since 2024) but does not publish TLSA records for outbound.
• Fastmail: Publishes TLSA records and validates DANE.
• Proton Mail: Publishes TLSA records and validates DANE.

If you self-host or use a provider that supports DANE, you can deploy it. If you use Google Workspace or Microsoft 365, focus on MTA-STS instead.

How to Verify Your DANE/TLSA Configuration

DNS Query Test

Check if your TLSA record is published and DNSSEC-signed:

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

You should see:

• A TLSA record with your 3 1 1 data.
• A RRSIG record (DNSSEC signature).
• The ad (authenticated data) flag in the response header.

If the ad flag is missing, DNSSEC validation failed. Check your DNSSEC configuration.

DANE Validator Tools

Use DMARCguard’s DANE checker or a command-line tool:

# Using dane-check (from the dane-tools package)
dane-check mail.yourdomain.com 25

# Or use DMARCguard's TLSA checker (when available)

Send a Test Email

Send an email from a DANE-aware server (e.g., your own Postfix instance with DANE enabled) to your domain. Check the Postfix logs for DANE validation results:

postfix/smtp[12345]: Verified TLS connection established to mail.yourdomain.com[192.0.2.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256; matched DANE TLSA 3 1 1 ...

The matched DANE TLSA 3 1 1 confirms DANE verification succeeded.

Monitor TLS-RPT Reports

Configure TLS-RPT to receive reports of DANE failures from sending domains. If DANE validation is failing, you’ll see tlsa-invalid or certificate-not-trusted failure types in the reports.

Common DANE Issues and Troubleshooting

TLSA Record Doesn’t Match Certificate

Symptom: Sending servers refuse delivery with “DANE verification failed” errors.

Cause: Your TLSA record was generated from an old certificate, or you renewed your certificate without updating the TLSA record.

Fix: Regenerate the TLSA record from your current certificate (step 2 above) and update DNS. Use selector 1 (public key) to avoid this issue when renewing certificates with the same key pair.

DNSSEC Validation Fails

Symptom: dig +dnssec shows no ad flag or returns SERVFAIL.

Cause: DNSSEC chain of trust is broken (missing DS record, expired signatures, clock skew).

Fix:

1. Verify your DNS provider’s DNSSEC signing is active.
2. Check the DS record is published at your registrar.
3. Validate the DNSSEC chain with dig +trace +dnssec yourdomain.com.
4. Ensure your server’s clock is accurate (DNSSEC signatures have validity periods).

Wrong Port in TLSA Record

Symptom: DANE validation fails even though the certificate is correct.

Cause: You published the TLSA record at _443._tcp.mail.yourdomain.com (HTTPS) instead of _25._tcp.mail.yourdomain.com (SMTP).

Fix: SMTP uses port 25. The TLSA record must be at _25._tcp.<your-mx-hostname>. Port 443 is only for HTTPS services.

TLSA Record at Wrong Hostname

Symptom: DANE validation fails; no TLSA record found.

Cause: You published the TLSA record at _25._tcp.yourdomain.com but your MX record points to mail.yourdomain.com.

Fix: The TLSA record must match the MX hostname. If your MX is mail.yourdomain.com, publish the TLSA at _25._tcp.mail.yourdomain.com.

Mail Server Doesn’t Support STARTTLS

Symptom: DANE validation fails with “TLS not available” errors.

Cause: Your mail server isn’t offering STARTTLS on port 25.

Fix: Configure your mail server to support STARTTLS. For Postfix, ensure smtpd_tls_cert_file and smtpd_tls_key_file are set.

Fallback to Opportunistic TLS

Symptom: Mail is delivered, but DANE isn’t being validated.

Cause: Sending servers may not support DANE, or your DNSSEC/TLSA record is invalid so they fall back to opportunistic TLS (if MTA-STS is also absent).

Fix: This is expected behavior. DANE is not universally supported. Monitor TLS-RPT reports to see which senders validate DANE. Consider deploying MTA-STS for broader coverage.

Frequently Asked Questions

What is a TLSA record?

A TLSA record is a DNS record type that binds a TLS certificate or public key to a specific service (like a mail server). For email, it’s published at _25._tcp.mail.example.com. and contains four fields: usage (how to verify), selector (what to match), matching type (hash algorithm), and the certificate or key fingerprint itself.

How do I set up DANE for email?

To set up DANE, first enable DNSSEC on your domain. Then generate a TLSA record from your mail server’s certificate using OpenSSL, publish it in DNS at _25._tcp.<your-mx-hostname>, and test with a DANE validation tool. Your mail server must support TLS and present a valid certificate.

What is the difference between DANE and MTA-STS?

DANE uses DNSSEC to verify certificates, allowing self-signed certificates with DANE-EE mode. MTA-STS uses HTTPS for trust and requires certificates signed by a trusted CA. DANE offers stronger cryptographic guarantees but requires DNSSEC, which is harder to deploy. MTA-STS has lower deployment barriers but relies on the Web PKI trust model.

Does DANE require DNSSEC?

Yes. DANE’s security depends entirely on DNSSEC. Without DNSSEC, an attacker could forge TLSA records via DNS spoofing, making DANE worthless. All conforming implementations ignore TLSA records that aren’t validated by DNSSEC.

Does my email provider support DANE?

Major providers like Microsoft Exchange Online (since 2024), Postfix, and Exim support DANE. Gmail and Google Workspace do not currently validate DANE on inbound mail but will accept DANE-protected connections. Check your provider’s documentation or test with a DANE-enabled mail server to verify support.

Is DANE required for NIS2 compliance?

The EU NIS2 Directive recommends DANE as part of email security best practices, but it’s not explicitly mandatory. Organizations subject to NIS2 should implement MTA-STS at minimum; DANE provides additional defense-in-depth and may be required depending on your national implementing legislation.

Can you use DANE without DNSSEC?

No. DANE fundamentally requires DNSSEC. Without DNSSEC, TLSA records cannot be authenticated, and any conforming mail server will ignore them. There is no way to deploy DANE without first enabling DNSSEC on your domain. If DNSSEC is not an option, use MTA-STS as an alternative for TLS enforcement.

Related Protocols

• MTA-STS — Alternative TLS enforcement using HTTPS instead of DNSSEC
• TLS-RPT — Reports DANE verification failures and TLS issues
• DMARC — Authentication at the message level (DANE operates at the transport level)