MTA-STS oder DANE: Welcher TLS-Standard schützt den E-Mail-Transport besser?
Die Verschlüsselung zwischen Mailservern ist seit Jahren ein Sorgenkind. Das verbreitete STARTTLS verschlüsselt nur dann, wenn beide Seiten zustimmen, und fällt bei einem Fehler ohne Warnung auf eine unverschlüsselte Zustellung zurück. Zwei Standards schließen diese Lücke und machen aus der freiwilligen eine verbindliche Verschlüsselung: MTA-STS und DANE. Beide verfolgen dasselbe Ziel, gehen beim Vertrauen aber grundlegend verschiedene Wege. Genau diese Unterscheidung entscheidet darüber, welcher Standard für Ihre Domäne der richtige ist.
Dieser Vergleich erklärt, wie sich MTA-STS und DANE im Vertrauensanker, in der DNSSEC-Voraussetzung und im Verhalten beim Erstkontakt unterscheiden, warum das BSI den parallelen Einsatz empfiehlt und wann welcher Standard die bessere Wahl ist.
Die Kurzfassung vorweg
TL;DR: MTA-STS und DANE erzwingen beide TLS im E-Mail-Transport, vertrauen dem Serverzertifikat aber unterschiedlich. DANE bindet das Zertifikat über einen signierten TLSA-Eintrag im DNS und setzt zwingend DNSSEC voraus. MTA-STS kommt ohne DNSSEC aus, stützt sich auf öffentliche Zertifizierungsstellen und eine über HTTPS abgerufene Richtlinie, vertraut dieser aber erst nach dem Erstkontakt (Trust on First Use). Die belastbare Empfehlung lautet daher: Ist DNSSEC vorhanden, betreiben Sie beide parallel. Fehlt DNSSEC, beginnen Sie mit MTA-STS.
Das gemeinsame Problem: STARTTLS ist freiwillig
Bevor der Vergleich greift, lohnt der Blick auf das Problem, das beide Standards lösen. STARTTLS verschlüsselt die Verbindung zwischen zwei Mailservern, sobald beide Seiten dazu bereit sind. Der Schwachpunkt liegt im Wort opportunistisch: Es gibt keine verbindliche Erwartung, dass überhaupt verschlüsselt wird. Ein Angreifer in der Position eines Mittelsmanns kann das STARTTLS-Signal aus der Serverkommunikation entfernen. Beide Seiten glauben dann, die Gegenstelle könne nicht verschlüsseln, und die Nachricht geht im Klartext über die Leitung. Weil STARTTLS bei jedem Fehler still auf Klartext zurückfällt, bleibt dieser Downgrade-Angriff unsichtbar.
Sowohl MTA-STS als auch DANE drehen diese Logik um. Eine fehlende oder nicht vertrauenswürdige TLS-Verbindung ist kein Grund zum Zurückfallen, sondern ein Grund, die Zustellung zu verweigern. Der Unterschied liegt allein darin, woraus die beiden Verfahren ihr Vertrauen in das Zertifikat des Zielservers ableiten.
DANE in Kürze: Vertrauen über DNSSEC
DANE, kurz für DNS-based Authentication of Named Entities, hinterlegt einen sogenannten TLSA-Eintrag direkt im DNS der Domäne. Dieser Eintrag bindet das erwartete Zertifikat oder dessen Schlüssel fest an den Mailserver. Ein sendender Server prüft beim Aufbau der Verbindung, ob das vorgelegte Zertifikat zu diesem hinterlegten Wert passt.
Damit dieser DNS-Eintrag nicht selbst manipulierbar ist, setzt DANE zwingend DNSSEC voraus. DNSSEC signiert die DNS-Antworten kryptografisch, sodass ein Angreifer den TLSA-Eintrag nicht unbemerkt fälschen kann. Der Vertrauensanker von DANE liegt also vollständig im signierten DNS, unabhängig von öffentlichen Zertifizierungsstellen.
MTA-STS in Kürze: Vertrauen über CA und HTTPS
MTA-STS, kurz für Mail Transfer Agent Strict Transport Security, veröffentlicht eine Richtlinie, die empfangende Mailserver verpflichtet, E-Mails nur über eine geprüfte TLS-Verbindung anzunehmen. Ein DNS-TXT-Eintrag unter _mta-sts signalisiert, dass eine Richtlinie existiert. Die Richtlinie selbst liegt als Datei auf einer HTTPS-Subdomäne und nennt die zulässigen Mailserver, den Modus und die Gültigkeitsdauer.
Das Vertrauen von MTA-STS stützt sich auf zwei Säulen: Erstens auf die Vertrauenskette gängiger Zertifizierungsstellen, deren Zertifikate das vorgelegte Serverzertifikat als gültig ausweisen, und zweitens auf HTTPS, das den manipulationssicheren Abruf der Richtlinie absichert. DNSSEC wird dafür nicht benötigt. Damit ist MTA-STS auch für Domänen einsetzbar, deren Zone noch nicht mit DNSSEC abgesichert ist.
MTA-STS oder DANE: Der direkte Vergleich
Die folgende Gegenüberstellung fasst die entscheidenden Unterschiede zusammen.
| Kriterium | DANE | MTA-STS |
|---|
| Vertrauensanker | Signierter TLSA-Eintrag im DNS | Öffentliche Zertifizierungsstellen und HTTPS |
| DNSSEC-Voraussetzung | Zwingend erforderlich | Nicht erforderlich |
| Verhalten beim Erstkontakt | Sofort fälschungssicher prüfbar | Trust on First Use, Richtlinie wird zwischengespeichert |
| Betriebsaufwand | DNSSEC-Pflege und TLSA-Eintrag passend zum Zertifikat | HTTPS-Subdomäne mit dauerhaft gültigem Zertifikat |
| Verbreitung | Vor allem bei DNSSEC-Vorreitern und großen Providern | Breite Unterstützung, auch ohne DNSSEC |
Der TOFU-Unterschied im Detail
Der vielleicht wichtigste konzeptionelle Unterschied steckt im Verhalten beim Erstkontakt. MTA-STS arbeitet nach dem Prinzip Trust on First Use, kurz TOFU. Ein sendender Server vertraut der Richtlinie beim ersten erfolgreichen Abruf und speichert sie für die angegebene Gültigkeitsdauer zwischen. Innerhalb dieses Fensters greift der Schutz zuverlässig. Theoretisch verbleibt jedoch ein schmales Zeitfenster: Manipuliert ein Angreifer ausgerechnet den allerersten Kontakt, bevor eine Richtlinie zwischengespeichert wurde, lässt sich der Schutz umgehen.
DANE kennt dieses Fenster nicht. Da der TLSA-Eintrag über DNSSEC bereits ab dem ersten Kontakt fälschungssicher prüfbar ist, besteht keine Phase blinden Erstvertrauens. Dieser Unterschied ist in der Praxis selten relevant, erklärt aber, warum DANE in besonders schutzbedürftigen Umgebungen als das stärkere Verfahren gilt.
Entscheidungshilfe: Welcher Standard passt zu Ihrer Domäne?
Die Entscheidung lässt sich an einer einzigen Frage festmachen, nämlich ob Ihre Zone bereits mit DNSSEC abgesichert ist.
| Ausgangslage | Empfehlung |
|---|
| DNSSEC ist aktiv | Beide Verfahren parallel betreiben, MTA-STS und DANE |
| DNSSEC ist nicht aktiv | Mit MTA-STS beginnen, DANE später ergänzen |
| Höchste Sicherheitsanforderung | DANE als primärer Schutz, MTA-STS als Absicherung |
Ist DNSSEC vorhanden, gibt es keinen Grund, sich auf ein Verfahren zu beschränken. Der parallele Betrieb erreicht die größte Reichweite, weil ein sendender Server entweder den TLSA-Eintrag oder die MTA-STS-Richtlinie auswertet, je nachdem, welches Verfahren er unterstützt. Fehlt DNSSEC, ist DANE technisch ausgeschlossen, und MTA-STS ist der pragmatische und sofort umsetzbare Einstieg. Stellt eine Organisation höchste Anforderungen, etwa im regulierten Umfeld, dient DANE als primärer Schutz und MTA-STS fängt jene Gegenstellen ab, die DANE nicht unterstützen.
Warum das BSI beide Verfahren parallel empfiehlt
Die Empfehlung zum parallelen Einsatz kommt nicht von ungefähr. Die Technische Richtlinie TR-03108 des BSI nennt MTA-STS, DANE und TLS-RPT gemeinsam als Bausteine für einen sicheren E-Mail-Transport. Der Grund ist die unterschiedliche Reichweite: Nicht jeder sendende Mailserver weltweit unterstützt DANE, und nicht jede Domäne kann oder will DNSSEC betreiben. Wer beide Verfahren parallel veröffentlicht, deckt die Stärken des einen mit dem anderen ab und maximiert den Anteil zuverlässig verschlüsselter Zustellungen.
Ergänzend liefert TLS-RPT die nötige Sichtbarkeit. Über tägliche Berichte zeigt es, wie viele Verbindungen erfolgreich verschlüsselt wurden und woran fehlgeschlagene Zustellungen lagen. Erst diese Kombination aus zwei sich ergänzenden Erzwingungsverfahren und einem Berichtskanal macht den verbindlichen Transportschutz sicher beherrschbar und nachweisbar, etwa im Hinblick auf die NIS2-Richtlinie und den Stand der Technik nach Artikel 32 DSGVO.
Conbool MailGuard betreibt beide Verfahren, ein- und ausgehend
Der praktische Aufwand unterscheidet sich je nach Verfahren, ist aber in beiden Fällen real. DANE verlangt eine saubere DNSSEC-Pflege und einen TLSA-Eintrag, der bei jedem Zertifikatswechsel passend aktualisiert wird. MTA-STS verlangt eine HTTPS-Subdomäne mit dauerhaft gültigem Zertifikat, was Plattformen wie Exchange Online nicht selbst übernehmen.
Conbool MailGuard nimmt Ihnen beide Aufgaben ab. Ausgehend stellt der Dienst die MTA-STS-Richtlinie samt Subdomäne und automatisch gültigem Zertifikat bereit und verwaltet den passenden TLSA-Eintrag für DANE, sodass beide Verfahren parallel und korrekt veröffentlicht sind. Eingehend wertet das Gateway die Richtlinien und TLSA-Einträge Ihrer Kommunikationspartner aus und erzwingt die verschlüsselte Zustellung in beide Richtungen. Die zugehörigen TLS-Berichte laufen an einer Stelle zusammen. Die Details zu den verwalteten Lösungen finden Sie auf den Seiten zu MTA-STS und DANE und TLSA.
Wer den aktuellen Status einer Domäne zuerst prüfen möchte, kann das mit dem kostenlosen Transportsicherheits-Check tun.
Häufig gestellte Fragen
Worin besteht der Kernunterschied zwischen MTA-STS und DANE?
Beide Verfahren machen TLS für den E-Mail-Transport verbindlich, vertrauen dem Serverzertifikat aber auf unterschiedlichem Weg. DANE bindet das Zertifikat über einen signierten TLSA-Eintrag im DNS und stützt sich dabei auf DNSSEC als Vertrauensanker. MTA-STS verlässt sich auf die Vertrauenskette öffentlicher Zertifizierungsstellen sowie auf eine über HTTPS abgerufene Richtlinie. DANE verankert das Vertrauen also im signierten DNS, MTA-STS in der CA-Infrastruktur und im Web.
Kann ich MTA-STS und DANE gleichzeitig einsetzen?
Ja, und genau das ist die empfohlene Praxis. Die beiden Verfahren stehen nicht im Widerspruch, sondern ergänzen sich. Ein sendender Server, der DANE unterstützt, wertet den TLSA-Eintrag aus, ein Server ohne DANE folgt der MTA-STS-Richtlinie. So erreichen Sie die größte Reichweite an verschlüsselter Zustellung. Das BSI empfiehlt in der Technischen Richtlinie TR-03108 ausdrücklich den parallelen Einsatz beider Standards zusammen mit TLS-RPT.
Wofür sollte ich mich entscheiden, wenn meine Domäne kein DNSSEC nutzt?
Ohne DNSSEC ist DANE technisch nicht möglich, da der TLSA-Eintrag sonst nicht fälschungssicher abgesichert wäre. In diesem Fall ist MTA-STS die richtige Wahl, denn es kommt ohne DNSSEC aus und stützt sich auf öffentliche Zertifizierungsstellen und HTTPS. Sobald DNSSEC für die Zone aktiviert ist, lässt sich DANE jederzeit ergänzen, ohne MTA-STS abzuschalten.
Was bedeutet Trust on First Use bei MTA-STS?
Trust on First Use, kurz TOFU, beschreibt, dass ein sendender Server der MTA-STS-Richtlinie beim ersten erfolgreichen Abruf vertraut und sie für die angegebene Gültigkeitsdauer zwischenspeichert. Erst dieser Erstkontakt etabliert das Vertrauen. Manipuliert ein Angreifer die allererste Verbindung, bevor eine Richtlinie zwischengespeichert ist, kann der Schutz theoretisch umgangen werden. DANE kennt dieses Fenster nicht, weil der signierte DNS-Eintrag bereits ab dem ersten Kontakt fälschungssicher prüfbar ist.
Warum reicht klassisches STARTTLS allein für keinen der beiden Standards aus?
STARTTLS verschlüsselt nur opportunistisch und fällt bei einem Fehler still auf eine unverschlüsselte Zustellung zurück. Ein Angreifer kann das STARTTLS-Signal entfernen, ohne dass es auffällt. Sowohl MTA-STS als auch DANE setzen genau hier an: Sie machen die Verschlüsselung verbindlich und erzwingen die Prüfung von Hostname und Zertifikat, sodass eine fehlende oder ungültige TLS-Verbindung zum Abbruch der Zustellung führt statt zu einem stillen Downgrade.
Fazit
MTA-STS oder DANE ist keine Entweder-oder-Frage, sondern eine Frage der Reihenfolge. Beide Standards beenden die Freiwilligkeit von STARTTLS und machen aus optionaler Verschlüsselung eine verbindliche Vorgabe. DANE setzt sein Vertrauen ins signierte DNS und braucht dafür DNSSEC, MTA-STS stützt sich auf öffentliche Zertifizierungsstellen und HTTPS und vertraut der Richtlinie nach dem ersten Kontakt. Wer DNSSEC betreibt, sollte beide parallel veröffentlichen, wie es auch das BSI in der TR-03108 empfiehlt. Wer noch kein DNSSEC hat, startet mit MTA-STS und ergänzt DANE später.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie, wie Conbool MailGuard MTA-STS und DANE ein- und ausgehend für Sie betreibt.
Weiterführende Artikel:
