Transportsicherheit nach BSI TR-03108

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.

Domain kostenlos prüfenMailGuard ansehen
TLSA-Record am MX-Hostnamen
_25._tcp.mx.example.de.  IN TLSA (
  3 1 1  d2abef7c...  )

mx.example.de.  IN  RRSIG  (
  TLSA  ECDSAP256SHA256 ... )
DNSSEC validiert
DNSSECTLSASTARTTLSRFC 7672

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. Veröffentlicht wird er unter dem Namen des Mailservers, nicht unter der Empfängerdomäne. 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.

STARTTLS

Warum opportunistisches STARTTLS nicht genügt

Die Standardverschlüsselung im SMTP-Transport lässt sich aushebeln, ohne dass Absender oder Empfänger es bemerken.

STARTTLS

verschlüsselt nur, wenn beide Seiten es anbieten, und fällt sonst still auf Klartext zurück

MITM

ein Angreifer in der Strecke kann ein eigenes Zertifikat vorlegen, ohne erkannt zu werden

Downgrade

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. 1

    DNSSEC-Lookup der Empfängerdomäne

    Der sendende Mailserver ermittelt über das MX-RRset den zuständigen Mailserver und prüft, ob die DNS-Antworten gültig signiert sind. Nur signierte Antworten taugen als Grundlage für die Bindung.

  2. 2

    TLSA-Record am MX-Hostnamen abrufen

    Abgefragt wird der Record unter dem Namen _25._tcp. gefolgt vom MX-Hostnamen, nicht unter der Empfängerdomäne. Nur wenn eine Domäne gar keinen MX-Eintrag führt, tritt sie selbst an diese Stelle. Der Record enthält den erwarteten Zertifikats-Fingerabdruck.

  3. 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. 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.

EigenschaftDANE und TLSAMTA-STS
VertrauensankerDNSSEC-signierter TLSA-Recordöffentliche Zertifikatswelt und HTTPS-Richtlinie
Schutz beim ersten Kontaktsofort wirksamVertrauen erst nach erstem Kontakt
VoraussetzungDNSSEC erforderlichkein DNSSEC nötig, dafür Webserver für die Richtlinie
Downgrade-Schutzkryptografisch erzwungenrichtlinienbasiert erzwungen
BSI TR-03108verpflichtendoptional 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 mit Conbool MailGuard: ausgehend erzwungen, eingehend am eigenen MX

Ausgehend prüft Conbool MailGuard jede Zustellung gegen die Zertifikatsbindung des Empfängers. Eingehendes DANE setzt einen selbst betriebenen Mailserver voraus, im OnPrem-Betrieb oder als Partner mit eigenem MX.

TLSA-Record aus dem Zertifikat ermittelt

Conbool ermittelt den passenden TLSA-Record aus dem Zertifikat, das der MX im Handshake vorlegt, und zeigt ihn mit vollständigem Eintragsnamen an. Der Record gehört an den MX-Hostnamen, nicht an die eigene Domäne. Dieselbe Prüfung zeigt, ob ein bereits veröffentlichter Record noch zum Zertifikat passt und ob er DNSSEC-gesichert ist.

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.

Werkzeuge für den Zertifikatswechsel

Conbool zeigt den TLSA-Record des aktuell ausgelieferten Zertifikats und meldet, sobald ein veröffentlichter Record nicht mehr dazu passt. Den Wert für ein neues Zertifikat bildet der Betreiber des MX aus dem neuen Schlüssel; alt und neu gehören zeitweise nebeneinander ins DNS, das neue Zertifikat wird erst nach der Verbreitung ausgeliefert.

Jede Entscheidung im Protokoll

Jede DANE-Entscheidung steht mit Ergebnis im Zustellprotokoll und ist dort nachvollziehbar.

Häufige Fragen zu DANE und TLSA

