SaaSFort DANE und MTA-STS existieren beide, um denselben Angriff zu verhindern: einen Angreifer auf dem Übertragungsweg, der STARTTLS aus einer SMTP-Sitzung entfernt, damit Mail an Ihre Domain im Klartext ankommt.
Sie unterscheiden sich darin, worauf sie vertrauen, um die Echtheit der Richtlinie zu belegen, und dieser eine Unterschied entscheidet, was Sie diese Woche ausrollen können.
Der Vertrauensanker ist der ganze Unterschied
DANE veröffentlicht im DNS einen TLSA-Eintrag, der das Zertifikat festlegt, das Ihr Mailserver vorlegen wird. Der Eintrag wird über DNSSEC authentifiziert. Das System der Zertifizierungsstellen ist nicht beteiligt, sodass eine CA, die fälschlich ein Zertifikat für Ihre Domain ausstellt, damit Ihre Mail nicht abfangen kann.
MTA-STS veröffentlicht eine Richtliniendatei über HTTPS unter einer bekannten URL auf einer mta-sts.-Subdomain. Die Richtlinie wird durch das Zertifikat dieser Subdomain authentifiziert, womit das CA-System die Vertrauenswurzel bildet.
Kryptografisch ist DANE stärker. Betrieblich ist MTA-STS heute auf jeder Domain einsetzbar, weil es kein DNSSEC voraussetzt.
Der Vergleich, der die Entscheidung trägt
| DANE | MTA-STS | |
|---|---|---|
| Vertrauensanker | DNSSEC | Zertifizierungsstelle |
| Voraussetzung | Signierte Zone | HTTPS-Host für eine Subdomain |
| Heute ohne Projekt einsetzbar | Nur wenn DNSSEC schon aktiv ist | Ja |
| Widersteht CA-Fehlausstellung | Ja | Nein |
| Widersteht DNS-Manipulation ohne DNSSEC | Ja | Ja, Richtlinie ist CA-authentifiziert |
| Unterstützung bei Absendern | Weit verbreitet, besonders bei europäischen Providern | Weit verbreitet, besonders bei großen Mailbox-Providern |
Die letzte Zeile erklärt, warum die ehrliche Antwort “beides” lautet. Absender, die beides unterstützen, bevorzugen DANE und fallen auf MTA-STS zurück, wenn keine DNSSEC-Validierung möglich ist. Sie decken nur teilweise überlappende Mengen sendender Server ab, sodass der Einsatz nur eines Mechanismus eine Lücke lässt, die der andere geschlossen hätte.
BSI TR-03108 erwartet beides, und das ist die Begründung dahinter, nicht übertriebene Vorsicht.
Warum die Reihenfolge MTA-STS zuerst lautet
Für einen SaaS-Anbieter ohne DNSSEC in der Zone ist die Abfolge keine echte Wahl.
DNSSEC zu aktivieren ist ein echtes Vorhaben. Es berührt die Registrarkonfiguration, die Schlüsselverwaltung und das Rollover-Verfahren, und es hat einen Fehlerfall, in dem ein missglücktes Rollover Ihre gesamte Domain unauflösbar macht, nicht nur Ihre Mail. Es lohnt sich. Es lohnt sich nicht an demselben Nachmittag, an dem Sie feststellen, dass Sie keinerlei Transportsicherheit haben.
MTA-STS plus TLS-RPT sind zwei DNS-Einträge und eine statische Datei, mit einem Testmodus, der den Rollout beobachtbar macht, bevor er verbindlich wird. Sie können es vor der Mittagspause im Testmodus live haben und drei Wochen später erzwingen, sobald die Berichte sauber sind.
Also: MTA-STS und TLS-RPT jetzt, DNSSEC und DANE als terminiertes Vorhaben.
Die einzige Ausnahme ist eine Domain, die bereits DNSSEC hat. Ergänzen Sie dann die TLSA-Einträge gleich mit, da der Zusatzaufwand bei etwa einer Stunde liegt.
Der Fehler, den beide Seiten machen
Bei MTA-STS ist der Fehler, in mode: testing zu verharren. Der Testmodus meldet Fehler und stellt dennoch zu, eine dort geparkte Domain hat also den Anschein des Kontrollmechanismus und keinen Schutz. Setzen Sie den Kalendereintrag für die Umstellung auf enforce beim Rollout, nicht danach.
Bei DANE ist der Fehler ein TLSA-Eintrag, der nach einer Erneuerung nicht mehr zum tatsächlich ausgelieferten Zertifikat passt. Mit Zertifikatslaufzeiten auf dem Weg zu 47 Tagen verschärft sich dieses Risiko: Jede Erneuerung ist eine Gelegenheit für ein veraltetes Pinning, und ein veralteter TLSA-Eintrag verschlechtert sich nicht sanft, er blockiert Mail.
Pinnen Sie den öffentlichen Schlüssel der CA statt des Endzertifikats (TLSA-Usage 2 oder 3, Selector 1), und automatisieren Sie die Aktualisierung des Eintrags zusammen mit der Erneuerung. Ein DANE-Deployment ohne automatisierte TLSA-Pflege wird brechen, und die sinkenden Laufzeiten entscheiden nur, wann.
Was TLS-RPT für beide leistet
Was Sie auch ausrollen: TLS-RPT ist das, was Ihnen sagt, dass es funktioniert.
_smtp._tls.example.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Tägliches JSON von sendenden Providern mit erfolgreichen und fehlgeschlagenen Aushandlungen samt Fehlergrund. Es fängt den veralteten TLSA-Eintrag, den in der MTA-STS-Richtlinie fehlenden MX-Host und das abgelaufene Zertifikat auf dem Zweitmailserver, den seit zwei Jahren niemand angesehen hat.
Rollen Sie TLS-RPT vor beiden Richtlinienmechanismen aus, damit der erste gelesene Bericht eine Ausgangsbasis ist und kein Zwischenfall.
Zuordnung
- NIS2 Artikel 21(2)(h) Kryptografie, 21(2)(e) Netzsicherheit.
- ISO/IEC 27001:2022 A.8.24 und A.5.14 Informationsübertragung.
- DORA Artikel 9 für Finanzunternehmen.
- BSI TR-03108 im deutschen Aufsichtskontext.
Kurzfassung
DANE ist stärker, MTA-STS ist sofort verfügbar, und beide decken unterschiedliche Absender ab: Das Ziel ist also beides.
Beginnen Sie mit TLS-RPT für Sichtbarkeit, dann MTA-STS im Testmodus, dann erzwingen. Planen Sie DNSSEC und DANE als Folgevorhaben, nicht als Grund, gar nichts zu tun.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.