DANE und TLSA für SMTP ausrollen, ohne Mail zu verlieren

Warum DANE — und warum die Vorsicht

SMTP zwischen Mailservern läuft bis heute auf opportunistischem TLS. Der sendende Server bietet STARTTLS an, der empfangende nimmt an, alle sind verschlüsselt — außer jemand im Netzwerkpfad filtert die STARTTLS-Fähigkeit aus dem Dialog, dann fallen beide Seiten klaglos auf Klartext zurück. Nichts alarmiert, nichts schlägt fehl. Der Sender hat keine unabhängige Möglichkeit zu wissen, dass dein Server eigentlich TLS mit einem bestimmten Schlüssel hätte anbieten müssen.

DANE schließt diese Lücke, indem die erwartete Zertifikatsbindung im DNS publiziert wird — DNSSEC-signiert. Ein validierender Sender schlägt den TLSA-Record deines MX-Hosts nach, und ab diesem Moment ist TLS mit passendem Schlüssel Pflicht: kein Record-Match, keine Zustellung. Das ist Stärke und Risiko in einem Satz. Publiziere einen falschen Record, und DANE-validierende Sender — darunter große europäische Provider und ein wachsender Anteil sicherheitsbewusster Betreiber — beginnen, Mail abzuweisen, die sonst angekommen wäre.

Voraussetzungen, über die du nicht verhandeln solltest

Erstens: DNSSEC auf der Zone, die deine MX-Hostnamen trägt — nicht auf der Empfängerdomain, sondern auf der Zone des MX-Hosts. Ein unsignierter TLSA-Record ist Dekoration: Das gesamte Design setzt voraus, dass der Record selbst nicht fälschbar ist, und nur eine validierte DNSSEC-Kette leistet das. Prüfe mit dem DNSSEC-Validator, dass die Zone secure meldet — nicht bloß, dass Records existieren.

Zweitens: stabiles Schlüsselmanagement. Entscheide vor der ersten Publikation, ob deine Zertifikatsautomatisierung den privaten Schlüssel über Renewals hinweg behält. Mit stabilem Schlüsselpaar übersteht das gängige TLSA-Profil 3 1 1 — DANE-EE, SubjectPublicKeyInfo, SHA-256 — jede Routine-Erneuerung unangetastet. Rotiert die Automatisierung den Schlüssel bei jedem Renewal, wird jedes Renewal zur koordinierten DNS-Änderung — und du hast dich für genau das Betriebsrisiko angemeldet, an dem die meisten DANE-Deployments scheitern.

Drittens: Monitoring, das auf das Richtige schaut — den Digest des Schlüssels, den dein MX gerade präsentiert, gegen den Digest im DNS. Zertifikatsablauf-Monitoring deckt das nicht ab. Der gefährliche Zustand ist ein gültiges, frisch erneuertes Zertifikat, dessen Schlüssel nicht mehr zum publizierten Record passt.

Die Records entwerfen

TLSA-Records liegen an einem Owner-Namen, der aus dem Dienst abgeleitet ist, nicht aus der Domain: _25._tcp.mail.example.com für SMTP auf mail.example.com. Jeder MX-Host braucht sein eigenes Record-Set; die Empfängerdomain selbst trägt nichts. Baue die Digests aus den echten Zertifikaten mit dem TLSA-Record-Prüfer/Generator — er leitet die Association-Daten aus einem eingefügten Zertifikat oder dem Live-Zertifikat des Hosts ab und difft das Ergebnis gegen die bestehende DNS-Antwort.

Bei der Parameterwahl ist der Konsens des Ökosystems eindeutig: 3 1 1 als Primär-Record. DANE-EE pinnt deinen End-Entity-Schlüssel direkt, braucht senderseitig keinen Kettenbau und ist mit dem SPKI-Selector renewal-fest, solange der Schlüssel bleibt. Die Trust-Anchor-Variante 2 1 1 hat legitime Einsätze — die CA statt jedes Host-Schlüssels pinnen —, verlangt aber die korrekt ausgelieferte vollständige Kette und bringt mehr bewegliche Teile mit. Starte mit 3 1 1; Komplexität erst, wenn es einen Grund gibt.

Die Ausroll-Sequenz

Publiziere die TLSA-Records und warte dann — bewusst —, bevor du den Job für erledigt hältst. Die Records propagieren mit ihrer TTL; validierende Sender setzen durch, sobald sie sie sehen. Das ist das Fenster, in dem ein Tippfehler als Rinnsal von Bounces genau der bestgeführten Sender-Infrastrukturen auftaucht — beobachte in den ersten Tagen deinen Inbound-Flow und die MX-Logs auf TLS-Fehler.

Für Rollover gilt eine eiserne Regel: DNS zuerst, Dienst danach. Publiziere den Record für den nächsten Schlüssel neben dem aktuellen, warte die Record-TTL ab, wechsle Zertifikat oder Schlüssel auf dem MX, entferne dann den alten Record. TLSA-Validierung besteht, sobald irgendein publizierter Record passt — genau das macht die Überlappung sicher. Das Warten zu überspringen ist der klassische selbstverschuldete Ausfall: Der neue Schlüssel geht live, während Caches noch ausschließlich den alten Digest kennen.

Verifiziere den Endzustand von außen. Der DANE-Validator beurteilt das Deployment wie ein validierender Sender — Owner-Name, Parameter-Plausibilität, DNSSEC-Kontext und Live-Zertifikatsabgleich in einem Durchlauf —, und der SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft zeigt das umgebende Transportbild inklusive MTA-STS und TLS-RPT.

Fehlerbilder aus der Praxis

Das Renewal, das den Schlüssel wechselte: Die Automatisierung rotierte das Schlüsselpaar, das Zertifikat ist gültig, Browser sind zufrieden — und DANE-validierende Sender bouncen alles. Von außen ist das von einem Angriff nicht zu unterscheiden, und genau so behandeln Sender es. Prävention heißt Schlüssel-Persistenz oder disziplinierte Rollover; Detektion heißt Digest-Monitoring, nicht Zertifikats-Monitoring.

Der vergessene Sekundär-MX: Der Primäre ist perfekt, der Backup-MX hat keinen oder einen veralteten TLSA-Record — und Mail, die während der Wartung failovert, bounct zum dümmsten Zeitpunkt. Jeder Host im MX-Set braucht dieselbe Sorgfalt; prüfe sie einzeln, beginnend mit dem MX-Record-Prüfung.

Der DNSSEC-Ablauf, der DANE mitreißt: RRSIG-Signaturen laufen ab, weil die Re-Signierungs-Automatik gestorben ist, die Zone geht bogus — und mit ihr scheitert jeder TLSA-Lookup. DANE erbt jedes DNSSEC-Fehlerbild; die Signier-Pipeline verdient dieselbe Monitoring-Aufmerksamkeit wie der Mail-Stack selbst.