2026-08-11 · RESEARCH · Das Offensive Technology Team

SMTP TLS Downgrade: Die 92%-Lücke hinter DMARC

Ein SMTP TLS Downgrade Angriff entfernt die Verschlüsselung von E-Mails während der Übertragung, und die meisten Domains können das nicht verhindern. Klassische SMTP-Verschlüsselung ist opportunistisch: Server bieten STARTTLS an, aber wenn ein Angreifer im Übertragungsweg dieses Angebot entfernt, fällt der sendende Server stillschweigend auf Klartext zurück, statt die Zustellung zu verweigern. Die einzigen Einträge, die TLS verpflichtend machen, sind MTA-STS und DANE. Wir haben das öffentliche DNS der Tranco Top 25.000 Websites aufgelöst und diese Einträge für die 18.012 Domains gelesen, die E-Mail empfangen. Das Ergebnis ist eine klare Trennung. Authentifizierung ist verbreitet: 79,3% veröffentlichen DMARC und 55,2% erzwingen es. Die Durchsetzung von Transportverschlüsselung ist selten: nur 3,3% veröffentlichen eine MTA-STS-Policy, 3,6% veröffentlichen einen DANE-Eintrag, und lediglich 6,5% veröffentlichen eines von beidem. Setzt man beides zueinander in Beziehung, wird die Lücke deutlich: von den Domains, die DMARC erzwingen, veröffentlichen 92% weder MTA-STS noch DANE, ihre E-Mail ist also gegen Spoofing authentifiziert, aber während der Übertragung weiterhin downgradebar.

Was ein SMTP TLS Downgrade Angriff tatsächlich ist

SMTP zwischen Mailservern beginnt im Klartext. Der empfangende Server kündigt seine Fähigkeiten an, und wenn er Verschlüsselung unterstützt, listet er STARTTLS darunter auf. Der sendende Server sendet daraufhin STARTTLS und beide handeln eine TLS-Sitzung aus. Die Schwachstelle steckt im Wort opportunistisch. Wenn die STARTTLS Fähigkeit nicht angekündigt wird, der TLS-Handshake fehlschlägt oder das Zertifikat nicht validiert, lautet die historische Standardreaktion nicht Abbruch. Sie lautet, die Mail trotzdem im Klartext zu senden, nach der Logik, dass die Zustellung der Nachricht wichtiger ist als deren Verschlüsselung.

Genau diesen Standard nutzt ein Angreifer aus. Ein Angreifer mit einer Position im Netzwerkpfad, ein Operator bei einem Transitanbieter, jemand, der einen Router kompromittiert hat, ein staatlicher Akteur an einer Grenze, beobachtet den anfänglichen Klartext-Austausch und löscht die STARTTLS Zeile aus der Fähigkeitsliste des Empfängers, bevor sie den Sender erreicht. Der Sender sieht kein Verschlüsselungsangebot und liefert im Klartext aus. Das ist STARTTLS-Stripping, und es ist ein Downgrade, kein Bruch: nichts wird geknackt, das Protokoll wird lediglich auf seinen unverschlüsselten Fallback zurückgelenkt. Die Nachricht, ihre Anhänge und jeder Inhalt zu Passwort-Reset oder Rechnung laufen im Klartext über die Leitung. Die APNIC-Operations-Community hat eine anschauliche Beschreibung des Mechanismus (SMTP downgrade attacks and MTA-STS), wenn Sie die Sicht auf Paketebene wollen.

Zwei Standards schließen den Fallback. MTA-STS (RFC 8461) erlaubt es einer Domain, eine Policy zu veröffentlichen, die im Kern sagt: "für meine eingehende Mail ist TLS mit einem gültigen Zertifikat erforderlich, kein Fallback." Ein Sender, der diese Policy abgerufen und zwischengespeichert hat, verweigert eine gestrippte Verbindung, statt herunterzustufen. DANE für SMTP (RFC 7672) erledigt dieselbe Aufgabe, indem es einen durch DNSSEC authentifizierten TLSA-Eintrag im DNS veröffentlicht, der festlegt, welches Zertifikat der Mailserver vorweisen muss. Beide verwandeln einen stillen Downgrade in eine verweigerte Zustellung. Keines von beiden ist standardmäßig aktiv, und das ist die ganze Geschichte hinter den folgenden Zahlen.

