Kostenloses MTA-STS Hosting

Warum MTA-STS unverzichtbar ist

SMTP wurde 1982 ohne Verschlüsselung entwickelt. STARTTLS kam später hinzu, um E-Mails bei der Übertragung zu verschlüsseln. Es hat aber einen kritischen Schwachpunkt: Es ist opportunistisch. Ein sendender Server kündigt STARTTLS-Unterstützung an. Der empfangende Server kann diese akzeptieren oder ignorieren. Nichts erzwingt, dass die Verbindung verschlüsselt bleibt.

Das eröffnet ein Fenster für SMTP-Downgrade-Angriffe. Ein Angreifer positioniert sich zwischen zwei Mailservern, etwa über BGP-Hijacking, DNS-Spoofing oder Netzwerk-Interception. Er entfernt den STARTTLS-Befehl aus dem SMTP-Handshake. Der sendende Server erkennt keine Verschlüsselungsoption und fällt auf Klartext zurück. Die E-Mail wird unverschlüsselt übertragen, lesbar für jeden auf dem Übertragungsweg.

MTA-STS (RFC 8461) schließt diese Lücke. Es veröffentlicht eine Policy, die sendenden Servern mitteilt: "Diese Domain erfordert TLS. Wenn die Verschlüsselung fehlschlägt, nicht auf Klartext zurückfallen." Der sendende Server muss eine gültige TLS-Verbindung herstellen. Gelingt das nicht, wird die Nachricht zur erneuten Zustellung in die Warteschlange gestellt.

Die Hürde bei der Bereitstellung: MTA-STS erfordert das Hosting einer Policy-Datei unter https://mta-sts.captaindns.com/.well-known/mta-sts.txt über HTTPS mit einem gültigen Zertifikat. Für viele Organisationen ist ein dedizierter Webserver für eine einzelne Textdatei unverhältnismäßig aufwendig. CaptainDNS beseitigt diese Hürde vollständig.

Was ohne MTA-STS passiert

Ohne MTA-STS verlässt sich Ihr E-Mail-Transport ausschließlich auf opportunistisches TLS. Das bedeutet in der Praxis:

• Klartext-Abfangen: Jeder Angreifer auf Netzwerkebene kann Ihre E-Mails lesen, indem er STARTTLS entfernt. Das ist nicht theoretisch. Staatliche Überwachungsprogramme und Abfangmaßnahmen auf ISP-Ebene sind dokumentiert.
• Keine Absenderverifizierung: Ohne veröffentlichte Policy haben sendende Server keine Möglichkeit zu wissen, dass Ihre Domain TLS erfordert. Sie werden stillschweigend herunterstufen, wenn etwas schiefgeht.
• Compliance-Risiko: Vorschriften wie DSGVO, HIPAA und PCI-DSS verlangen die Verschlüsselung sensibler Daten bei der Übertragung. Opportunistisches TLS allein erfüllt diesen Standard nicht, da es umgangen werden kann.
• Unsichtbare Fehler: Ohne TLS-RPT (das begleitende Reporting-Protokoll) erfahren Sie nie, dass E-Mails an Ihre Domain unverschlüsselt zugestellt wurden. Das Problem bleibt unsichtbar.

Im Jahr 2014 dokumentierten Forscher großflächige STARTTLS-Unterdrückung durch Netzwerk-Intermediäre in mehreren Ländern. Googles Transparency Report bestätigte später, dass ein erheblicher Anteil eingehender E-Mails weiterhin unverschlüsselt ankommt. MTA-STS ist das Protokoll, das entwickelt wurde, um dies zu beenden.

MTA-STS in Kombination mit TLS-RPT bietet Ihnen sowohl Durchsetzung als auch Transparenz.

Wie MTA-STS im Detail funktioniert

MTA-STS verwendet zwei Komponenten, die zusammenwirken:

1. Ein DNS-TXT-Eintrag unter _mta-sts.captaindns.com

