Stand: Juli 2026
Zusammenfassung: DANE erzwingt verschlüsselte, authentifizierte Mailzustellung — aber nur, wenn der empfangende Mailserver DNSSEC und TLSA-Einträge bereitstellt. Das können nur wenige Anbieter. Dieser Artikel zeigt, wer DANE kann (Microsoft 365, Selfhosting), wer nicht (Google Workspace, die deutschen Shared-Hoster) — und welche Alternative dir bleibt.
Was ist DANE?
DANE (DNS-based Authentication of Named Entities, RFC 6698) nutzt einen TLSA-Eintrag im DNS deiner Domain, „um zu signalisieren, dass eine Domäne und ihre E-Mail-Server DANE unterstützen”. Ein sendender Server prüft vor der Zustellung, ob das TLS-Zertifikat des Empfängers zum TLSA-Eintrag passt. Das macht die Authentifizierung „resistent gegen Downgrade- und MITM-Angriffe” — der zentrale Vorteil gegenüber der reinen Best-Effort-Verschlüsselung von SMTP.
Die harte Voraussetzung: DNSSEC + TLSA am MX
Hier liegt der Haken, der DANE für die meisten Nutzer unerreichbar macht. DANE hat „direkte Abhängigkeiten von DNSSEC” — und „Sie können TLSA-Einträgen nur vertrauen, wenn Sie DNSSEC für Ihre Domäne aktivieren”. Konkret braucht es dreierlei, und zwar beim Betreiber deines empfangenden Mailservers:
- DNSSEC für die Zone (signierte DNS-Einträge),
- TLSA-Einträge unter
_25._tcp.mail.deine-domain, die zum Zertifikat des MX passen, - einen MX, der genau dieses Zertifikat präsentiert.
Das ist der entscheidende Punkt: DANE ist keine Einstellung, die du als Kunde nebenbei setzt — der Betreiber deiner Postfächer muss es unterstützen. Bei einem Shared-Hoster, dessen MX kein TLSA veröffentlicht, kannst du DANE schlicht nicht „einrichten”.
Wer DANE kann
Microsoft 365 (Exchange Online). Microsoft hat eingehendes SMTP DANE mit DNSSEC allgemein verfügbar gemacht. Die Aktivierung läuft über PowerShell, empfohlen wird der TLSA-Typ 3 1 1 (DANE-EE) — Microsofts Doku betont, „dass Werte des Zertifikatverwendungsfelds 0 oder 1 nicht verwendet werden sollten”. Details in unserer DANE-Anleitung für Microsoft 365.
Selbst gehostete Server (z. B. Mailcow). Wenn du deinen eigenen MX betreibst, hast du volle Kontrolle: Zone per DNSSEC signieren, TLSA aus dem MX-Zertifikat erzeugen, veröffentlichen. Das ist der klassische DANE-Weg — siehe DANE für Mailcow.
Mit eigenem MX hinter einem DNSSEC-fähigen DNS-Anbieter. Einige DNS-Anbieter „bieten … möglicherweise DNSSEC als Einstellung an”. Betreibst du deinen eigenen Mailserver hinter einer solchen Zone, kannst du DANE umsetzen — technisch entspricht das dem Selfhosting-Weg.
Wer DANE (für dich) nicht kann
Google Workspace. Google veröffentlicht für seine MX keine TLSA-Einträge — Google setzt beim eingehenden Transport auf MTA-STS („authenticated with a valid public certificate”, TLS 1.2+). Für Google-Workspace-Domains ist DANE also kein Thema; die Alternative heißt MTA-STS für Google Workspace.
Die deutschen Shared-Hoster (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain). Manche bieten DNSSEC-Signierung für deine Zone an — aber ihre Mailserver veröffentlichen keine TLSA-Einträge. Ohne TLSA am MX gibt es kein DANE. DNSSEC allein (ohne mailbezogenes TLSA) bringt für die Transportsicherheit deiner E-Mails nichts.
Was du stattdessen nutzt: MTA-STS
Für alle, die DANE nicht umsetzen können, ist MTA-STS die praktikable Alternative. Es erreicht dasselbe Ziel — erzwungene, authentifizierte TLS-Zustellung — ohne DNSSEC, dafür über eine per HTTPS bereitgestellte Policy-Datei. Wo das gut geht (Google, Microsoft, Mailcow) und wo es hakt (Shared-Hoster), erklären wir in MTA-STS bei Shared-Hostern und den Einzelanleitungen für Google Workspace, Microsoft 365 und Mailcow.
Und in jedem Fall gilt: Ergänze TLS-RPT, damit du Berichte über die TLS-Zustellung bekommst — egal ob du am Ende DANE oder MTA-STS fährst.
Ergebnis prüfen
Der kostenlose MXAudit-Scanner zeigt dir, ob deine Domain DNSSEC-signiert ist, ob TLSA-Einträge für deine MX existieren und wie es um MTA-STS und TLS-RPT steht — der schnelle Weg, um zu sehen, welcher Transportschutz bei deinem Setup überhaupt greift.