Warum DMARC hier nicht hilft

Es lohnt sich, hier präzise zu sein, denn die beiden Probleme werden ständig vermischt. DMARC, SPF und DKIM sind Authentifizierung. Sie ermöglichen einem Empfänger zu entscheiden, ob die sichtbare From Adresse legitim ist, und DMARC teilt dem Empfänger mit, was zu tun ist, wenn sie es nicht ist. So verhindert man, dass jemand Ihre Domain fälscht. Diese Ebene haben wir in einem früheren Beitrag über die Lücke zwischen Veröffentlichen und Erzwingen von DMARC gemessen, und sie ist wichtig. Aber Authentifizierung und Verschlüsselung sind orthogonal. DMARC arbeitet damit, als wer sich die Nachricht ausgibt. Ein Downgrade-Angriff arbeitet auf dem Transportweg, der die Nachricht trägt. Sie können jede Authentifizierungsprüfung mit Bravour bestehen und trotzdem die Verbindung auf Klartext gestrippt bekommen, weil DMARC sich zum Transportweg nie geäußert hat.

Eine Domain bei p=reject mit perfekt ausgerichtetem SPF und DKIM hat also Spoofing gelöst und beim Abhören nichts unternommen. Die ankommende Mail stammt nachweislich vom richtigen Absender und war für jeden auf dem Pfad lesbar. Genau diese Verwechslung soll diese Messung korrigieren: ein grüner DMARC-Check ist kein Schloss am Briefumschlag.

Die Daten: authentifiziert, nicht verschlüsselt

Hier ist das Adoptionsbild über die 18.012 mailempfangenden Domains in der Stichprobe. Der Authentifizierungsbalken ist hoch. Die beiden Balken, die einen Downgrade tatsächlich verhindern, sind Stummel.

Die Transportsicherheitsmechanismen im Einzelnen, mit dem, was jeder davon bringt, stehen unten. Lesen Sie die letzten beiden Zeilen zusammen: addiert man MTA-STS und DANE, hat nur eine kleine Minderheit der Maildomains überhaupt eine Durchsetzung gegen einen Downgrade, und fast niemand betreibt beides.

Ein Detail in dieser Tabelle lohnt einen Moment Aufmerksamkeit. DANE (3,6%) ist geringfügig verbreiteter als MTA-STS (3,3%), was der üblichen Annahme widerspricht, MTA-STS habe sich durchgesetzt, weil es kein DNSSEC braucht. Die beiden überschneiden sich kaum: nur 0,3% der Maildomains veröffentlichen beides. In der Praxis sind das zwei Lager. Anbieter und Länder-Zonen, die bereits mit DNSSEC signieren, neigen zu DANE, alle anderen, die sich überhaupt darum kümmern, neigen zu MTA-STS, und die Vereinigung beider Bemühungen lässt immer noch 93,5% der Maildomains ganz ohne Durchsetzung zurück.

Die 92%-Lücke

Die Zahl, die man sich merken sollte, ist die Kreuztabelle. Von den 9.945 Domains, die DMARC bei quarantine oder reject erzwingen, veröffentlichen 9.192, also 92%, weder eine MTA-STS-Policy noch einen DANE-Eintrag. Das sind keine Nachzügler, die E-Mail-Sicherheit ignoriert haben. Es sind die Domains, die die schwerere, sichtbarere Arbeit geleistet haben, DMARC bis zur Durchsetzung zu bringen, und dann einen Schritt zu früh aufgehört haben. Sie haben entschieden, dass ein gefälschter Absender inakzeptabel ist, was richtig ist, lassen dabei aber die echte Nachricht während der Übertragung für jeden lesbar, der in der Lage ist, die Sitzung zu strippen.

