DANE and TLSA records explained

12 May 2026 · 13 min read

The problem DANE was built to solve

When one mail server sends a message to another, the connection between them is supposed to be encrypted. The sending server issues a STARTTLS command, the two sides negotiate TLS, and the message crosses the internet inside an encrypted tunnel rather than in plain text. That is the theory. The reality, for most of email's history, has been quietly broken in a way that almost nobody notices, because the failure is silent and the mail still gets delivered.

The weakness is this: classic SMTP TLS is opportunistic. The sending server will use encryption if the receiving server offers it, but it will happily fall back to an unencrypted connection if encryption is not available, and it does not verify the certificate it is presented with the way a web browser does. An attacker sitting in the network path can strip the STARTTLS offer out of the conversation, or present their own certificate, and the sending server, with no expectation of anything better, sends the message anyway. The encryption that was supposed to protect the message in transit simply does not happen, and there is no error, no warning, no bounce.

DANE, DNS-Based Authentication of Named Entities, exists to close that gap. It lets a receiving domain publish, in DNS, a cryptographic statement of which certificate its mail server is supposed to present. A sending server that supports DANE looks up that statement before it connects, and refuses to deliver over an unauthenticated or downgraded connection. The trick that makes this trustworthy is that the DNS records are themselves protected by DNSSEC, so an attacker cannot forge them. This article explains how DANE and its TLSA records actually work, how the binding through DNSSEC holds together, how DANE compares with MTA-STS (the other answer to the same problem), and which one fits which situation.

What a TLSA record is

DANE is published in DNS as a record type called TLSA. A TLSA record is, in plain terms, a fingerprint of the certificate (or the public key) that a server is allowed to present, placed at a specific name in DNS so that a client can find it before connecting.

For SMTP, the record lives at a name built from the port and protocol of the mail server, prefixed to the hostname. For a mail exchanger called mx.example.com listening on port 25, the TLSA record is published at:

_25._tcp.mx.example.com.  IN TLSA  3 1 1  <hash of the certificate's public key>

That _25._tcp. prefix is the convention: an underscore-prefixed label for the port, then _tcp, then the actual hostname of the server. A sending mail server that has resolved your MX record to mx.example.com knows to look up _25._tcp.mx.example.com for a TLSA record before it delivers.

The three numbers before the hash are the heart of the record. They tell the client exactly what is being asserted.

The certificate usage field

The first number is the certificate usage. It answers "what kind of certificate am I describing, and how should you check it?"

• 0 (PKIX-TA): the record names a certificate authority in the public PKI that must appear in the server's chain.
• 1 (PKIX-EE): the record names the server's own (end-entity) certificate, which must also validate against the public PKI.
• 2 (DANE-TA): the record names a trust anchor (typically a private or internal CA) that the client must accept as the root of the chain, regardless of the public PKI.
• 3 (DANE-EE): the record names the server's own end-entity certificate directly, and the client trusts it on the strength of the DNSSEC-signed record alone, without reference to any public CA.

For SMTP, usage 3 (DANE-EE) is by far the most common and the most practical. It says, in effect, "here is the exact public key my mail server will present; if you see that key over a TLS connection, trust it, because this record is signed with DNSSEC and cannot be forged." It removes the public certificate authority system from the trust decision entirely, which for server-to-server mail is a feature rather than a loss, and it means your certificate does not even need to be issued by a public CA to work.

The selector and matching type fields

The second number is the selector. 0 means the record covers the full certificate; 1 means it covers only the certificate's public key (the SubjectPublicKeyInfo). Selector 1 is usually preferred, because it lets you renew a certificate without changing the TLSA record, as long as you keep the same key pair.

The third number is the matching type. 0 means the record contains the full data with no hashing; 1 means it contains a SHA-256 hash; 2 means SHA-512. In practice you will almost always see 1, a SHA-256 hash, because publishing a compact hash is cleaner than embedding a whole certificate in DNS.

So the very common 3 1 1 combination reads as: "DANE-EE, match on the public key, presented as a SHA-256 hash." That single line is the workhorse of DANE for SMTP, and if you understand it you understand the format.

How DNSSEC makes the binding trustworthy

A fingerprint published in DNS is only as trustworthy as DNS itself, and ordinary DNS is trivially forgeable. An attacker who can tamper with your DNS responses could simply serve a TLSA record matching their own certificate, and the whole scheme would collapse. This is exactly why DANE requires DNSSEC, and why DNSSEC is not optional but foundational to the entire mechanism.

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records. Each zone signs its records with a private key, and publishes the corresponding public key. The parent zone signs a fingerprint of the child's key, and so on up to the root, which is trusted by convention. The result is an unbroken chain of signatures from the DNS root down to your TLSA record. A resolver that validates DNSSEC can confirm that the TLSA record it received is exactly what your zone published, and has not been altered, injected or removed in transit.

