DANE und TLSAManipulationssichererE-Mail-Transport
DANE bindet das Zertifikat des empfangenden Mailservers per DNSSEC fest im DNS. Damit wird die TLS-Verschlüsselung zwischen Mailservern erzwungen und gegen Downgrade- sowie Man-in-the-Middle-Angriffe abgesichert, ohne Abhängigkeit von der öffentlichen Zertifikatswelt.
_25._tcp.mx.example.de. IN TLSA ( 3 1 1 d2abef7c... ) mx.example.de. IN RRSIG ( TLSA ECDSAP256SHA256 ... )
DANE schließt die letzte große Lücke der E-Mail-Verschlüsselung im Transport. SPF, DKIM und DMARC sichern die Authentizität des Absenders. DANE und TLSA sorgen dafür, dass der Weg der Nachricht zwischen den Mailservern tatsächlich verschlüsselt und der Empfänger-Server der echte ist.
Klassisches STARTTLS verschlüsselt nur opportunistisch. Ein Angreifer in der Übertragungsstrecke kann die Verschlüsselung abschalten oder ein eigenes Zertifikat unterschieben, ohne dass es auffällt. DANE beendet dieses Risiko, indem der Fingerabdruck des erwarteten Zertifikats über einen TLSA-Record im DNS hinterlegt und per DNSSEC fälschungssicher signiert wird.
DANE, TLSA und DNSSEC verständlich erklärt
Drei Bausteine, die zusammen geprüfte Transportverschlüsselung ergeben.
DANE
DNS-based Authentication of Named Entities
Ein Verfahren nach RFC 7672, das dem sendenden Mailserver per DNS mitteilt, welches Zertifikat der empfangende Server vorweisen muss. Trifft die Bindung nicht zu, wird die Zustellung verweigert statt unverschlüsselt fortgesetzt.
TLSA-Record
der DNS-Eintrag hinter DANE
Im TLSA-Record liegt der Hash des Mailserver-Zertifikats oder des öffentlichen Schlüssels. Der sendende Server vergleicht diesen Hash mit dem Zertifikat aus dem TLS-Handshake und erkennt jede Abweichung sofort.
DNSSEC
die kryptografische Absicherung des DNS
DANE setzt zwingend DNSSEC voraus. Erst die Signatur der DNS-Zone stellt sicher, dass der TLSA-Record selbst nicht manipuliert wurde. Ohne DNSSEC gäbe es keine vertrauenswürdige Grundlage für die Zertifikatsbindung.
Warum opportunistisches STARTTLS nicht genügt
Die Standardverschlüsselung im SMTP-Transport lässt sich aushebeln, ohne dass Absender oder Empfänger es bemerken.
verschlüsselt nur, wenn beide Seiten es anbieten, und fällt sonst still auf Klartext zurück
ein Angreifer in der Strecke kann ein eigenes Zertifikat vorlegen, ohne erkannt zu werden
die TLS-Aushandlung lässt sich aktiv entfernen, sodass die Nachricht im Klartext fließt
Bei opportunistischer Verschlüsselung prüft der sendende Server nicht, ob das Zertifikat der Gegenstelle echt ist. Genau hier setzen Stripping- und Downgrade-Angriffe an. Sie entfernen den TLS-Hinweis aus der Serverantwort oder schieben ein gefälschtes Zertifikat unter. Die Nachricht wird zugestellt, der Schutz war jedoch eine Illusion. DANE verhindert das, weil die erwartete Zertifikatsbindung bereits vor dem Verbindungsaufbau feststeht.
So funktioniert die Zertifikatsbindung mit DANE
Vier Schritte vom DNS-Lookup bis zur erzwungenen Verschlüsselung.
- 1
DNSSEC-Lookup der Empfängerdomäne
Der sendende Mailserver ermittelt den zuständigen Mailserver und prüft, ob die DNS-Antworten gültig signiert sind. Nur signierte Antworten werden akzeptiert.
- 2
TLSA-Record abrufen
Für den Mailserver wird der TLSA-Record unter dem MX-Namen abgefragt. Er enthält den erwarteten Zertifikats-Fingerabdruck.
- 3
TLS-Handshake abgleichen
Im Handshake legt der empfangende Server sein Zertifikat vor. Der sendende Server vergleicht es mit dem Hash aus dem TLSA-Record.
- 4
Erzwingen oder verweigern
Stimmt die Bindung, fließt die Nachricht verschlüsselt. Stimmt sie nicht, wird die Zustellung verweigert und nicht etwa unverschlüsselt fortgesetzt.
DANE und MTA-STS im Vergleich
Beide erzwingen TLS im Transport, mit unterschiedlichem Vertrauensanker. In der Praxis ergänzen sie sich.
| Eigenschaft | DANE und TLSA | MTA-STS |
|---|---|---|
| Vertrauensanker | DNSSEC-signierter TLSA-Record | öffentliche Zertifikatswelt und HTTPS-Richtlinie |
| Schutz beim ersten Kontakt | sofort wirksam | Vertrauen erst nach erstem Kontakt |
| Voraussetzung | DNSSEC erforderlich | kein DNSSEC nötig, dafür Webserver für die Richtlinie |
| Downgrade-Schutz | kryptografisch erzwungen | richtlinienbasiert erzwungen |
| BSI TR-03108 | verpflichtend | optional anerkannt |
Conbool unterstützt beide Verfahren. DANE deckt alle Sender ab, die DNSSEC auswerten, MTA-STS ergänzt für Sender ohne DNSSEC. Die Kombination schließt die Lücke des ersten Kontakts vollständig.
DANE ist Pflicht nach BSI TR-03108
Die Technische Richtlinie BSI TR-03108 für sicheren E-Mail-Transport macht DANE für zertifizierte Diensteanbieter verbindlich.
Das Bundesamt für Sicherheit in der Informationstechnik stuft DANE als wirksamen und skalierbaren Schutz gegen Man-in-the-Middle-Bedrohungen im verschlüsselten E-Mail-Transport ein. MTA-STS wird in Version 2.0 als optionale Ergänzung anerkannt, ersetzt DANE jedoch nicht. Wer Transportsicherheit nach dem aktuellen Stand der Technik nachweisen will, kommt an DANE nicht vorbei.
- Verbindliche Zertifikatsbindung per TLSA-Record
- DNSSEC als signierte Vertrauensbasis
- Nachweisbarer Schutz gegen Downgrade und Manipulation
- Anschlussfähig an NIS2 und branchenspezifische Vorgaben
DANE eingehend und ausgehend mit Conbool MailGuard
Conbool MailGuard betreibt DANE in beide Richtungen, ohne dass eigene Mailserver umgebaut werden müssen.
TLSA-Records veröffentlicht
Für die geschützten Domänen wird die Zertifikatsbindung im DNS bereitgestellt, sodass externe Sender DANE erzwingen können.
Ausgehende Validierung
Ausgehende Nachrichten prüfen den TLSA-Record des Empfängers und stellen nur bei korrekter Bindung zu.
DNSSEC-validierender Resolver
Ein eigener validierender Resolver stellt sicher, dass nur signierte DNS-Antworten als Grundlage dienen.
Sicherer Fallback
Temporäre DNS-Fehler führen zu kontrolliertem Aufschub statt zu unverschlüsselter Zustellung. Schutz wird nie stillschweigend abgeschaltet.
Schlüsselrollierung ohne Bruch
Zertifikatswechsel werden mit doppelten TLSA-Records begleitet, sodass kein Zustellungsausfall entsteht.
Lückenlose Protokollierung
Jede DANE-Entscheidung wird nachvollziehbar dokumentiert und steht für Audits bereit.
Häufige Fragen zu DANE und TLSA
Was ist der Unterschied zwischen DANE und TLSA?
Benötigt DANE zwingend DNSSEC?
Worin unterscheidet sich DANE von MTA-STS?
Ist DANE für Microsoft 365 oder Exchange relevant?
Was passiert bei einem Zertifikatswechsel?
Bricht DANE die Zustellung, wenn ein Empfänger es falsch konfiguriert hat?
Wie lässt sich prüfen, ob eine Domäne DANE nutzt?
Reicht DANE allein für sicheren E-Mail-Transport?
Ist DANE auch im Betrieb beim eigenen Anbieter möglich?
Weitere Bausteine der Transportsicherheit
MTA-STS
Erzwungene TLS-Verschlüsselung für alle Sender, auch ohne DNSSEC.
TLS-RPT
Berichte über Transportfehler, damit keine stille Verschlüsselungslücke unentdeckt bleibt.
Directory-Harvesting-Schutz
Abwehr von Angriffen, die gültige E-Mail-Adressen am Server abgreifen.
MailGuard
Das E-Mail-Security-Gateway, das alle Transport- und Inhaltsschutzfunktionen bündelt.
Transportsicherheit nachweisbar machen
Der kostenlose Mail-Check zeigt in wenigen Minuten, ob DANE, DNSSEC und Transportverschlüsselung der eigenen Domäne korrekt greifen.