What is DANE for email?

Updated 2026-10-15 · DMARC Fundamentals

DANE — DNS-Based Authentication of Named Entities — does the same job as MTA-STS by a different route. Both make sending servers deliver mail to you only over an encrypted connection to the right server. MTA-STS publishes that promise on a web server; DANE publishes it in DNS, protected by DNSSEC. For email, the rules are RFC 7672.

How it works

For each mail server that receives mail for your domain — each host in your MX records — a TLSA record is published at a name built from the SMTP port and the host name:

_25._tcp.mx1.example.com.   TLSA   3 1 1 0BECB1AF349FC7C52D47BD380303BFAB79EC3D7F32A808843D43FF67270CC419

The record says which certificate (or which key) that server will present. The three numbers say how to read the last field; 3 1 1 — "this exact key, as a SHA-256 fingerprint" — is the most common choice for mail.

A sending server that supports DANE looks up your MX hosts, finds their TLSA records, and checks the certificate it is shown against them. If it does not match, or encryption is not offered, it does not deliver. No certificate authority is involved, so a wrongly issued certificate cannot be used against you.

The one hard requirement: DNSSEC

A TLSA record only counts if the answer was DNSSEC-validated. Without DNSSEC anyone who can forge DNS could forge the pin too, so senders ignore an unsigned TLSA record entirely — mail still arrives, over ordinary opportunistic TLS, but it is not pinned.

Note whose DNSSEC that is: the TLSA record lives in the zone of the MX host, not necessarily in yours. If your mail is handled by a provider, the TLSA records are theirs to publish.

Who sets it up

If a mail provider runs your MX servers, DANE is their decision. Some providers publish TLSA records for their MX hosts (posteo.de does, for example); many do not, including Google's MX hosts. There is nothing to configure on your side beyond pointing your MX records at them.
If you run your own mail servers, you publish the TLSA records yourself, in a DNSSEC-signed zone, and you must update them before you replace a certificate's key — publish the new record alongside the old one, wait for caches to expire, then switch. A stale TLSA record makes DANE-aware senders refuse your mail.

DANE is used most by mail providers and organisations in Europe, notably in Germany and the Netherlands. It and MTA-STS can be published side by side; a sender uses whichever it supports.

What the Domain health card shows

We check the TLSA record for up to four of your MX hosts, most preferred first.

Result	What it means
no TLSA	None of your MX hosts publishes a TLSA record. Optional; usually your mail provider's choice.
MX pinned / N MX pinned	Every MX host checked has a DNSSEC-validated TLSA record.
first 4 pinned	You have more than four MX hosts; the four most preferred are pinned and the rest were not checked.
N of M MX	Only some MX hosts publish TLSA; mail delivered to the others is not pinned.
TLSA unsigned	A TLSA record exists but its answer was not DNSSEC-validated, so every sender ignores it. Mail still arrives, but is not pinned.
no MX	The domain publishes no MX hosts (or a null MX), so there is nothing to pin.
couldn't read	Our DNS lookup failed. This says nothing about your domain — press Re-check.

The mail transport security rows — MTA-STS, TLS-RPT, DNSSEC and DANE — are part of the Starter, Scale and Enterprise plans; on the Free plan they are shown locked, marked Upgrade.