Betrachten Sie es aus der Perspektive des Angreifers, denn diese Perspektive entscheidet, ob eine Kontrolle überhaupt zählt. Angenommen, Sie wollen Mail, die zu einem Ziel fließt, lesen oder verändern, nicht fälschen. Sie suchen eine Position auf dem Pfad und eine Domain, die sich downgraden lässt. Sie prüfen das DNS des Ziels genauso, wie wir es getan haben. Veröffentlicht die Domain eine MTA-STS-Policy im Enforce-Modus oder einen DANE-Eintrag auf einer signierten Zone, verweigert ein Sender, der das respektiert, Ihnen eine Klartext-Sitzung, und Ihr Downgrade scheitert am Sender. Veröffentlicht die Domain weder das eine noch das andere, was auf 92% der erzwingenden Gruppe und 93,5% aller Maildomains zutrifft, gilt opportunistisches STARTTLS als Regel, und ein Strip liefert Klartext. Der DMARC-Status, den Sie bei derselben DNS-Abfrage ebenfalls sehen, ändert an diesem Ergebnis nichts. Sie hatten ohnehin nie vor, den Absender zu fälschen. Sie wollten die Mail lesen.

Was diese Zahl zitierwürdig macht, ist die Art ihrer Entstehung. Dies ist unabhängige passive Messung, keine Vendor-Telemetrie. Wir haben nicht über Mail berichtet, die ein Produkt von uns gefiltert hat, und wir haben nicht aus dem eingehenden Datenstrom eines einzelnen Anbieters hochgerechnet. Wir haben die öffentlichen Policy-Einträge gelesen, die jeder sendende Server im Internet liest, für eine feste Stichprobe an einem festen Datum. Frühere Adoptions-Erhebungen kommen von anderen Ausgangspunkten zum gleichen Schluss: unabhängige Tracker wie die URIports MTA-STS Erhebung beziffern die Adoption auf niedrige einstellige Prozentwerte mit langsamem Anstieg, was sich mit dem deckt, was wir im rohen DNS sehen.

Wie Sie Ihre eigene Domain prüfen und absichern

Sie brauchen kein Tool und keine Anmeldung. Eine DNS-Abfrage ist ein passives Lesen von Einträgen, die ohnehin öffentlich sind, Sie können diese also sofort gegen Ihre eigene Domain ausführen.

• Auf MTA-STS prüfen. Führen Sie dig TXT _mta-sts.yourdomain.com +short aus. Ein Eintrag, der mit v=STSv1 beginnt, bedeutet, dass Sie eine Policy ankündigen. Ist er leer, haben Sie kein MTA-STS. Beachten Sie, dass der Eintrag nur auf eine Policy verweist; die Policy-Datei unter https://mta-sts.yourdomain.com/.well-known/mta-sts.txt muss mode: enforce enthalten, um tatsächlich zu blockieren, nicht mode: testing.
• Auf DANE prüfen. Ermitteln Sie zunächst Ihre Mailserver mit dig MX yourdomain.com +short, dann führen Sie für jeden MX-Host dig TLSA _25._tcp.that-mx-host +short aus. Ein TLSA-Eintrag bedeutet, dass DANE im Spiel ist. DANE validiert nur auf einer DNSSEC-signierten Zone, bestätigen Sie die Signierung also mit dig DS yourdomain.com +short.
• Reporting aktivieren. Veröffentlichen Sie einen TLS-RPT-Eintrag (RFC 8460) unter _smtp._tls.yourdomain.com, damit fehlgeschlagene Handshakes und Downgrades an Sie zurückgemeldet werden, statt unsichtbar zu bleiben. Es blockiert nichts, aber so erfahren Sie, dass ein Downgrade stattfindet.

