DANE/TLSA-Test für Mailserver

Dieser kostenlose Test prüft für jeden MX Ihrer Domain, ob TLSA-Records vorhanden sind, ob die Zone DNSSEC-signiert ist und ob die TLSA-Daten zum tatsächlich ausgelieferten Serverzertifikat passen – die drei Bedingungen, ohne die DANE nicht funktioniert. Jetzt Domain prüfen → Sie brauchen einen TLSA-Record? Der kostenlose TLSA/DANE-Generator erzeugt den empfohlenen 3 1 1-Record aus Ihrem Zertifikat.

Was ist DANE?

DANE (DNS-Based Authentication of Named Entities, RFC 6698; für SMTP: RFC 7672) verankert das Zertifikat eines Mailservers direkt im DNS: Ein TLSA-Record veröffentlicht einen Hash des Zertifikats bzw. Schlüssels, den sendende Server vor dem Verbindungsaufbau abrufen und per DNSSEC validieren. Damit können Sender Verschlüsselung erzwingen – klassisches STARTTLS ist opportunistisch und lässt sich von einem Angreifer im Pfad einfach herausfiltern (Downgrade auf Klartext). DANE schließt genau diese Lücke und macht den Mailtransport zusätzlich unabhängig vom Vertrauen in einzelne Zertifizierungsstellen.

Der empfohlene TLSA-Record: 3 1 1

Ein TLSA-Record für den MX mail.beispiel.de sieht so aus:

_25._tcp.mail.beispiel.de. IN TLSA 3 1 1 <SHA-256-Hash des Public Keys>

Usage 3 (DANE-EE): Es zählt das Serverzertifikat selbst – keine CA-Kette nötig.
Selector 1: Gehasht wird nur der öffentliche Schlüssel (SubjectPublicKeyInfo), nicht das ganze Zertifikat.
Matching 1: SHA-256 als Hash-Verfahren.

Der Vorteil von 3 1 1: Zertifikatsverlängerungen (z. B. alle 90 Tage bei Let's Encrypt) ändern den Record nicht, solange derselbe Schlüssel weiterverwendet wird. Bei einem geplanten Schlüsselwechsel publiziert man den Hash des neuen Schlüssels als zweiten TLSA-Record, bevor der Wechsel stattfindet (Rollover), und entfernt den alten danach.

DANE in Deutschland: BSI TR-03108

Die Technische Richtlinie BSI TR-03108 („Sicherer E-Mail-Transport“) des Bundesamts für Sicherheit in der Informationstechnik verlangt von zertifizierten E-Mail-Diensteanbietern unter anderem DNSSEC und DANE für den empfangenden Mailverkehr. Posteo ist nach dieser Richtlinie zertifiziert; auch andere deutsche Anbieter wie mailbox.org erfüllen ihre Anforderungen und setzen DANE produktiv ein. Wer selbst TLSA-Records publiziert, stellt sicher, dass eingehende Mail von solchen Anbietern zwingend verschlüsselt und authentifiziert zugestellt wird.

Häufige Fehler – und wie Sie sie beheben

TLSA ohne DNSSEC: wirkungslos – validierende Sender ignorieren die Records. Zuerst die Zone signieren und den DS-Record beim Registrar hinterlegen.
TLSA passt nicht zum Zertifikat: häufig nach einem Serverumzug oder Schlüsselwechsel ohne Rollover. Für sendende Server, die DANE validieren, schlägt die Zustellung dann fehl. Mit 3 1 1 und stabilem Schlüssel passiert das bei reinen Verlängerungen nicht.
Nur ein MX abgedeckt: Jeder MX-Host braucht eigene TLSA-Records – auch Backup-MX.
Record am falschen Namen: Der TLSA-Record gehört an _25._tcp.<MX-Hostname>, nicht an die Domain selbst.

Der Domain-Sicherheitscheck deckt alle diese Fälle auf: Er verbindet sich mit jedem MX, gleicht die TLSA-Records mit dem live ausgelieferten Zertifikat ab und prüft die DNSSEC-Kette.

Häufige Fragen

Funktioniert DANE ohne DNSSEC?

Nein. Ohne DNSSEC kann ein Angreifer die TLSA-Records selbst fälschen oder unterdrücken – die Vertrauenskette bricht. Ein TLSA-Record in einer unsignierten Zone wird von validierenden Sendern ignoriert und bietet keinen Schutz.

Brauche ich DANE, wenn ich schon MTA-STS habe?

Die beiden Mechanismen ergänzen sich. DANE verankert das Vertrauen per DNSSEC direkt im DNS und funktioniert unabhängig von Web-PKI und CAs; MTA-STS verteilt seine Policy per HTTPS und deckt Sender ab, die kein DNSSEC validieren. Wer beides veröffentlicht, erreicht die größte Sender-Abdeckung.

Welchen TLSA-Record sollte ich verwenden?

Empfohlen ist 3 1 1: Usage 3 (DANE-EE, das Serverzertifikat selbst), Selector 1 (nur der öffentliche Schlüssel), Matching 1 (SHA-256-Hash). Diese Kombination übersteht Zertifikatsverlängerungen, solange der Schlüssel gleich bleibt; bei einem Schlüsselwechsel publiziert man den neuen Hash als zweiten Record vorab.

Quellen

RFC 7672 (DANE für SMTP) ↗ · RFC 6698 (TLSA) ↗ · BSI TR-03108 ↗