MTA-STS Check — TLS erzwingen statt nur anbieten

Das Problem, das MTA-STS löst

STARTTLS ist optional und wird im Klartext ausgehandelt. Ein Angreifer in der Position eines Man-in-the-Middle kann die STARTTLS-Ankündigung schlicht aus dem SMTP-Dialog streichen. Der sendende Server sieht dann einen Empfänger, der angeblich kein TLS kann, und liefert die Nachricht unverschlüsselt aus — ohne Fehlermeldung, ohne dass jemand etwas bemerkt. Dieser Downgrade-Angriff ist der zentrale Schwachpunkt der E-Mail-Transportverschlüsselung.

MTA-STS (RFC 8461) schließt die Lücke. Du veröffentlichst eine Policy, die besagt: Für meine Domain ist TLS Pflicht, und meine MX-Hosts heißen so und so. Sendende Server holen diese Policy per HTTPS ab, cachen sie und verweigern die Zustellung, wenn TLS fehlt oder das Zertifikat nicht passt. Da die Policy über HTTPS mit gültigem Zertifikat ausgeliefert wird, kann ein Angreifer sie nicht fälschen.

Was AnalyzeMy.Email prüft

• DNS-Record unter _mta-sts.deinedomain.de mit gültigem v=STSv1 und einer id=
• Policy-Datei unter https://mta-sts.deinedomain.de/.well-known/mta-sts.txt — sie wird tatsächlich abgerufen
• Modus: enforce, testing oder none
• MX-Muster in der Policy und deren max_age
• TLS-RPT-Record unter _smtp._tls.deinedomain.de

Die drei Modi

• none — Die Policy ist bewusst deaktiviert. Wird verwendet, um eine zuvor veröffentlichte Policy sauber zurückzuziehen.
• testing — Verstöße werden nicht durchgesetzt, aber über TLS-RPT gemeldet. Der richtige Einstieg.
• enforce — TLS und passender Hostname sind Pflicht. Schlägt die Prüfung fehl, wird nicht zugestellt. Das ist das Ziel.

TLS-RPT — die Rückmeldung

MTA-STS allein zeigt dir nicht, ob es funktioniert. TLS-RPT (RFC 8460) ergänzt einen DNS-Record, über den sendende Server dir täglich Berichte über erfolgreiche und fehlgeschlagene TLS-Verbindungen schicken. Ohne TLS-RPT stellst du eine enforce-Policy blind scharf und erfährst von Zustellproblemen erst, wenn sich jemand beschwert. Beides gehört zusammen eingerichtet.

Typische Stolpersteine

• Policy-Datei nicht erreichbar: Die Subdomain mta-sts. braucht ein eigenes gültiges HTTPS-Zertifikat. Ein Zertifikatsfehler macht die gesamte Policy unwirksam.
• id nicht aktualisiert: Nach jeder Änderung an der Policy muss die id= im DNS-Record neu gesetzt werden, sonst arbeiten sendende Server weiter mit der gecachten Fassung.
• MX-Liste unvollständig: Jeder MX-Host muss in der Policy stehen. Ein vergessener Backup-MX führt bei enforce zu abgelehnten Nachrichten.
• Zu früh auf enforce: Erst testing fahren und die TLS-RPT-Berichte auswerten.