What Is DANE for Email? DNSSEC-Backed SMTP Security

So what is DANE for email? DANE — short for DNS-Based Authentication of Named Entities — is a way to prove a mail server's TLS certificate using DNS instead of a public certificate authority. Applied to server-to-server email in RFC 7672, it lets a domain publish a TLSA record in its DNSSEC-signed DNS zone. A sending server reads that record and uses it to verify the receiving server's certificate before it hands over any mail.

The gap it fills is specific. Email between servers runs on SMTP, which upgrades to encryption through an optional command called STARTTLS. Optional means an attacker on the network can strip that offer, and the two servers quietly fall back to plaintext. DANE gives the receiving domain a way to say, in a place an attacker cannot forge, that encryption is mandatory and which certificate is the real one.

The word doing the heavy lifting is DNSSEC. A plain DNS record can be spoofed, so an unsigned TLSA record proves nothing; DANE only works when the DNS zone is DNSSEC-signed end to end. That single requirement explains almost everything about where DANE is common and where it is not — a point this guide returns to below.

How does DANE for SMTP work?#

A sending server that supports DANE runs the same short sequence before delivering to a domain that publishes TLSA records. Every DNS lookup in it is validated by DNSSEC; if any answer is not DNSSEC-secure, the sender treats DANE as unavailable and falls back to ordinary opportunistic TLS.

1. 1

   Resolve the MX securely

   The sender looks up the recipient domain's MX records and validates them with DNSSEC. Without a DNSSEC-secure MX answer, DANE does not apply to the delivery.

2. 2

   Query the TLSA record

   For each candidate MX host, the sender queries a TLSA record at _25._tcp.<mx-host> — again validated by DNSSEC. Port 25 is the server-to-server SMTP port.

3. 3

   Open TLS and match the certificate

   During the STARTTLS handshake, the sender checks the receiving server's certificate against the TLSA record — for example, a SHA-256 fingerprint of the server's public key.

4. 4

   Deliver, or fail closed

   If a usable, DNSSEC-secure TLSA record exists and the certificate matches, mail is delivered. If the record exists but the certificate does not match, RFC 7672 requires the sender to refuse delivery rather than drop to plaintext.

What a TLSA record looks like#

The TLSA record type is defined in RFC 6698. For a mail server it lives at an owner name built from the port and protocol — _25._tcp — in front of the mail host. The record carries three small numeric fields plus the certificate data itself.

Here is a common shape for an SMTP server: usage 3, selector 1, matching type 1, followed by a SHA-256 digest of the server's public key.

The three TLSA fields#

Each field is one octet. Together they tell a sender whose certificate the record names and how to match it. RFC 6698 defines the full set of values; RFC 7672 narrows the sensible choices for mail.

How the TLSA record ties DNSSEC to the certificate#

The record on its own is just data. What makes it trustworthy is the DNSSEC chain of trust wrapped around the DNS zone it lives in. Because that chain signs every step from the root down to the TLSA record, a sender can be sure the fingerprint it reads is the one the domain owner published — not one an attacker swapped in on the wire.

So the flow is a bridge: DNSSEC vouches for the DNS zone, the TLSA record inside it carries the fingerprint of the mail server's certificate, and the sender trusts that certificate because the DNSSEC signatures check out. No public certificate authority sits in the middle of that decision.

Why DANE matters: what STARTTLS leaves open#

Without DANE, TLS between mail servers is opportunistic — it happens if the handshake succeeds and is skipped if it does not. That is convenient for delivery and weak for security, because an attacker positioned between two servers can make the handshake quietly fail.

The concrete attack is STARTTLS stripping. The attacker deletes the STARTTLS offer, both servers fall back to plaintext, and the mail crosses the wire unencrypted while neither side records a problem. A DNSSEC-secure TLSA record removes that fallback: encryption is required, the certificate is pinned, and a mismatch becomes a delivery failure instead of a silent leak.

DANE also covers a case MTA-STS cannot on its own — the very first message from a sender that has never contacted you before. Because a DANE-aware sender validates on every connection using DNS it can already verify, there is no need to have cached a policy first.

DANE vs MTA-STS: the short version#

DANE and MTA-STS solve the same problem — stopping a TLS downgrade between mail servers — but anchor trust in different things. This is the quick orientation a definition needs; a fuller weigh-up of when to pick each belongs in a dedicated comparison. The one line to remember: DANE leans on DNSSEC, MTA-STS leans on the public CA system, and many domains run both.

Common misconceptions about DANE#

DANE sits next to several other email standards, and the overlap breeds confusion.

• It is not end-to-end encryption. DANE secures the server-to-server hop and only for mail sent to a domain that publishes TLSA records. The message is still readable on each server it passes through, unlike PGP or S/MIME.
• It does not replace SPF, DKIM, or DMARC. Those authenticate who sent a message; DANE secures how the message travels. Different jobs — you want both.
• It is not just a DNS record you add. An unsigned TLSA record is worthless: senders ignore it. The zone has to be DNSSEC-signed first, and that is the harder half of the work.
• It does not use public certificate authorities. A self-signed certificate is fine if it matches the TLSA record, because DNSSEC — not a CA — is what vouches for the record.
• It is not an either/or with MTA-STS. Neither standard obsoletes the other, and publishing both adds first-contact protection on top of a policy every CA-using sender already understands.

Does DANE work everywhere? Adoption and support#

DANE's reach is shaped by one prerequisite: DNSSEC. A domain can only publish a TLSA record senders will trust if its DNS zone is DNSSEC-signed, and a sender can only validate one if it does DNSSEC lookups. Many domains, registrars, and resolvers still do not, which is the honest reason DANE is not universal.

So DANE clusters where DNSSEC is already common. It is widely deployed across parts of Europe and in several national and government mail stacks, and rarer among large consumer providers elsewhere — some of which rely on MTA-STS instead. This is a real difference in the landscape, not a flaw in the standard.

One dated data point on the adoption side: Microsoft has rolled out inbound SMTP DANE with DNSSEC for Exchange Online and its consumer Outlook and Hotmail domains, and has been extending outbound DANE alongside it (as of 2026). On the other side, several large consumer mailbox providers publish no TLSA records for their own servers and use MTA-STS instead — Google-hosted domains, for instance, do not currently publish DANE records. Because these positions move, verify each provider's current status on its own documentation.

Where DANE sits — and where AI Emaily fits#

DANE is a control you set at the DNS and mail-server layer, and it protects mail while it moves between servers, before it reaches any mailbox. AI Emaily is not part of that layer. It does not publish TLSA records, sign your DNS zone, or act as a mail server — DANE and DNSSEC live with your DNS provider and mail host, and no email client can stand in for them.

What AI Emaily does begins after a message lands. It is an AI-native email client for Gmail, Outlook, and IMAP that triages the inbox, drafts replies you approve before they send, and defends against spam and phishing that slip through. Sensitive data it stores, such as OAuth tokens and message bodies, is encrypted, and it does not train on your mail. So DANE secures the delivery path; AI Emaily handles what arrives at the end of it. We build AI Emaily.