This chain of trust is what gives DANE its strength. The binding is not "trust this certificate because a public CA vouched for it", which is the web's model and depends on hundreds of CAs all behaving. The binding is "trust this certificate because the domain owner said so, in a DNS record cryptographically signed all the way up to the root." For email between servers, where there is no human to click through a certificate warning, that is a clean and self-contained trust model.

The practical consequence is unavoidable: without DNSSEC, you cannot deploy DANE. If your zone is not signed, a sending server that validates DANE will treat your TLSA records as unauthenticated and ignore them, exactly as it should, because an unsigned TLSA record proves nothing. Standing up DNSSEC on your domain, and on the zone that holds your MX hostnames, is therefore the first and largest piece of work in any DANE deployment, and it is not a small piece. A DNSSEC misconfiguration does not just break DANE, it can make your whole domain unresolvable, so it has to be done carefully.

What actually happens on a DANE-protected delivery

It helps to walk through a single message to see where DANE intervenes.

1. A sending server has a message for you@example.com. It looks up the MX record for example.com and finds mx.example.com. Because it is a DANE-aware sender, it requests these records with DNSSEC validation, and confirms the MX answer is authentic.
2. It then looks up _25._tcp.mx.example.com for TLSA records, again validating DNSSEC. It finds 3 1 1 <hash>.
3. The sender now knows two things for certain: that it must use TLS to deliver this message, and exactly which public key the receiving server must present. The "must use TLS" part is implied by the mere presence of a validated TLSA record; there is no separate "encryption is mandatory" flag to publish.
4. The sender connects, issues STARTTLS, and inspects the certificate the receiving server presents. It computes the SHA-256 hash of that certificate's public key and compares it with the hash in the TLSA record.
5. If they match, delivery proceeds inside the encrypted, authenticated tunnel. If they do not match, or if STARTTLS is missing, or if the certificate is absent, the sender refuses to deliver and defers the message rather than falling back to plain text.

That step 5 is the entire point. An attacker who strips STARTTLS cannot succeed, because the sender was told by DNSSEC-signed records to expect encryption and will not downgrade. An attacker who substitutes a certificate cannot succeed, because the public key will not match the published hash. The silent downgrade that plagues opportunistic TLS is closed off.

How DANE compares with MTA-STS

DANE is not the only answer to the SMTP downgrade problem. MTA-STS, Mail Transfer Agent Strict Transport Security, solves the same problem with a completely different mechanism, and the two are worth comparing directly because most teams will choose one rather than both.

The problem both address is identical: stop the silent downgrade of SMTP TLS, and stop certificate substitution. Where they differ is in how the sending server learns the policy and how trust is anchored.

DANE anchors trust in DNSSEC. The policy lives in TLSA records, and their authenticity comes from the DNSSEC chain to the root. There is no separate web server, no HTTPS fetch, nothing to host. The cost is that you must run DNSSEC.