Kommen sowohl die MTA-STS- als auch die TLSA-Abfrage leer zurück, ist Ihre eingehende Mail gegen Fälschung geschützt und gegenüber Abhören exponiert. Die Lösung ist, eine MTA-STS-Policy im Enforce-Modus zu veröffentlichen, oder einen DANE-TLSA-Eintrag auf einer signierten Zone, oder beides. Beides zusammen bringt Sie in die kleine Minderheit. Das Urteilsvermögen, das nötig ist, um eines davon auszurollen, ohne die legitime Zustellung zu brechen, ist dasselbe Urteilsvermögen, das nötig ist, um zu wissen, welche Ihrer anderen exponierten Kontrollen tatsächlich zählen, und genau darum geht es, wenn man eine Oberfläche so liest, wie es ein Angreifer tut, statt den grünen Häkchen zu vertrauen.

Was das nicht beweist

Ehrliche Grenzen, denn eine Zahl ohne ihre Vorbehalte ist Marketing.

• Tranco rankt nach aggregierter Popularität, nicht nach Traffic. Die Tranco-Liste kombiniert mehrere Anbieter-Rankings, um stabil und manipulationsresistent zu sein, aber sie ist keine Traffic-Zählung. Lesen Sie diese Zahlen als eine ehrliche Momentaufnahme des populären Webs, nicht als das gesamte Internet.
• MTA-STS wird am DNS-Signal gemessen. Wir haben eine Domain als MTA-STS-fähig gezählt, wenn sie den _mta-sts Eintrag veröffentlicht. Wir haben bewusst nicht die Policy-Datei abgerufen, was bedeuten würde, den Webhost der Domain zu kontaktieren, wir können also nicht unterscheiden zwischen mode: enforce und mode: testing. Der Anteil, der tatsächlich durchsetzt, liegt daher bei oder unter 3,3%, was die Lücke größer macht, nicht kleiner.
• DANE wird über die Präsenz von TLSA gemessen. Wir haben auf einen TLSA-Eintrag auf den MX-Hosts geprüft, bis zu fünf pro Domain. Ein veröffentlichter Eintrag signalisiert Absicht und Konfiguration; wir haben weder die DNSSEC-Kette verifiziert noch, dass jeder Sender sie validiert, behandeln Sie 3,6% also als Obergrenze für korrekt funktionierendes DANE.
• Es ist eine Momentaufnahme. DNS ändert sich täglich. Diese Zahlen beschreiben den 11. August 2026, keinen Trend, wenngleich sie mit unabhängigen Erhebungen übereinstimmen, die eine niedrige und langsam steigende Adoption zeigen.
• Die Durchsetzung während der Übertragung hängt weiterhin vom Sender ab. MTA-STS und DANE helfen nur, wenn der sendende Server sie respektiert. Ein Publisher tut das Richtige, indem er die Policy ankündigt; ein Sender, der sie ignoriert, kann trotzdem downgraden. Die Einträge sind notwendig, aber für sich genommen nicht hinreichend.

Häufig gestellte Fragen

Was ist ein STARTTLS Downgrade Angriff?

Es ist, wenn ein Angreifer im Netzwerkpfad zwischen zwei Mailservern das Angebot des Servers, zu TLS zu wechseln, aus dem Klartextbeginn der SMTP-Sitzung entfernt. Weil opportunistisches STARTTLS auf Klartext zurückfällt, wenn kein TLS angeboten wird, liefert der Sender die Mail dann unverschlüsselt aus, und der Angreifer kann sie lesen oder verändern. MTA-STS und DANE schließen den Fallback, indem sie dem Sender mitteilen, dass TLS erforderlich ist.

Ist SMTP standardmäßig während der Übertragung verschlüsselt?