Dieser Eintrag macht Ihre MTA-STS-Policy bekannt und enthält eine eindeutige Policy-ID. Wenn sich die ID ändert, wissen sendende Server, dass sie eine neue Version der Policy abrufen müssen.

Beispiel: v=STSv1; id=20260308120000

2. Eine über HTTPS gehostete Policy-Datei unter https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Diese Datei definiert drei Dinge:

• mode: testing (nur Berichte) oder enforce (Ablehnung bei TLS-Fehler)
• mx: die Mailserver-Muster, die mit Ihren MX-Einträgen übereinstimmen müssen
• max_age: wie lange sendende Server die Policy cachen sollen (in Sekunden)

Beispiel:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Wenn ein sendender Server eine E-Mail an Ihre Domain zustellen möchte, prüft er den _mta-sts-TXT-Eintrag. Falls vorhanden, ruft er die Policy-Datei über HTTPS ab, validiert das TLS-Zertifikat Ihrer MX-Server anhand der Policy-Muster und fährt nur fort, wenn alles übereinstimmt.

Trust on first use (TOFU): MTA-STS setzt darauf, dass der erste erfolgreiche Policy-Abruf legitim ist. Danach schützt die gecachte Policy vor zukünftigen Angriffen für die Dauer von max_age. Deshalb wird im Enforce-Modus ein längerer max_age (7+ Tage) empfohlen.

So funktioniert es

1. Policy erstellen

Melden Sie sich an und erstellen Sie eine neue Policy. Legen Sie Domain, Modus (Testing oder Enforce), MX-Muster und Cache-Dauer (max_age) fest.

2. Domain-Inhaberschaft verifizieren

Fügen Sie den TXT-Verifizierungseintrag zu Ihrem DNS hinzu. Wir erkennen ihn automatisch innerhalb von Sekunden.

3. Deployment-DNS-Einträge hinzufügen

Zwei DNS-Einträge:

• CNAME: Verweist mta-sts.captaindns.com auf unseren Policy-Server
• TXT: Macht Ihre MTA-STS-Policy unter _mta-sts.captaindns.com bekannt

Ihre MTA-STS-Policy ist aktiv.

Kompatibel mit großen E-Mail-Anbietern

MTA-STS funktioniert mit jedem E-Mail-Anbieter, der Standard-MX-Einträge verwendet. Die MX-Muster in Ihrer Policy müssen mit den Mailservern Ihres Anbieters übereinstimmen:

Beim Erstellen Ihrer Policy auf CaptainDNS geben Sie die MX-Muster ein, die zu Ihrem Anbieter passen. Das Dashboard validiert sie anhand Ihrer aktiven MX-Einträge, um Abweichungen zu vermeiden.

Gehostet vs. selbst gehostet: Welche Option wählen?

Wählen Sie gehostet, wenn Sie MTA-STS in wenigen Minuten ohne Infrastruktur bereitstellen möchten. Wählen Sie selbst gehostet, wenn Sie volle Kontrolle über den Policy-Endpunkt benötigen oder in einer abgeschotteten Umgebung arbeiten.

Von Testing zu Enforce: eine schrittweise Strategie

MTA-STS sofort im Enforce-Modus bereitzustellen, ist riskant. Wenn Ihre MX-Muster falsch sind oder ein TLS-Zertifikat abläuft, werden legitime E-Mails abgelehnt. Der empfohlene Ansatz ist schrittweise:

Phase 1: Bereitstellung im Testing-Modus (1 bis 2 Wochen)

Setzen Sie mode: testing in Ihrer Policy. Sendende Server versuchen TLS und melden Fehler über TLS-RPT, stellen E-Mails aber weiterhin zu, auch wenn TLS fehlschlägt. So erhalten Sie Transparenz ohne Risiko.

Phase 2: TLS-RPT-Berichte analysieren