Was ist der Unterschied zwischen DANE und TLSA?
DANE ist das Verfahren, das geprüfte Transportverschlüsselung im SMTP erzwingt. Der TLSA-Record ist der konkrete DNS-Eintrag, in dem der Fingerabdruck des erwarteten Zertifikats steht. DANE nutzt den TLSA-Record als Grundlage für den Abgleich.
Benötigt DANE zwingend DNSSEC?
Ja. Ohne DNSSEC ließe sich der TLSA-Record selbst manipulieren. Erst die signierte DNS-Zone macht die Zertifikatsbindung vertrauenswürdig. DNSSEC ist daher die Grundvoraussetzung für DANE.
Worin unterscheidet sich DANE von MTA-STS?
DANE verankert das Vertrauen kryptografisch im DNS über DNSSEC und schützt bereits beim ersten Kontakt. MTA-STS nutzt die öffentliche Zertifikatswelt und eine über HTTPS verteilte Richtlinie, vertraut beim ersten Kontakt jedoch zunächst. Beide Verfahren lassen sich kombinieren.
Ist DANE für Microsoft 365 oder Exchange relevant?
Ausgehend ja: Conbool MailGuard übernimmt die DANE-Validierung unabhängig vom dahinterliegenden Postfachdienst. Eingehend hängt DANE an dem MX, der die Mail annimmt, und an dem Record, den dessen Betreiber dort veröffentlicht. Beim eigenen MX aus OnPrem- oder Partnerbetrieb liegt beides in eigener Hand.
Was passiert bei einem Zertifikatswechsel?
Ein Zertifikatswechsel bricht die Bindung, sobald der veröffentlichte TLSA-Record nicht mehr zum neuen Schlüssel passt. Deshalb gehören alter und neuer Record zeitweise nebeneinander ins DNS, und das neue Zertifikat wird erst nach der Verbreitung ausgeliefert. Veröffentlicht und erneuert wird der Record von der Stelle, die den betroffenen MX und dessen DNS-Zone betreibt, einen automatischen Austausch durch Conbool gibt es nicht.
Bricht DANE die Zustellung, wenn ein Empfänger es falsch konfiguriert hat?
Bei einer ungültigen Bindung wird die Zustellung bewusst verweigert statt unverschlüsselt fortgesetzt. Temporäre DNS-Probleme führen zu kontrolliertem Aufschub mit erneuten Versuchen, nicht zu einem stillen Verlust.
Wie lässt sich prüfen, ob eine Domäne DANE nutzt?
Der kostenlose Mail-Check von Conbool wertet den TLSA-Record am MX-Hostnamen aus und zeigt, ob die Zertifikatsbindung korrekt und DNSSEC-validiert ist. Das Ergebnis kommt als kompakter Bericht zurück.
Reicht DANE allein für sicheren E-Mail-Transport?
DANE sichert die Transportstrecke und die Identität des Empfänger-Servers. Für die Authentizität des Absenders sind zusätzlich SPF, DKIM und DMARC nötig. TLS-RPT liefert die Sichtbarkeit über Transportfehler. Erst zusammen entsteht ein vollständiger Schutz.
Ist DANE auch im Betrieb beim eigenen Anbieter möglich?
Ja. Im OnPrem-Betrieb von Conbool wird der validierende Resolver lokal betrieben, sodass DANE auch in abgeschotteten Umgebungen ohne Abhängigkeit von externen Resolvern funktioniert. Dort liegt auch der eingehende MX in eigener Hand, samt der DNS-Zone, in der sein TLSA-Record steht.
Steht im Zustellnachweis, dass DANE gegriffen hat?
Ja. Das Nachweisdokument einer Nachricht weist die Verbindung aus, mit der sie übergeben wurde: DANE mit Prüfung des Ziels über den TLSA-Eintrag, MTA-STS nach Richtlinie des Empfängers oder einfaches TLS, jeweils mit der Angabe, ob die Verschlüsselung zwingend war. Damit belegen Sie nicht nur, dass die Nachricht ankam, sondern auch, dass sie auf dem Weg dorthin nicht unverschlüsselt umgeleitet werden konnte.

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.

Domain kostenlos prüfenBeratung anfragen