Hosted MTA-STS und TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) ist ein Sicherheitsstandard, der es Mail-Service-Anbietern ermöglicht, ihre Fähigkeit zum Empfang TLS-gesicherter Verbindungen zu deklarieren und Anforderungen an die SMTP-Zertifikatsvalidierung festzulegen. Im Gegensatz zum "opportunistischen TLS" bei Standard-E-Mail (das stillschweigend auf Klartext zurückfällt, wenn die Verschlüsselung fehlschlägt) erfordert MTA-STS PKIX-authentifizierte TLS-Verschlüsselung mit gültigen Zertifikaten oder blockiert die Zustellung vollständig.

Es verhindert Man-in-the-Middle-Angriffe, Downgrade-Angriffe (bei denen Angreifer STARTTLS-Befehle entfernen), Zertifikatsvalidierungs-Umgehungen und nicht autorisierte MX-Server-Angriffe. Ohne MTA-STS können Angreifer E-Mails abfangen, lesen oder verändern und dabei potenziell sensible Informationen offenlegen.

Bei selbst gehostetem MTA-STS müssen Sie einen Webserver einrichten und warten, um die Policy-Datei zu hosten, DNS-Einträge manuell konfigurieren und Policies selbst aktualisieren. Hosted MTA-STS erledigt all das automatisch — wir hosten die Policy-Datei, verwalten DNS-Einträge und aktualisieren Policies bei Änderungen. Sie erhalten die gleichen Sicherheitsvorteile ohne die technische Komplexität.

Nein, bei korrekter Konfiguration nicht. MTA-STS beeinflusst nur, wie sendende E-Mail-Server sich mit den MX-Servern Ihrer Domain verbinden, indem es STARTTLS mit PKIX-authentifizierter Verschlüsselung und gültigen Zertifikaten erfordert. Solange Ihre MX-Server STARTTLS mit gültigen X.509-Zertifikaten unterstützen (was alle modernen Mailserver tun), funktioniert MTA-STS nahtlos.

Sie sollten mit dem "Testing"-Modus beginnen, um alles zu überprüfen und TLS-RPT-Berichte auf Probleme zu prüfen, bevor Sie zum "Enforce"-Modus wechseln. Im Testing-Modus werden E-Mails normal zugestellt, auch wenn die TLS-Validierung fehlschlägt, sodass kein Risiko besteht, legitime E-Mails zu blockieren, während Sie Ihr Setup überprüfen.

Die Einrichtung dauert typischerweise nur wenige Minuten. Nach der Verifizierung Ihres Domain-Besitzes fügen Sie die von uns bereitgestellten DNS-Einträge hinzu (oder nutzen unser automatisches Setup). Sobald das DNS propagiert ist (normalerweise innerhalb von Minuten), wählen Sie Ihre E-Mail-Server aus und veröffentlichen Ihre Policy. Der gesamte Prozess kann in unter 10 Minuten abgeschlossen werden.

Nein. Mit Hosted MTA-STS und TLS-RPT aktualisieren wir die Policy-Datei (unter https://mta-sts.yourdomain.com/.well-known/mta-sts.txt) und die TLS-RPT-Konfiguration automatisch bei Änderungen. Sie können MX-Server hinzufügen oder entfernen, Policy-Modi ändern oder max_age-Einstellungen anpassen — wir kümmern uns um die Veröffentlichung des aktualisierten Policy-Inhalts, die Erhöhung der Policy-Versions-ID im DNS-TXT-Eintrag und die Verwaltung der TLS-Reporting-Endpunkte.

Es ist keine manuelle Dateiverwaltung oder Serverkonfiguration erforderlich. Sendende Server erkennen Policy-Updates, indem sie das "id"-Feld im DNS-TXT-Eintrag mit ihrer zwischengespeicherten Policy-Version vergleichen, was sie veranlasst, den aktualisierten Policy-Inhalt abzurufen. SMTP-TLS-Berichte werden automatisch an unsere Server geliefert und für Ihre Überprüfung verarbeitet.

MTA-STS verwendet einen zweistufigen Erkennungsprozess, der DNS und HTTPS kombiniert:

1. DNS-TXT-Eintrag-Abfrage: Sendende Server prüfen zunächst einen TXT-Eintrag bei _mta-sts.yourdomain.com mit dem Versionsfeld "v=STSv1" und einem eindeutigen "id"-Feld zur Verfolgung der Policy-Version
2. HTTPS-Policy-Datei-Abruf: Wenn der DNS-Eintrag existiert und die "id" sich von einer zwischengespeicherten Policy unterscheidet, rufen Server die eigentliche Policy-Datei über HTTPS von https://mta-sts.yourdomain.com/.well-known/mta-sts.txt ab

Die HTTPS-Verbindung muss ein gültiges Zertifikat einer vertrauenswürdigen CA für mta-sts.yourdomain.com verwenden, um sicherzustellen, dass die Policy authentisch und unverändert ist. Die Policy-Datei selbst enthält den Modus (enforce/testing/none), die max_age-Cache-Dauer und MX-Hostnamen-Muster, die angeben, welche Mailserver autorisiert sind. Mit Hosted MTA-STS und TLS-RPT übernehmen wir die DNS-TXT-Eintrag-Verwaltung, das sichere Hosting der Policy-Datei und den Empfang von SMTP-TLS-Berichten von sendenden Mailservern.

MTA-STS ist mit robusten Fehlermodi konzipiert, um Sicherheit und Verfügbarkeit auszubalancieren:

• Zwischengespeicherte Policy verfügbar (fail-closed): Wenn ein sendender Server eine zwischengespeicherte Policy hat, die nicht abgelaufen ist (basierend auf max_age), verwendet er diese weiterhin, auch wenn der HTTPS-Abruf fehlschlägt. Dies schützt Sie, auch wenn ein Angreifer die Policy-Erkennung vorübergehend blockiert.
• Keine zwischengespeicherte Policy (fail-open): Wenn keine zwischengespeicherte Policy vorhanden ist und der HTTPS-Abruf fehlschlägt, stellt der Absender E-Mails mit Standard-opportunistischem TLS zu. Dies verhindert, dass E-Mails auf unbestimmte Zeit blockiert werden, wenn Ihr Policy-Server während der erstmaligen Erkennung vorübergehend nicht verfügbar ist.
• Abgelaufene zwischengespeicherte Policy: Wenn die max_age einer zwischengespeicherten Policy abläuft und nicht über HTTPS aktualisiert werden kann, sollten Absender eine Aktualisierung versuchen, können aber je nach Implementierung die abgelaufene Policy weiter verwenden oder auf opportunistische Zustellung zurückfallen.

Der RFC empfiehlt geeignete max_age-Werte (bis zu 31.557.600 Sekunden für ein Jahr) und schlägt vor, dass Absender Policies proaktiv vor Ablauf aktualisieren. Mit Hosted MTA-STS und TLS-RPT gewährleisten wir hohe Verfügbarkeit Ihres Policy-Endpunkts, um den Schutz vor Cache-basierten Angriffen zu maximieren, und empfangen SMTP-TLS-Berichte, um Sie über Policy-Abruffehler oder Zustellprobleme zu informieren.