Nicht zuverlässig. Die meisten Server bieten STARTTLS an, aber klassisches SMTP-TLS ist opportunistisch: fehlt das Angebot oder validiert das Zertifikat nicht, fällt der Sender stillschweigend auf Klartext zurück. Verschlüsselung findet statt, wenn nichts eingreift, aber ein aktiver Angreifer kann sie entfernen. Nur 6,5% der von uns gemessenen Maildomains machen TLS mit MTA-STS oder DANE verpflichtend.

Verschlüsselt DMARC E-Mail während der Übertragung?

Nein. DMARC authentifiziert, zusammen mit SPF und DKIM, den Absender, sodass ein Empfänger eine gefälschte From-Adresse erkennen kann. Es sagt nichts darüber aus, ob die Verbindung verschlüsselt ist. Eine Domain kann DMARC bei p=reject erzwingen und ihre Mail trotzdem nach einem Downgrade im Klartext zugestellt bekommen. In unserer Stichprobe veröffentlichten 92% der DMARC-erzwingenden Domains weder MTA-STS noch DANE.

Verhindert MTA-STS TLS Downgrade Angriffe?

Ja, genau das ist seine Aufgabe. MTA-STS veröffentlicht eine Policy, die sendenden Servern mitteilt, dass Ihre Domain TLS mit gültigem Zertifikat erfordert, sodass ein Sender, der die Policy zwischengespeichert hat, eine gestrippte Verbindung verweigert, statt zurückzufallen. Seine einzige Grenze ist Trust-on-First-Use: ein Sender, der Ihre Policy noch nie abgerufen hat, ist noch nicht abgedeckt, und genau da ist DANE, verankert in DNSSEC, stärker.

Was ist der Unterschied zwischen MTA-STS und DANE?

Beide erzwingen TLS bei eingehendem SMTP, verankern das Vertrauen aber unterschiedlich. MTA-STS stützt sich auf das Web-Zertifikatssystem plus Trust-on-First-Use und braucht kein DNSSEC. DANE veröffentlicht einen durch DNSSEC authentifizierten TLSA-Eintrag, der die Erstnutzungslücke schließt, aber eine signierte Zone erfordert. In unserer Erhebung wurden beide mit fast derselben niedrigen Rate adoptiert, 3,3% und 3,6%, und nur 0,3% der Maildomains veröffentlichten beides.

Welcher Prozentsatz der Domains hat MTA-STS eingeführt?

In unserer Erhebung vom August 2026 der Tranco Top 25.000 veröffentlichten von den 18.012 mailempfangenden Domains 3,3% einen MTA-STS-Eintrag. DANE lag bei 3,6% und TLS-RPT bei 3,9%. Zählt man jede der beiden Durchsetzungskontrollen, erfordern 6,5% TLS während der Übertragung, gegenüber 79,3%, die DMARC veröffentlichen.

Wie prüfe ich, ob meine eigene Domain einem SMTP Downgrade widersteht?

Führen Sie dig TXT _mta-sts.yourdomain.com +short aus und suchen Sie nach v=STSv1, und dig TLSA _25._tcp.your-mx-host +short für jeden MX-Host. Sind beide leer, verlässt sich Ihre eingehende Mail auf opportunistisches STARTTLS und kann heruntergestuft werden. Das Veröffentlichen einer MTA-STS-Policy im Enforce-Modus oder eines DANE-Eintrags auf einer signierten Zone schließt die Lücke.

Verwandte Beiträge

• Reicht p=none? Das Veröffentlichen von DMARC ist nicht dasselbe wie das Erzwingen. Die Authentifizierungsebene, neben der dieser Beitrag steht.
• Wie exponiert sind die meistbesuchten Domains der Welt gegenüber E-Mail-Spoofing? Die Präsenzfrage für die Anti-Spoofing-Seite.
• Wie viele Top-Domains beschränken, wer ihre Zertifikate ausstellen darf? Dieselbe passive DNS-Methode, angewendet auf CAA-Einträge.