DANE and TLSA Records for Email: The Advanced Transport Security Layer Beyond MTA-STS

Most discussions of email transport security in 2026 stop at MTA-STS. That covers the majority of senders correctly: MTA-STS rides on HTTPS, requires no DNSSEC, and provides reasonable assurance that messages travel encrypted between mail servers. But for senders who need stronger guarantees, particularly in regulated industries or large enterprises with adversarial threat models, DANE is the layer that comes next.

DANE has existed as a standard since 2012 (RFC 6698 for general DANE, RFC 7672 for SMTP-specific DANE). For most of that time it was a niche security feature used by Google, GMX, Comcast, and a handful of European providers. In 2026, Microsoft enabling DANE inbound support across Exchange Online changed the calculus. Now meaningful enterprise email traffic flows through DANE-validated paths, and senders who deploy DANE on their own infrastructure benefit from broader downstream compatibility.

This guide explains exactly how DANE works for SMTP, how it differs from MTA-STS, how to publish TLSA records correctly, and the operational discipline DANE requires that most teams underestimate.

Why Transport Security Matters Beyond Authentication

SPF, DKIM, and DMARC protect the integrity and authenticity of email content. They do not protect the privacy of the transport channel. Without transport security, a message can travel between mail servers in cleartext across the public internet, and anyone with access to the network path can read or modify it.

The standard answer is opportunistic TLS via STARTTLS: the sending server announces TLS capability, the receiver acknowledges, and the connection is upgraded to encrypted. This works in normal operation. The problem is that opportunistic TLS is trivially downgradable. A man-in-the-middle attacker positioned between the two mail servers can strip the STARTTLS announcement from the conversation, both servers see a peer that "does not support TLS," and the entire message flows in cleartext. Neither side notices because nothing is broken from their perspective.

Transport security policies like MTA-STS and DANE exist to make TLS non-negotiable for properly configured domains. They tell sending servers "TLS is required when sending to this destination; refuse to deliver if TLS cannot be established."

What DANE Actually Does

DANE solves the same fundamental problem as MTA-STS but takes a different architectural path. MTA-STS relies on the public Web PKI: certificates issued by trusted certificate authorities, validated by checking the certificate chain against a list of trusted roots. DANE eliminates the CA dependency by publishing the certificate fingerprint directly in DNS, secured by DNSSEC.

The DANE workflow:

1. The receiving mail server has a TLS certificate on its SMTP port.
2. The receiving domain publishes a TLSA record in DNS at _25._tcp.<mx-hostname> containing the fingerprint (or full key) of that certificate.
3. The DNS zone is signed with DNSSEC so the TLSA record itself is authenticated.
4. When a sending server attempts SMTP delivery, it looks up the TLSA record (and validates the DNSSEC signature) before initiating TLS.
5. During TLS handshake, the sending server compares the certificate the receiver presents against the fingerprint in the TLSA record.
6. If they match, the connection proceeds. If they do not match, the sending server refuses to deliver, regardless of whether the certificate would have validated against the public CA system.

This eliminates two attack vectors that the Web PKI cannot fully prevent: a compromised CA issuing fraudulent certificates for your domain, and downgrade attacks that strip security policy retrieval.

DANE vs MTA-STS: When to Use Which

Both protocols protect email in transit and prevent downgrade attacks. They differ in trust model, infrastructure requirements, and adoption.

MTA-STS is the practical baseline for most senders. It works without DNSSEC, deploys via HTTPS, and is supported by the major providers. DANE is the upgrade path for senders who already have DNSSEC infrastructure, operate in environments where CA compromise is a real threat model, or need to interoperate with DANE-only systems.

The two are not mutually exclusive. A receiving domain can publish both an MTA-STS policy and TLSA records, and sending servers will use whichever protocol they support. In practice, larger organizations in 2026 deploy MTA-STS first for broad compatibility and add DANE later for enhanced security.

DNSSEC Is the Hard Prerequisite

DANE cannot exist without DNSSEC. The entire security model depends on the receiving domain's DNS zone being signed so that TLSA records cannot be tampered with in transit. A TLSA record in an unsigned zone provides no security; sending servers that respect DANE will ignore it.

DNSSEC adoption is uneven. Country-code TLDs vary widely (.se, .nl, .cz have high adoption; .com, .net are mid-range; many regional TLDs have minimal adoption). DNS providers also vary: AWS Route 53 supports DNSSEC, Cloudflare supports it, Google Cloud DNS supports it, but smaller registrars and managed providers often do not.

Before considering DANE, verify three things:

• Your TLD supports DNSSEC.
• Your DNS provider supports DNSSEC signing.
• Your domain registrar supports publishing DS records to the TLD registry (this is how the chain of trust is established).

If any of these is missing, MTA-STS is your path. DANE is not viable without all three.

The TLSA Record Format

A TLSA record has four fields plus the certificate or key data. The format:

_25._tcp.mail.example.com.   IN   TLSA   3 1 1 [hash of certificate or key]

Breaking down the fields:

• Service prefix: _25._tcp indicates port 25 over TCP (SMTP). For submission on port 587, use _587._tcp.
• Hostname: Your mail server hostname, which must match one of your MX records.
• Certificate Usage (first field): 0=CA constraint, 1=Service certificate constraint, 2=Trust anchor assertion, 3=Domain-issued certificate. For email DANE, use 3 (DANE-EE) for self-signed or domain-pinned certificates, or 2 (DANE-TA) to pin a trust anchor.
• Selector (second field): 0=Full certificate, 1=SubjectPublicKeyInfo. Use 1 to allow certificate renewal without TLSA changes when the underlying key stays the same.
• Matching Type (third field): 0=Exact match, 1=SHA-256 hash, 2=SHA-512 hash. SHA-256 (value 1) is the standard choice.
• Certificate Association Data: The actual hash, in hexadecimal.

The most common production TLSA record for email is 3 1 1 [SHA-256 hash of the SubjectPublicKeyInfo]. This pins the public key of the certificate without pinning the certificate itself, which lets you renew certificates as long as the underlying key remains the same.

Deploying DANE for an Existing Mail Server

Step 1: Confirm DNSSEC Is Working

Before publishing any TLSA records, verify DNSSEC is fully operational on your domain:

dig +dnssec example.com SOA

Look for the AD flag in the response header. If present, DNSSEC validation is succeeding. Also verify the DS records at the TLD registry match the DNSKEY records in your zone using a tool like DNSViz or Verisign's DNSSEC Analyzer.

Step 2: Generate the TLSA Record from Your Mail Server Certificate

Extract the SubjectPublicKeyInfo hash from your mail server's certificate. Using OpenSSL:

openssl x509 -in /path/to/mail-cert.pem -pubkey -noout |
  openssl pkey -pubin -outform DER |
  openssl dgst -sha256 -hex

The output is the SHA-256 hash you need for the TLSA record. Format the resulting record as:

_25._tcp.mail.example.com.   IN   TLSA   3 1 1 [your hash here]

Step 3: Publish the TLSA Record

Add the TLSA record to your DNS zone for each MX hostname. If you have multiple MX records pointing to different hostnames, each needs its own TLSA record:

_25._tcp.mail1.example.com.  IN  TLSA  3 1 1 [hash of mail1 cert]
_25._tcp.mail2.example.com.  IN  TLSA  3 1 1 [hash of mail2 cert]

Step 4: Test DANE Validation

Test from an external host that supports DANE validation. The posttls-finger tool included with Postfix is the standard test:

posttls-finger -t 10 -L verbose -P /etc/ssl/certs/ -l dane example.com

A successful DANE validation will show Verified TLS connection with the matched TLSA record. Failure modes are explicit and include reasons like TLSA lookup error (DNSSEC failure) or no usable TLSA records (certificate does not match published hash).

Step 5: Configure TLS-RPT to Monitor

Publish a TLS-RPT record to receive aggregate reports about TLS handshake failures from sending servers:

_smtp._tls.example.com.   IN   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Compliant sending servers will send daily aggregate reports detailing TLS connection outcomes, certificate validation failures, and DANE-specific errors. This is your monitoring layer; without it, DANE failures are invisible until users complain.

The Key Rotation Choreography

The most operationally challenging aspect of DANE is certificate and key rotation. With the public CA model, you can rotate certificates anytime as long as the new one validates against trusted roots. With DANE, rotating a certificate without updating TLSA records first will break delivery from DANE-validating senders.

The correct rotation sequence:

1. Generate the new certificate and key but do not deploy it yet.
2. Calculate the new TLSA hash for the new key.
3. Publish the new TLSA record alongside the old one (both records valid simultaneously).
4. Wait for DNS propagation and TLSA caching to expire across all sending resolvers (24-48 hours is typical).
5. Deploy the new certificate on the mail server.
6. Verify mail flow is healthy with the new certificate.
7. After another 24-48 hours of healthy operation, remove the old TLSA record.

Skipping any step risks delivery failures. Senders whose resolvers have the old TLSA record cached but receive a connection presenting the new certificate will treat the mismatch as an attack and refuse to deliver.

The Microsoft 2026 DANE Rollout

For most of DANE's history, Microsoft did not validate it on outbound SMTP from Exchange Online and did not support it on inbound either. This made DANE meaningfully less valuable for senders whose traffic touched Microsoft mailboxes. In 2026, this changed.

Microsoft now supports DANE inbound for Exchange Online tenants that migrate to the new mx.microsoft.com MX target. The transition timeline pushes all tenants to the new MX by mid-2026. Once on the new MX, Exchange Online publishes its own TLSA records (signed by DNSSEC) and validates outbound DANE when sending to DANE-protected receivers.

For email administrators, this has two implications. First, sending mail to Microsoft 365 users now traverses DANE-validating infrastructure, which makes deploying DANE on your own outbound side more valuable than it was previously. Second, organizations running Exchange hybrid configurations need to plan the MX migration carefully, particularly if they have custom MTA-STS or DANE configurations that depend on the old MX hostnames.

When DANE Is Not the Right Answer

DANE is not appropriate for every sender. Skip DANE if:

• Your TLD or DNS provider does not support DNSSEC.
• You cannot commit to operational discipline around DNSSEC key management and TLSA rotation.
• Your sending volume is low enough that MTA-STS provides adequate coverage.
• Your team has not yet implemented basic email authentication (SPF, DKIM, DMARC, MTA-STS); these should come first.

For most senders, the upgrade path is: SPF, DKIM, DMARC, then MTA-STS, then DANE. Each layer builds on the previous, and skipping layers to jump to DANE creates fragility without addressing more basic security gaps.

Frequently Asked Questions

← Back to Blog