> ## Content Index > Fetch the complete content index at: https://blog.lange-it.com/llms.txt > Use this file to discover other available public pages before exploring further. # DANE, MTA-STS und TLS: Was bei sicherer Mailzustellung wirklich passiert - URL: https://blog.lange-it.com/dane-mta-sts-tls-sichere-mailzustellung/ - Published: 2026-10-05T15:31:19.000Z - Updated: 2026-10-05T15:31:19.000Z - Description: DANE, MTA-STS und opportunistisches TLS greifen an unterschiedlichen Stellen. Wie ich sichere ausgehende Mailzustellung als gestuftes Modell betrachte. - Author: Peter Lange - Tags: Mail, DANE, MTA-STS, TLS, DNSSEC, Postfix, TLS-RPT Wenn ich eine E-Mail verschicke, wirkt der Vorgang zunächst ziemlich eindeutig: Mein Mailserver ermittelt den zuständigen Mailserver der Empfängerdomain, baut eine SMTP-Verbindung auf und überträgt die Nachricht. Interessant wird es bei der Frage, wie sicher diese Verbindung tatsächlich ist. STARTTLS und eine erfolgreiche TLS-Verbindung sind heute zwar alltäglich. Trotzdem bedeutet das noch nicht automatisch, dass ein sendender Mailserver eine verschlüsselte Verbindung erzwingen oder die Identität der Gegenstelle zuverlässig überprüfen kann. Als ich mich intensiver mit der Absicherung ausgehender Mailzustellung beschäftigt habe, wurde deshalb eine andere Frage für mich wichtiger als die eigentliche Postfix-Konfiguration: **Welche Sicherheitsrichtlinie soll ein sendender Mailserver anwenden, wenn die Gegenstelle DANE unterstützt, MTA-STS anbietet oder überhaupt keine verbindliche TLS-Policy veröffentlicht?** Genau an dieser Stelle treffen DANE, MTA-STS und das klassische opportunistische TLS aufeinander. ## Warum STARTTLS allein nicht das ganze Problem löst SMTP wurde ursprünglich nicht mit verpflichtender Transportverschlüsselung entwickelt. STARTTLS erweitert eine zunächst unverschlüsselte SMTP-Verbindung um die Möglichkeit, auf TLS umzuschalten. Vereinfacht sieht das so aus: ![STARTTLS-Ablauf zwischen Sender-MTA und Empfänger-MTA](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-starttls-flow.png) Das ist bereits deutlich besser als eine unverschlüsselte Übertragung. Das Problem liegt im Wort „angeboten“. Bei klassischem opportunistischem TLS versucht der Sender TLS zu verwenden, wenn die Gegenstelle STARTTLS unterstützt. Kann TLS jedoch nicht verwendet werden, kann eine Zustellung – abhängig von der Konfiguration – trotzdem ohne TLS stattfinden. Genau dadurch entsteht eine Angriffsfläche. Ein aktiver Angreifer zwischen den beiden Mailservern könnte beispielsweise versuchen, das STARTTLS-Angebot zu unterdrücken. Der sendende Mailserver könnte dann zu dem Schluss kommen, dass die Gegenstelle TLS schlicht nicht unterstützt. Eine verschlüsselte Verbindung ist deshalb nicht dasselbe wie eine gegen Downgrade geschützte Transportpolicy. Hier kommen DANE und MTA-STS ins Spiel. ## DANE: TLS-Sicherheit über DNSSEC und TLSA DANE verfolgt einen Ansatz, den ich technisch besonders interessant finde: Die Information darüber, wie eine TLS-Verbindung abgesichert werden soll, wird mit DNSSEC abgesichert im DNS veröffentlicht. Für SMTP geschieht das über TLSA-Datensätze. Ein stark vereinfachtes Beispiel könnte so aussehen: ```text _25._tcp.mx1.example.com. IN TLSA 3 1 1 ``` Der sendende Mailserver fragt zunächst die für die Empfängerdomain zuständigen MX-Systeme ab und kann anschließend nach den zugehörigen TLSA-Datensätzen suchen. Entscheidend ist dabei DNSSEC. Ein TLSA-Datensatz allein macht DANE noch nicht vertrauenswürdig. Der Sender muss die DNSSEC-Validierung erfolgreich durchführen können. Vereinfacht ergibt sich: Der Entscheidungsweg lässt sich kompakt so beschreiben: ![DANE-Auflösung von der Empfängerdomain bis zur DNSSEC-Validierung](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-dane-resolution-flow.png) Ist die DNSSEC-Validierung erfolgreich, kann die DANE-Policy angewendet werden. Schlägt sie fehl, steht für diesen Pfad kein nutzbares DANE zur Verfügung. Ist eine verwendbare DANE-Policy vorhanden, kann der Sender nicht mehr einfach auf eine ungeschützte SMTP-Verbindung zurückfallen, nur weil STARTTLS plötzlich nicht angeboten wird. Das ist ein wesentlicher Unterschied zum klassischen opportunistischen TLS. ## Warum DNSSEC bei DANE so wichtig ist DANE verschiebt einen Teil der Vertrauensentscheidung in das DNS. Das funktioniert nur, wenn der Sender sicher feststellen kann, dass die erhaltenen DNS-Informationen authentisch sind. Ohne DNSSEC könnte ein Angreifer nicht nur die SMTP-Verbindung beeinflussen, sondern theoretisch bereits die DNS-Antwort manipulieren und einen anderen MX-Server präsentieren. Deshalb gehören für mich bei SMTP-DANE drei Dinge unmittelbar zusammen: ![DANE-Vertrauenskette von DNSSEC bis zur authentisierten TLS-Verbindung](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-dane-trust-flow.png) Wer DANE betrachtet, ohne DNSSEC mitzudenken, betrachtet nur einen Teil des Mechanismus. ## MTA-STS verfolgt einen anderen Ansatz MTA-STS – Mail Transfer Agent Strict Transport Security – löst das Problem anders. Eine Domain kann damit veröffentlichen, dass ihre Mailserver TLS unterstützen und welche MX-Systeme für eine sichere Zustellung akzeptiert werden sollen. Dazu existieren zwei wesentliche Bestandteile. Im DNS befindet sich zunächst ein TXT-Record, beispielsweise: ```text _mta-sts.example.com. IN TXT "v=STSv1; id=2026100501" ``` Die eigentliche Policy wird anschließend per HTTPS abgerufen: ```text https://mta-sts.example.com/.well-known/mta-sts.txt ``` Eine Policy könnte beispielsweise so aussehen: ```text version: STSv1 mode: enforce mx: mx1.example.com mx: mx2.example.com max_age: 86400 ``` Der interessante Teil ist `mode: enforce`. Besitzt der Sender eine gültige MTA-STS-Policy im Enforce-Modus, darf er eine Nachricht nicht einfach zustellen, wenn beispielsweise STARTTLS fehlt, die Zertifikatsprüfung scheitert oder der angesprochene MX nicht zur Policy passt. Damit verhindert MTA-STS ebenfalls, dass ein Fehler bei der TLS-Aushandlung einfach zu einer unsicheren Zustellung führt. ## DANE und MTA-STS sind keine Konkurrenten Anfangs könnte man leicht zu dem Schluss kommen, man müsse sich zwischen DANE und MTA-STS entscheiden. So betrachte ich die beiden Verfahren inzwischen nicht mehr. Sie lösen ein ähnliches Problem mit unterschiedlichen Vertrauensmodellen. DANE stützt sich auf DNSSEC und TLSA. MTA-STS verwendet eine per HTTPS gelieferte Policy und das klassische Web-PKI-Modell für die Zertifikatsprüfung. Gerade beim ausgehenden Mailtransport fand ich deshalb eine gestufte Betrachtung sinnvoll. Das Modell, das sich in meiner Praxis bewährt hat, sieht vereinfacht so aus: Für die Entscheidung ergibt sich damit ein gestuftes Modell: ![Gestuftes Architekturmodell für DANE, MTA-STS und opportunistisches TLS](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-policyentscheidung-flow.png) 1. **DNS- und MX-Auflösung durchführen.** 2. **Nutzbares DANE vorhanden?** Dann DANE anwenden. 3. **Kein nutzbares DANE:** Ist eine MTA-STS-Policy vorhanden, wird sie berücksichtigt. 4. **Weder DANE noch MTA-STS:** Die Zustellung fällt auf opportunistisches TLS zurück. Wichtig ist mir an dieser Stelle eine Unterscheidung: **Diese Darstellung ist ein Architekturmodell für die Entscheidungslogik eines sendenden Mailservers. Sie ist keine Behauptung, dass jeder Mailserver im Internet exakt diese Implementierungslogik verwenden muss.** Für meinen Anwendungsfall war genau diese Abstufung sinnvoll: vorhandenes DANE nutzen, ansonsten eine verfügbare MTA-STS-Policy berücksichtigen und Domains ohne beide Verfahren weiterhin per normaler SMTP-Zustellung erreichen. ## Warum der Fallback wichtig bleibt Es wäre verlockend, nach der Beschäftigung mit DANE und MTA-STS nur noch Verbindungen zu akzeptieren, die eines der beiden Verfahren absichern. Für einen allgemein verwendbaren Mailserver wäre das allerdings problematisch. Nicht jede Empfängerdomain veröffentlicht TLSA-Datensätze. Nicht jede Domain stellt eine MTA-STS-Policy bereit. Ein Mailserver muss deshalb unterscheiden können zwischen: **Policy vorhanden und verletzt** und: **keine zusätzliche Policy vorhanden** Das ist ein entscheidender Unterschied. Fehlt sowohl DANE als auch MTA-STS, kann opportunistisches TLS weiterhin die sinnvollste verfügbare Transportmethode sein. Das bedeutet nicht, dass diese Verbindung dieselben Sicherheitsgarantien bietet. Es bedeutet lediglich, dass fehlende zusätzliche Sicherheitsmechanismen nicht automatisch die weltweite Zustellbarkeit von E-Mails verhindern. ## Wie ich das mit Postfix betrachte Postfix bringt Unterstützung für DANE mit. Ein wichtiger Parameter ist dabei beispielsweise: ```text smtp_tls_security_level = dane ``` Für DANE muss außerdem eine DNSSEC-fähige DNS-Auflösung vorhanden sein. Je nach Architektur kann die Behandlung zusätzlicher TLS-Policies wie MTA-STS über einen externen Policy-Dienst erfolgen. Ich würde dabei allerdings davon abraten, einzelne Konfigurationszeilen aus einem fremden Setup zu übernehmen und davon auszugehen, dass dadurch automatisch dieselbe Sicherheitsarchitektur entsteht. Entscheidend ist das Zusammenspiel: Für die Fehlersuche betrachte ich deshalb mehrere getrennte Ebenen: ![Getrennte Ebenen für die Fehlersuche beim Mailtransport](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-diagnose-flow.png) . Gerade DNS-Auflösung, Policy-Entscheidung und tatsächliche SMTP-Verbindung sollten bei der Fehlersuche getrennt betrachtet werden. Diese Trennung hat sich für mich als wesentlich hilfreicher erwiesen als die pauschale Frage: „Warum funktioniert TLS nicht?“ ## Drei Fälle, die ich immer getrennt testen würde Nach einer solchen Konfiguration würde ich mich nicht damit zufriedengeben, dass eine einzelne Testmail angekommen ist. Ich möchte mindestens drei unterschiedliche Zieltypen überprüfen. ### 1\. Ziel mit DANE Hier sollte nachvollziehbar sein, dass gültige DNSSEC- und TLSA-Informationen gefunden und für die TLS-Verbindung verwendet werden. ### 2\. Ziel ohne DANE, aber mit MTA-STS Hier möchte ich sehen, dass tatsächlich die MTA-STS-Policy erkannt und angewendet wird. Besonders interessant ist eine Policy mit: ```text mode: enforce ``` Denn erst dann lässt sich sinnvoll prüfen, ob ein Policy-Verstoß tatsächlich eine unsichere Zustellung verhindert. ### 3\. Ziel ohne DANE und ohne MTA-STS Auch dieser Fall gehört zum Test. Die Nachricht sollte nicht allein deshalb unzustellbar werden, weil die Empfängerdomain keine der beiden zusätzlichen Policies veröffentlicht. Genau dieser dritte Test wird leicht vergessen. Für mich ist er aber genauso wichtig wie die beiden ersten, weil Sicherheit bei einem Mailserver nicht dadurch gewonnen wird, dass man unbeabsichtigt die Interoperabilität zerstört. ## TLS-RPT: Konfiguration allein reicht mir nicht Mit DANE und MTA-STS kann ich festlegen beziehungsweise auswerten, wie TLS-Verbindungen abgesichert werden sollen. Damit bleibt aber noch eine wichtige Frage: **Wie erfahre ich, wenn dabei etwas schiefläuft?** Hier kommt SMTP TLS Reporting, kurz TLS-RPT, ins Spiel. Eine Domain kann beispielsweise über einen DNS-TXT-Record angeben, wohin TLS-Berichte gesendet werden sollen: ```text _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ``` TLS-RPT kann Informationen über erfolgreiche und fehlgeschlagene TLS-Verbindungen beziehungsweise Policy-Anwendungen liefern. Das finde ich konzeptionell besonders wichtig. Eine Sicherheitsrichtlinie, deren Fehler ich im laufenden Betrieb nicht erkennen kann, ist für mich nur die halbe Lösung. TLS-RPT ersetzt dabei weder DANE noch MTA-STS. Es ergänzt die Transportabsicherung um eine Beobachtungsebene. Vereinfacht: ![Zusammenspiel von Transport-Policy, SMTP-TLS und TLS-RPT](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-tlsrpt-flow.png) Damit lassen sich Fehlkonfigurationen wesentlich besser von normalen Zustellproblemen unterscheiden. ## Transportverschlüsselung und Spamfilter sind zwei verschiedene Dinge Eine Erfahrung halte ich in diesem Zusammenhang ebenfalls für wichtig: Eine technisch einwandfreie TLS-Verbindung sagt nichts darüber aus, ob die Nachricht anschließend im Posteingang oder im Spam-Ordner landet. Das sind unterschiedliche Ebenen. Für die Transportebene interessieren mich unter anderem: - DNS und DNSSEC - DANE und TLSA - MTA-STS - STARTTLS - Zertifikatsprüfung Für die spätere Bewertung einer Nachricht spielen dagegen zusätzlich ganz andere Faktoren eine Rolle, beispielsweise: - SPF, DKIM und DMARC - IP- und Domain-Reputation - Nachrichteninhalt - Empfängerregeln - Providerbewertung Wenn eine Nachricht technisch erfolgreich und per TLS übertragen wurde, anschließend aber im Junk-Ordner landet, würde ich deshalb nicht als Erstes meine TLS-Policy zurückbauen. Ich würde zunächst herausfinden, auf welcher Ebene das Problem tatsächlich entstanden ist. ## Mein Fazit Die wichtigste Erkenntnis aus meiner Beschäftigung mit sicherer SMTP-Zustellung war für mich nicht ein bestimmter Postfix-Parameter. Es war die Erkenntnis, dass „TLS funktioniert“ als Beschreibung eigentlich zu ungenau ist. Ich möchte wissen: - Warum wurde TLS verwendet? - Welche Policy galt für das Ziel? - Wie wurde die Gegenstelle authentisiert? - Was passiert bei einem Policy-Verstoß? - Was passiert, wenn überhaupt keine zusätzliche Policy existiert? - Und wie erfahre ich von Fehlern? DANE beantwortet einen Teil dieser Fragen über DNSSEC und TLSA. MTA-STS bietet einen anderen Weg, eine verbindlichere TLS-Policy für SMTP zu veröffentlichen und durchzusetzen. Opportunistisches TLS bleibt der wichtige Fallback für Ziele ohne zusätzliche Policy. Und TLS-RPT hilft dabei, aus einer einmal eingerichteten Sicherheitskonfiguration etwas zu machen, das sich auch im laufenden Betrieb beobachten lässt. Für mich ergibt sich daraus weniger ein einzelnes Feature als vielmehr eine Kette: ![Methodik für eine bewusst aufgebaute Transport-Sicherheitsarchitektur](https://blog.lange-it.com/content/images/2026/10/lange-it-blog-mail-methodik-flow.png) Genau diese Kette ist für mich der entscheidende Unterschied zwischen „TLS eingeschaltet“ und einer bewusst aufgebauten Transport-Sicherheitsarchitektur.