What is DANE and does your email need 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-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 it is defined in RFC 7672, 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; the underlying TLSA record type comes from RFC 6698.
• 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 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:

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 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 recommends the 3 1 1 combination shown below:

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 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, DKIM, or 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 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.

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 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, 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 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.

Related reading

• What is MTA-STS?
• What is SPF?
• What is DMARC?