MTA-STS anchors trust in the public web PKI. Instead of a signed DNS record, you publish a small mta-sts.txt policy file over HTTPS at a well-known URL on your domain (https://mta-sts.yourdomain.com/.well-known/mta-sts.txt), plus a small TXT record at _mta-sts.yourdomain.com whose only job is to signal the current policy version so senders know when to refetch. The sending server fetches that policy file over a TLS connection validated against the normal public certificate authorities, then enforces it: it requires TLS to your MX hosts and checks that their certificates are issued by a trusted public CA and match the MX hostname. We cover the full mechanism in our MTA-STS product overview, and you can inspect any domain's policy with the MTA-STS checker.

The trade-offs fall out cleanly:

• DNSSEC requirement. DANE needs DNSSEC; MTA-STS does not. This is the single biggest factor for most teams. If your DNS provider does not support DNSSEC, or you are nervous about the operational risk of signing your zone, MTA-STS is the only option of the two you can deploy.
• Trust anchor. DANE trusts DNS (via DNSSEC); MTA-STS trusts the public CA system (via HTTPS). Neither is universally "better"; they move the trust to different places.
• Failure mode. DANE is strict by design: a mismatch means non-delivery, full stop. MTA-STS has a testing mode and an explicit enforce mode, so you can roll it out in report-only fashion first, which many operators find safer.
• Downgrade resistance. DANE is harder to bypass at the network layer, because the policy discovery itself is DNSSEC-protected end to end. MTA-STS has a known first-contact window: a sender that has never seen your policy could, in principle, be prevented from fetching it. After the first successful fetch the policy is cached, which closes most of that gap, but it is a real difference.
• Operational surface. DANE lives entirely in DNS once DNSSEC is running, but it couples your certificate lifecycle tightly to your DNS records: every certificate rotation must be choreographed with the TLSA record, or delivery breaks. MTA-STS needs a web host for the policy file but leaves certificate rotation alone, as long as you stay with a trusted public CA.

That last point about DANE and certificate rotation deserves emphasis, because it is where real-world DANE deployments most often fail.

The DANE rotation trap, and how to avoid it

Because a TLSA record pins a specific certificate or key, renewing or replacing that certificate without updating the record will cause every DANE-aware sender to reject your mail. This is the most common way DANE deployments break, and it is entirely self-inflicted.

The safe pattern is to publish the new key before you switch to it, so that at the moment of changeover, both the old and new keys have valid TLSA records in DNS. The sequence looks like this:

1. Generate the new key pair and certificate.
2. Add a second TLSA record for the new key alongside the existing one. Now both keys are accepted.
3. Wait for the old record's TTL to expire everywhere, so all caches know about the new record.
4. Deploy the new certificate on the mail server.
5. Once you have confirmed mail is flowing on the new certificate, remove the old TLSA record.

Using selector 1 (public key rather than full certificate) helps here, because if you reuse the same key pair across a certificate renewal, the TLSA record does not need to change at all. Many operators pin a long-lived key precisely so that routine certificate renewals do not touch DNS. Whichever approach you take, the rule is the same: the DNS record and the deployed certificate must never be out of sync at a moment when senders are connecting. Automating this, so that certificate issuance also generates and publishes the matching TLSA records, is what separates a stable DANE deployment from a fragile one.

When each one fits

With the mechanics clear, the choice between DANE and MTA-STS, or the decision to run both, comes down to a few honest questions.

Reach for DANE when:

• Your domain already runs DNSSEC, or you are committed to running it for other reasons. Once DNSSEC is in place, DANE is a small additional step and gives the stronger downgrade resistance of the two.
• You want a trust model that does not depend on the public certificate authority ecosystem at all, which is appealing for internal or high-assurance infrastructure where you would rather pin your own keys.
• You and your DNS or mail provider have automation that can keep TLSA records in step with certificate rotation. Without that, DANE's strictness becomes a liability.

Reach for MTA-STS when:

• DNSSEC is off the table, whether because your DNS provider does not support it or because you judge the operational risk of zone signing too high for now. MTA-STS gives you real downgrade protection with no DNSSEC dependency.
• You want a gentle rollout. The testing mode lets you publish a policy and collect reports (via the related TLS-RPT mechanism) before you switch to enforce, so you can confirm nothing breaks first.
• You would rather keep certificate management conventional: a normal certificate from a trusted public CA, renewed on the usual cadence, with no DNS choreography tied to it.

Run both when you operate mail at a scale where maximising the share of senders who will enforce TLS to you matters. The two are complementary, not mutually exclusive: a given sending server supports one, the other, both or neither, so publishing both widens the set of senders that will refuse to downgrade when delivering to you. The large mailbox providers increasingly support both, and there is no conflict in having a TLSA record and an mta-sts.txt policy describing the same servers.

It is worth being clear about scope, because DANE and MTA-STS are easy to confuse with the rest of the email-authentication stack. Both protect the connection between mail servers in transit. Neither has anything to do with whether a message is authentic, or who is allowed to send as your domain. That job belongs to SPF, DKIM and DMARC, which authenticate the message itself rather than the transport. A domain can have flawless DANE and still be wide open to spoofing if its DMARC policy is p=none; and a domain at p=reject can still be having its mail silently downgraded in transit if it has neither DANE nor MTA-STS. They are different layers solving different problems, and a complete setup wants both layers covered. If you are still working the message-authentication layer, start with our guides on what DMARC is and moving from p=none to p=reject.

The practical takeaway

DANE turns the silent, unverified, easily downgraded encryption of classic SMTP into something strict and provable. It does this by publishing a TLSA record, a fingerprint of the certificate or key your mail server must present, and protecting that record with DNSSEC so it cannot be forged. A DANE-aware sender looks the record up, validates the DNSSEC chain, and refuses to deliver unless the server presents exactly the expected key over an encrypted connection. The 3 1 1 record, DANE-EE matching a SHA-256 hash of the public key, is the format you will use most.

MTA-STS answers the same question with the public web PKI instead of DNSSEC, trading DANE's stronger downgrade resistance for an easier deployment that needs no zone signing and offers a safe testing mode. If you already run DNSSEC and can automate certificate rotation, DANE is excellent. If you cannot or will not run DNSSEC, MTA-STS gives you most of the protection with far less risk. At larger scale, publish both.

Whichever you choose, remember the rotation discipline for DANE and the layering point for both: transport security and message authentication are separate, and you want both. You can check any domain's transport policy today with the free MTA-STS checker and review the rest of your setup with the wider diagnostic tools. And if you would rather not hand-roll DNSSEC, TLSA records and a careful certificate-rotation process yourself, our done-for-you hosting sets up and maintains your transport security alongside DMARC, SPF, DKIM and BIMI, with continuous monitoring so you are alerted the moment a record or certificate drifts out of line.