Last updated: July 2026

In short: DANE enforces encrypted, authenticated mail delivery — but only if the receiving mail server provides DNSSEC and TLSA records. Only a few providers can do that. This article shows who can do DANE (Microsoft 365, self-hosting), who can’t (Google Workspace, the German shared hosts) — and which alternative remains for you.

What is DANE?

DANE (DNS-based Authentication of Named Entities, RFC 6698) uses a TLSA record in your domain’s DNS “to signal that a domain and its email servers support DANE”. A sending server checks before delivery whether the recipient’s TLS certificate matches the TLSA record. This makes the authentication “resistant to downgrade and MITM attacks” — the key advantage over SMTP’s pure best-effort encryption.

The hard prerequisite: DNSSEC + TLSA at the MX

Here lies the catch that makes DANE unreachable for most users. DANE has “direct dependencies on DNSSEC” — and “you can only trust TLSA records if you enable DNSSEC for your domain”. Concretely, three things are needed, and at the operator of your receiving mail server:

  1. DNSSEC for the zone (signed DNS records),
  2. TLSA records under _25._tcp.mail.your-domain that match the MX’s certificate,
  3. an MX that presents exactly this certificate.

That’s the decisive point: DANE isn’t a setting you set on the side as a customer — the operator of your mailboxes must support it. At a shared host whose MX publishes no TLSA, you simply can’t “set up” DANE.

Who can do DANE

Microsoft 365 (Exchange Online). Microsoft has made inbound SMTP DANE with DNSSEC generally available. Activation runs via PowerShell, with the recommended TLSA type 3 1 1 (DANE-EE) — Microsoft’s docs stress “that certificate usage field values of 0 or 1 should not be used”. Details in our DANE guide for Microsoft 365.

Self-hosted servers (e.g. Mailcow). If you run your own MX, you have full control: sign the zone with DNSSEC, generate TLSA from the MX certificate, publish. That’s the classic DANE route — see DANE for Mailcow.

With your own MX behind a DNSSEC-capable DNS provider. Some DNS providers “may offer … DNSSEC as a setting”. If you run your own mail server behind such a zone, you can implement DANE — technically this matches the self-hosting route.

Who can’t do DANE (for you)

Google Workspace. Google publishes no TLSA records for its MX — Google relies on MTA-STS for inbound transport (“authenticated with a valid public certificate”, TLS 1.2+). So for Google Workspace domains DANE is a non-issue; the alternative is MTA-STS for Google Workspace.

The German shared hosts (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain). Some offer DNSSEC signing for your zone — but their mail servers publish no TLSA records. Without TLSA at the MX there’s no DANE. DNSSEC alone (without mail-related TLSA) does nothing for the transport security of your email.

What to use instead: MTA-STS

For everyone who can’t implement DANE, MTA-STS is the practical alternative. It reaches the same goal — enforced, authenticated TLS delivery — without DNSSEC, but via a policy file served over HTTPS. Where that works well (Google, Microsoft, Mailcow) and where it gets tricky (shared hosts), we explain in MTA-STS at shared hosts and the individual guides for Google Workspace, Microsoft 365, and Mailcow.

And in any case: add TLS-RPT so you get reports on TLS delivery — whether you end up running DANE or MTA-STS.

Verify the result

The free MXAudit scanner shows you whether your domain is DNSSEC-signed, whether TLSA records exist for your MX, and how MTA-STS and TLS-RPT stand — the quick way to see which transport protection actually applies to your setup.

Further reading