Überprüfen Sie die Berichte, um Probleme zu identifizieren: Zertifikatsabweichungen, MX-Muster, die nicht alle Mailserver abdecken, oder Drittanbieter-Sender mit fehlerhaftem TLS. Beheben Sie jedes Problem, bevor Sie fortfahren.

Phase 3: Auf Enforce-Modus umschalten

Sobald die Berichte mindestens eine Woche lang null Fehler zeigen, ändern Sie den Modus auf enforce und erhöhen Sie max_age auf 604800 (7 Tage) oder mehr. Bei CaptainDNS ist das ein einziger Klick im Dashboard. Die Policy-ID rotiert automatisch.

Notfall-Rollback: Falls der Enforce-Modus legitime E-Mails blockiert, wechseln Sie sofort zurück auf testing. Sendende Server rufen die aktualisierte Policy ab und stellen die Ablehnung innerhalb von Minuten ein (oder spätestens innerhalb des alten max_age-Fensters).

MTA-STS und DANE: zwei ergänzende Ansätze

Zwei Protokolle existieren, um die Verschlüsselung des E-Mail-Transports durchzusetzen: MTA-STS und DANE (DNS-based Authentication of Named Entities). Sie lösen dasselbe Problem auf unterschiedliche Weise.

Wenn Ihre Domain kein DNSSEC nutzt, ist MTA-STS Ihre einzige Option für erzwungene Transportverschlüsselung.

Wenn Ihre Domain DNSSEC nutzt, bietet die Bereitstellung beider Protokolle den stärksten Schutz: DANE eliminiert TOFU für DNSSEC-fähige Sender, während MTA-STS Sender abdeckt, die DANE nicht unterstützen.

Best Practices für die MTA-STS-Bereitstellung

1. Beginnen Sie im Testing-Modus: Identifizieren Sie TLS-Verbindungsprobleme, bevor Sie auf Enforce umschalten.
2. Richten Sie TLS-RPT ein: Erhalten Sie Berichte über TLS-Zustellfehler. Nutzen Sie unseren TLS-RPT Generator.
3. Validieren Sie Ihre MX-Einträge: Stellen Sie sicher, dass die MX-Muster in Ihrer Policy mit Ihren tatsächlichen Mailservern übereinstimmen. Abweichungen verursachen Zustellfehler im Enforce-Modus.
4. Überwachen Sie vor der Durchsetzung: Analysieren Sie TLS-RPT-Berichte mindestens eine Woche lang mit null Fehlern, bevor Sie auf Enforce umschalten.
5. Verwenden Sie einen langen max_age im Enforce-Modus: 604800 Sekunden (7 Tage) oder mehr. So stellen Sie sicher, dass sendende Server Ihre Policy lange genug cachen, um Downgrade-Angriffe abzuwehren.
6. Wechseln Sie zu Enforce: Sobald die TLS-RPT-Berichte bestätigen, dass alles funktioniert, aktivieren Sie den Enforce-Modus für vollständigen Schutz.

Ergänzende Tools

Anleitungen und Ressourcen

• MTA-STS: Die Komplettanleitung zur Absicherung Ihres E-Mail-Transports - Alles, was Sie über die Konfiguration und Bereitstellung von MTA-STS wissen müssen.
• Von testing zu enforce: schrittweise MTA-STS-Bereitstellungsstrategie - Best Practices für eine schrittweise MTA-STS-Einführung.
• MTA-STS für Microsoft 365 und Google Workspace einrichten - Schritt-für-Schritt-Anleitung für die beiden beliebtesten E-Mail-Plattformen.
• MTA-STS funktioniert nicht? Der komplette Fehlerbehebungs-Guide - Diagnostizieren und beheben Sie die häufigsten MTA-STS-Konfigurationsfehler.
• MTA-STS vs DANE: Welches Protokoll zur Absicherung des E-Mail-Transports wählen? - Detaillierter Vergleich, um das richtige Protokoll zu wählen.