# What is DANE and does your email need it? > DANE uses DNSSEC-signed TLSA records to force verified TLS on inbound SMTP. Here is how it works, the record you publish, and when your email needs it. DANE (DNS-Based Authentication of Named Entities) is a standard that lets a domain owner tell sending mail servers "always reach me over TLS, and here is exactly which certificate to trust." It does this by publishing a [DNSSEC](/learning/what-is-a-dns)-signed TLSA record that pins your mail server's certificate, so an attacker can neither strip the encryption nor swap in a fake certificate without being detected. For [SMTP](/learning/what-is-smtp) it is defined in [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672), and you need it if you want inbound mail encryption that cannot be silently downgraded — but only if your domain already runs DNSSEC. ## Quick Takeaways - DANE for SMTP is specified in [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672); the underlying TLSA record type comes from [RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698). - It binds your mail server's TLS certificate to DNS, so senders reject any certificate that does not match — blocking man-in-the-middle interception. - DANE **requires DNSSEC** on your domain. Without signed DNS responses, the TLSA record itself could be forged, and DANE gives no protection. - A TLSA record lives at `_25._tcp.` and has four fields: usage, selector, matching type, and the certificate/key fingerprint. - DANE and [MTA-STS](/learning/what-is-mta-sts) solve the same problem two ways: DANE anchors trust in DNSSEC, MTA-STS in the web PKI. Some domains publish both. - Adoption is uneven — Microsoft 365 supports SMTP DANE, while Google favours MTA-STS — so DANE protects mail from senders that implement it and is safely ignored by those that do not. ## How does DANE work? DANE works by publishing a TLSA record that describes the certificate your mail server is allowed to present, and having sending servers verify that certificate against the record before they deliver mail: ![Record card showing an example SMTP DANE TLSA record with its host and 3 1 1 value fields.](/images/figures/what-is-dane-records.webp) *An example SMTP DANE TLSA record — usage 3, selector 1, matching type 1 (example-shaped values).* - **DNSSEC lookup.** A sending server resolves your [MX records](/learning/what-is-an-mx-record) and checks that the response is signed with DNSSEC. DNSSEC is what makes the rest trustworthy — it cryptographically proves the records came from you and were not tampered with in transit. - **TLSA retrieval.** For each MX host, the sender queries a TLSA record at `_25._tcp.` (port 25, TCP). If one exists, the sender now knows TLS is mandatory for this domain. - **Certificate matching.** The sender opens a TLS connection and compares the certificate your server presents against the fingerprint in the TLSA record. If it matches, delivery proceeds over the encrypted channel. - **Fail closed.** If TLS is unavailable, or the certificate does not match the TLSA record, the message is **not delivered** — the sender queues and retries rather than falling back to plaintext. That "fail closed" behaviour is what stops downgrade attacks. Because the TLSA record is protected by DNSSEC, an attacker on the network path cannot forge it, strip the `STARTTLS` offer, or substitute their own certificate without the sender noticing. ## What is in a TLSA record? A TLSA record binds a certificate to a service using four fields. For SMTP, [RFC 7672](https://datatracker.ietf.org/doc/html/rfc7672) recommends the `3 1 1` combination shown below: | Field | Meaning | Common SMTP value | | --- | --- | --- | | Usage | Which certificate to trust and how | `3` (DANE-EE — the server's own certificate) | | Selector | Which part of the certificate to match | `1` (the public key / SubjectPublicKeyInfo) | | Matching type | How the data is hashed | `1` (SHA-256) | | Certificate data | The fingerprint senders compare against | A SHA-256 hash of the public key | A published record looks like `_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 `. Usage `3` (DANE-EE) is the most common choice for mail because it pins the server's own certificate and does not depend on a public certificate authority chain, which keeps renewal simpler. ## How is DANE different from MTA-STS? Both DANE and [MTA-STS](/learning/what-is-mta-sts) force verified TLS on inbound SMTP and block downgrade attacks — they differ in where they anchor trust: - **DANE** anchors trust in **DNSSEC**. The TLSA record is trustworthy because DNS itself is signed. This means DANE needs DNSSEC deployed on your domain, which not every DNS host supports. - **MTA-STS** anchors trust in the **web PKI** — the same certificate authorities browsers use — plus an HTTPS-hosted policy file. It needs no DNSSEC, so it is often easier to deploy. Neither replaces [SPF](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), or [DMARC](/learning/what-is-dmarc): those authenticate *who* sent a message, while DANE and MTA-STS protect the *channel* the message travels over. Many security-conscious domains publish both DANE and MTA-STS so they are covered whether a given sender supports one standard or the other. ## Does your email need DANE? DANE is worth deploying if all three of these are true: - **You already run DNSSEC** (or can enable it). DNSSEC is the hard prerequisite; without it, DANE offers no security benefit at all. - **You handle sensitive mail** — healthcare, finance, legal, government — where enforced, tamper-proof transport encryption supports your compliance obligations. - **You want defence against active network attackers**, not just passive eavesdroppers, since DANE's certificate pinning is what defeats man-in-the-middle interception. If your DNS provider does not offer DNSSEC, [MTA-STS](/learning/what-is-mta-sts) gives you most of the same inbound-transport protection without it, and is the more pragmatic starting point. Neither is a substitute for getting SPF, DKIM, and DMARC right first — those remain the foundation of [email authentication](/tools/email-security-score). ## Common issues with DANE ### Why is my DANE record being ignored? The most common cause is missing or broken DNSSEC. A TLSA record on a domain that is not DNSSEC-signed is invisible to DANE-aware senders — they will not trust an unsigned TLSA record, so they treat your domain as if it has no DANE at all. Confirm DNSSEC is fully signed and validating with a [DNS lookup](/tools/dns-lookup) before troubleshooting anything else. ### My mail started bouncing after I enabled DANE If the certificate your mail server presents no longer matches the fingerprint in the TLSA record, DANE-aware senders will refuse to deliver. This usually happens after a certificate renewal where the key changed but the TLSA record was not updated. Publish the new TLSA record *before* rotating the certificate, let it propagate, then switch. ### Do I need a TLSA record for every MX host? Yes. TLSA records are per host and per port, published at `_25._tcp.`. If you have several MX servers, each one needs its own TLSA record matching the certificate it presents. A single missing record means senders cannot authenticate that server. ### Does DANE work for outbound mail? DANE for SMTP protects *inbound* mail — it governs how other servers deliver to you. Whether your *outbound* mail uses DANE to authenticate the recipients you send to depends on your own mail platform's support. Publishing TLSA records secures the mail arriving at your domain regardless. ## Frequently asked questions ### Is DANE a replacement for DMARC? No. [DMARC](/learning/what-is-dmarc), with SPF and DKIM, authenticates the sender of a message and decides what happens when authentication fails. DANE secures the transport connection between mail servers so the message cannot be intercepted or downgraded in transit. They protect different layers — run both. ### Can I deploy DANE without DNSSEC? No. DNSSEC is a hard requirement. The whole security model depends on DNS responses being cryptographically signed; without that, an attacker could forge the TLSA record as easily as a certificate, and DANE provides no protection. ### What port does the SMTP TLSA record use? Server-to-server mail delivery uses port 25, so SMTP DANE records are published at `_25._tcp.`. The `_25._tcp` prefix tells resolvers the record applies to TLS on that port. ### Do the big mailbox providers support DANE? Support is uneven. Microsoft documents [SMTP DANE with DNSSEC](https://learn.microsoft.com/en-us/purview/how-smtp-dane-works) for Exchange Online, while Google has favoured MTA-STS for Gmail and Google Workspace. DANE protects mail from any sender that implements it and is safely ignored by those that do not. Palisade continuously checks your domain's transport-security posture — DANE, MTA-STS, and the SPF, DKIM, and DMARC records underneath — and flags a missing or broken record before it costs you mail. You can see where your domain stands right now with the [Email Security Score](/tools/email-security-score). ## Related reading - [What is MTA-STS?](/learning/what-is-mta-sts) - [What is SPF?](/learning/what-is-spf) - [What is DMARC?](/learning/what-is-dmarc)