SMTP-TLS-Check

Was ist DANE?

DANE steht für DNS-based Authentication of Named Entities und ist ein Verfahren, das TLS-Zertifikate über das Domain Name System verifiziert. Im Kern löst DANE ein grundlegendes Problem der E-Mail-Sicherheit: Wenn zwei Mailserver über STARTTLS eine verschlüsselte Verbindung aufbauen, fehlt traditionell eine zuverlässige Methode, das Zertifikat des Empfängerservers zu verifizieren. Ohne Verifizierung ist die Verbindung anfällig für Man-in-the-Middle-Angriffe, bei denen ein Angreifer ein gefälschtes Zertifikat vorlegt oder die STARTTLS-Aushandlung ganz unterdrückt.

DANE löst dieses Problem, indem es den Fingerabdruck oder den öffentlichen Schlüssel des TLS-Zertifikats als TLSA-Record im DNS der Empfängerdomain veröffentlicht. Voraussetzung dafür ist eine funktionierende DNSSEC-Infrastruktur, die die Integrität des TLSA-Records kryptografisch absichert. Ohne DNSSEC wäre der TLSA-Record selbst manipulierbar — und der gesamte Sicherheitsgewinn hinfällig.

Warum reicht opportunistisches STARTTLS nicht aus?

Die meisten Mailserver unterstützen heute STARTTLS, um die Verbindung zwischen zwei MTAs (Mail Transfer Agents) zu verschlüsseln. Das Problem liegt im Wort "opportunistisch": Wenn der sendende Server eine STARTTLS-Aushandlung anbietet und der empfangende Server signalisiert, kein TLS zu unterstützen, fällt die Verbindung auf unverschlüsselten Klartext zurück. Ein aktiver Angreifer kann genau diesen Fallback erzwingen, indem er die STARTTLS-Antwort des Empfängerservers manipuliert — ein sogenannter STARTTLS-Stripping-Angriff.

Selbst wenn die TLS-Verbindung zustande kommt, prüft der sendende Server bei opportunistischem STARTTLS in der Regel nicht, ob das Zertifikat des Empfängers gültig oder vertrauenswürdig ist. Er akzeptiert jedes beliebige Zertifikat, weil er keine Möglichkeit hat, das richtige zu kennen. Genau diese Lücke schließt DANE: Der sendende Server kennt durch den TLSA-Record das erwartete Zertifikat und kann eine Verbindung ablehnen, wenn das vorgelegte Zertifikat nicht übereinstimmt.

Wie TLSA-Records aufgebaut sind

Ein TLSA-Record besteht aus vier Feldern, die gemeinsam definieren, welches Zertifikat für eine bestimmte TLS-Verbindung erwartet wird. Das Certificate Usage Field bestimmt, ob das gesamte CA-Vertrauensmodell verwendet wird (PKIX-TA/PKIX-EE) oder ob das Zertifikat unabhängig von CAs direkt über DNS verifiziert wird (DANE-TA/DANE-EE). Für Mailserver ist der Wert 3 (DANE-EE, End Entity) am gebräuchlichsten, da er das Zertifikat direkt an den DNS-Record bindet und keine CA-Infrastruktur voraussetzt.

Das Selector Field gibt an, ob der vollständige Zertifikatsinhalt (0) oder nur der öffentliche Schlüssel (1) geprüft wird. Die Verwendung des öffentlichen Schlüssels hat den Vorteil, dass der TLSA-Record bei einer Zertifikatserneuerung nur dann aktualisiert werden muss, wenn sich der Schlüssel selbst ändert — bei einer reinen Verlängerung bleibt der Record gültig. Das Matching Type Field definiert die Hash-Methode: 1 für SHA-256 oder 2 für SHA-512.

Ein typischer TLSA-Record für den MX-Server mail.example.de wird unter _25._tcp.mail.example.de im DNS veröffentlicht und sieht etwa so aus:

3 1 1 a0b1c2d3e4f5... (DANE-EE, Public Key, SHA-256 Hash)

DANE und DNSSEC: untrennbar verbunden

DANE ohne DNSSEC ist wirkungslos. Die gesamte Sicherheit von DANE basiert darauf, dass der TLSA-Record im DNS authentisch und unmanipuliert ist. Nur DNSSEC kann das garantieren, indem es die DNS-Antwort digital signiert und dem anfragenden Server die Verifizierung über die Vertrauenskette ermöglicht. Bevor Sie DANE implementieren, muss Ihre Domain also DNSSEC korrekt konfiguriert haben — prüfbar mit dem DNSSEC-Check.

Diese Abhängigkeit von DNSSEC ist gleichzeitig der größte Vorteil und die größte Hürde von DANE. Der Vorteil: Die Authentizität des Zertifikats wird kryptografisch bewiesen, ohne auf externe Zertifizierungsstellen vertrauen zu müssen. Die Hürde: DNSSEC ist in Deutschland noch wenig verbreitet — nur ein kleiner Teil der .de-Domains hat DNSSEC aktiviert. Für Domains ohne DNSSEC bietet MTA-STS eine Alternative, die ohne DNSSEC auskommt, dafür aber einen anderen Vertrauensanker nutzt.

Verbreitung und Praxisrelevanz

In der E-Mail-Infrastruktur hat DANE vor allem im nordeuropäischen Raum signifikante Verbreitung erreicht. Die Niederlande, Dänemark und Schweden setzen DANE flächendeckend für behördliche E-Mail-Kommunikation ein. In Deutschland fordert das BSI DANE-TLSA als empfohlene Maßnahme in seinen technischen Richtlinien. Große deutsche Mailprovider wie posteo.de und mailbox.org unterstützen DANE sowohl eingehend als auch ausgehend.

Für die E-Mail-Authentifizierung ergänzt DANE die bestehenden Verfahren SPF, DKIM und DMARC um eine entscheidende Dimension: Während SPF, DKIM und DMARC die Absenderauthentizität prüfen, sichert DANE den Transportweg kryptografisch ab. Zusammen bilden sie einen umfassenden Schutz, der sowohl Inhaltsmanipulation als auch Transportangriffe verhindert.

DANE-Konfiguration prüfen

Unser SMTP-TLS-Check analysiert die TLSA-Records Ihrer MX-Server und prüft, ob die DANE-Konfiguration korrekt ist. Das Tool verifiziert die DNSSEC-Signatur der TLSA-Records, gleicht den hinterlegten Fingerabdruck mit dem tatsächlich ausgelieferten TLS-Zertifikat ab und prüft die Certificate-Usage- und Matching-Type-Felder auf korrekte Werte. Ergänzend empfiehlt sich der E-Mail Security Check, um sicherzustellen, dass auch die Absenderauthentifizierung über SPF, DKIM und DMARC korrekt konfiguriert ist.