What is DANE for SMTP, and do you need it?

STARTTLS encrypts mail between servers, but by default a sender accepts any certificate and falls back to plain text if TLS fails. DANE closes that gap by publishing, in DNSSEC-signed DNS, exactly which certificate your mail servers should present. This guide explains how DANE works, what a TLSA record contains, how it compares with MTA-STS, where Microsoft Exchange Online stands, and how to check a domain. For the background on opportunistic TLS, read STARTTLS and email encryption in transit.

What is DANE for SMTP?

DANE stands for DNS-Based Authentication of Named Entities. The general TLSA record format is defined in RFC 6698, and its use for mail between servers in RFC 7672, a Standards Track RFC from 2015. RFC 7672 describes itself as "a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents".

It works in three steps:

1. A sending server looks up your MX records using DNSSEC and confirms the answer is authentic.
2. For each MX host, it looks up a TLSA record at _25._tcp.<mx-hostname>, again validated with DNSSEC.
3. If a usable TLSA record exists, the sender requires STARTTLS and checks that the server's certificate or public key matches the record. If it doesn't match, the sender doesn't deliver.

The presence of a TLSA record is a promise. RFC 7672 says DNSSEC-validated TLSA records "MUST NOT be published for servers that do not support TLS", so senders "can safely interpret their presence as a commitment by the server operator to implement TLS and STARTTLS".

Why does DANE need DNSSEC?

Without signed DNS, an attacker who can forge DNS answers could forge TLSA records too, or point your MX at their own server. DNSSEC lets the sender verify that each answer really came from the zone owner.

RFC 7672 is precise about what has to be signed. It says DANE "can authenticate message delivery to the intended next-hop domain only when the MX records are obtained securely via a DNSSEC-validated lookup." That means two zones matter:

If you host your own mail server, you control both. If your MX points to a mailbox provider or a filtering service, the provider must sign its zone and publish TLSA records for its hosts, and you must sign yours. RFC 7672 notes that senders may still use a provider's TLSA records when the customer's own zone isn't signed, but an attacker could then tamper with the unsigned MX answer.

What does a TLSA record look like?

A TLSA record has four fields. For a mail server at mx1.example.com:

_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 (
    0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef )

RFC 7672 says: "we RECOMMEND the use of 'DANE-EE(3) SPKI(1) SHA2-256(1)', with 'DANE-TA(2) Cert(0) SHA2-256(1)' TLSA records as a second choice." Microsoft gives the same 3 1 1 recommendation.

Two practical consequences:

• A 3 1 1 record survives certificate renewals that keep the same key. RFC 7672 says this record type "need not change across certificate renewals with the same key", and DANE-EE records "don't suddenly stop working when leaf or intermediate certificates expire".
• Don't use usages 0 or 1 (PKIX-TA and PKIX-EE). RFC 7672 says SMTP TLSA records "SHOULD NOT include" them, because mail servers have no agreed list of trusted CAs. Exchange Online treats such records as unusable, but because a TLSA record exists, it still insists on TLS.

How does DANE compare with MTA-STS?

Both stop senders from falling back to plain text or accepting an impostor server. They trust different things.

RFC 8461 says MTA-STS exists for domains where "deploying DNSSEC is undesirable or impractical", and that senders "MUST NOT allow MTA-STS Policy validation to override a failing DANE validation". You can publish both. Our MTA-STS and TLS-RPT guide covers the other half, and a TLS-RPT record works for DANE too: RFC 8460 defines failure types such as tlsa-invalid and dnssec-invalid.

Does Microsoft Exchange Online support DANE?

Yes, in both directions, at the time of writing (October 2026).

Outbound: on by default

Microsoft says outbound SMTP DANE with DNSSEC is "ON by default for all Exchange Online customers" and is used "when the destination domain advertises support for DANE". You don't configure anything. If validation fails, Exchange Online retries after 15 minutes, again 15 minutes later, then every hour for 24 hours, and then returns a non-delivery report. The NDR codes are:

Microsoft notes that it currently reports DNSSEC failures as a generic DNS error rather than 5.7.324.

Inbound: opt-in, per domain

Microsoft announced general availability of inbound SMTP DANE with DNSSEC for Exchange Online in October 2024 (Microsoft Tech Community). It's not automatic. According to Microsoft Learn:

1. Lower the TTL on your existing MX record and wait for the old TTL to expire.
2. If you use MTA-STS, switch the policy to testing and update its id first.
3. Run Enable-DnssecForVerifiedDomain -DomainName <domain>. It returns a new MX value ending in mx.microsoft.
4. Add that MX at priority 20, test it, then make it priority 0 and delete the old mail.protection.outlook.com record.
5. Run Enable-SmtpDaneInbound -DomainName <domain>, which provisions the TLSA records. Microsoft says propagation "can take 15-30 minutes".
6. Validate with the DANE test in Microsoft's Remote Connectivity Analyzer, then return MTA-STS to enforce.

Microsoft lists limitations: onmicrosoft.com domains and self-service sign-up domains aren't supported, and if a third-party gateway receives your mail first, inbound DANE only secures the gateway-to-Exchange hop, and only if the gateway validates DANE. If something goes wrong, Disable-SmtpDaneInbound turns it off.

Who should deploy DANE?

Most small businesses get more from finishing SPF, DKIM and DMARC first, then adding MTA-STS. DANE is worth it where DNSSEC is already in place or easy to turn on.

What can go wrong with DANE?

DANE fails closed, so mistakes stop mail rather than weakening it.

• Key changes without a TLSA update. RFC 7671 says to publish a record for the new key alongside the old one "at least two Times to Live (TTLs) or longer before the new chain is deployed", then remove the old record after the switch.
• Broken DNSSEC. If your zone signals DNSSEC but its answers fail validation, for example after moving DNS hosts without updating DNSSEC, Microsoft says Exchange Online blocks delivery. If a signed zone gives no proper answer to a TLSA query, Exchange Online defers mail with 450 4.7.324 dnssec-invalid.
• MX changes. Moving MX to a new provider means the new hosts need TLSA records, and your MX records must stay signed.
• Records for servers that can't do TLS. RFC 7672 forbids this; senders will refuse delivery.

How do you check DANE for a domain?

Our free tools don't test DANE or DNSSEC yet, so use these steps:

1. List the MX hosts with the MX Lookup.
2. Check DNSSEC on your domain. From a validating resolver, run dig +dnssec MX example.com and look for the ad (authenticated data) flag in the response header.
3. Look up TLSA records for each host: dig +dnssec TLSA _25._tcp.mx1.example.com. No answer means no DANE for that host.
4. Compare the record with the live key. Connect with openssl s_client -connect mx1.example.com:25 -starttls smtp, hash the public key with SHA-256, and compare it with the TLSA data.
5. For Microsoft 365 domains, use the DANE validation test in Microsoft's Remote Connectivity Analyzer, as Microsoft's setup steps describe.
6. Watch the reports. Publish TLS-RPT and look for tlsa-invalid or dnssec-invalid failures.

To see whether a message you received was encrypted on each hop, paste its headers into the Email Header Analyzer and look for ESMTPS in the Received lines.

Next steps

• Publish a TLS-RPT record now; it costs nothing and reports TLS problems for DANE and MTA-STS alike.
• Ask your DNS host whether it supports DNSSEC, and your mail or filtering provider whether its MX hosts publish TLSA records.
• If DNSSEC isn't practical, deploy MTA-STS and confirm it with the MTA-STS Checker.
• Run the Email Health Check for an overview of your MX, authentication and MTA-STS records. If your MX points to iBlockSpam, see how it works for where filtering sits in the delivery path.

Read more email security basics.