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.

Ohne Rückkanal nicht scharf schalten

MTA-STS allein zeigt dir nicht, ob es funktioniert: Die Policy wirkt, indem sie Zustellungen verhindert, und davon erfährst du nichts. Den Rückkanal liefert TLS-RPT — er gehört eingerichtet, bevor du von testing auf enforce wechselst. Wie der Record aussieht und was in den Berichten steht, steht auf der TLS-RPT-Seite.

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.

Prüf deine eigene Konfiguration

Sende eine beliebige E-Mail an hello@analyzemy.email und du bekommst innerhalb von Sekunden einen vollständigen Report mit über 20 Checks zurück — inklusive dieser Prüfung.

Jetzt E-Mail analysieren

Zuletzt aktualisiert: · Alle Checks im Überblick