So funktioniert’s
Zwischen Mailservern ist Verschlüsselung per STARTTLS von Haus aus freiwillig: Klappt TLS nicht, stellt der sendende Server im Klartext zu, und das Zertifikat des Empfängers prüft er meist gar nicht. MTA-STS (RFC 8461) macht daraus eine Pflicht, die du für deine Domain veröffentlichst.
Dazu gehören zwei Teile. Ein TXT-Record unter _mta-sts.example.com kündigt die Policy an, etwa v=STSv1; id=20261109120000. Die Policy selbst ist eine Textdatei unter https://mta-sts.example.com/.well-known/mta-sts.txt mit den Zeilen version: STSv1, mode (none, testing oder enforce), einer oder mehreren mx-Zeilen und max_age in Sekunden. Die Subdomain mta-sts braucht dafür ein eigenes, gültiges HTTPS-Zertifikat.
Ein sendender Server, der MTA-STS beherrscht – etwa bei Google und Microsoft –, lädt die Policy, speichert sie für die Dauer von max_age und stellt im Modus enforce nur noch an MX-Hosts zu, die in der Policy stehen und ein gültiges Zertifikat für ihren Namen vorzeigen. Im Modus testing liefert er trotzdem aus und meldet Fehler nur über TLS-RPT.
Ändert sich die Policy, muss sich auch die id im TXT-Record ändern. Sonst bleiben Absender bei der Fassung, die sie zwischengespeichert haben, bis max_age abgelaufen ist.
Warum gefährlich
Ohne MTA-STS kann jemand, der den Weg zwischen zwei Mailservern kontrolliert, die STARTTLS-Ankündigung aus der Verbindung streichen oder sich mit einem beliebigen Zertifikat dazwischenschalten. Der sendende Server merkt davon nichts und liefert Rechnungen, Verträge und Passwort-Links lesbar aus.
Eine falsch gepflegte Policy richtet den umgekehrten Schaden an: Steht im Modus enforce ein MX-Host nicht in den mx-Zeilen, etwa nach einem Wechsel des Mailanbieters, oder ist sein Zertifikat abgelaufen, verweigern Absender die Zustellung. Die Mails bleiben in deren Warteschlangen hängen und kommen nach einigen Tagen als unzustellbar zurück.
So vermeidest du es
- Mit mode: testing beginnen, gleichzeitig einen TLS-RPT-Record setzen und die Berichte einige Wochen auswerten, bevor du auf enforce umstellst.
- In die mx-Zeilen alle MX-Hosts eintragen; bei Anbietern mit wechselnden Hosts einen Platzhalter wie *.mail.protection.outlook.com für Microsoft 365 verwenden.
- Die Policy-Datei direkt mit Status 200 und ohne Weiterleitung ausliefern und das Zertifikat für mta-sts.example.com automatisch verlängern lassen.
- Bei jeder Änderung an der Datei die id im TXT-Record ändern, zum Beispiel auf einen aktuellen Zeitstempel.
- Im Betrieb ein max_age von mindestens einem Tag (86400) setzen, besser mehrere Wochen; vor einem Anbieterwechsel zuerst den neuen MX-Host in die Policy aufnehmen.
- Wer dafür keinen eigenen Webserver betreiben will, lässt die Policy samt Zertifikat von DomainWarn hosten; der Kunde setzt dann nur einen CNAME und den TXT-Record.
So erkennt DomainWarn es
Der Check MTA-STS liest den TXT-Record unter _mta-sts, lädt die Policy-Datei per HTTPS und gleicht ihre mx-Zeilen mit den tatsächlichen MX-Records der Domain ab. Er meldet einen fehlenden id-Tag, mehrere konkurrierende Records, eine nicht abrufbare oder weitergeleitete Policy, eine ungültige version-Zeile, einen ungültigen Modus sowie fehlendes max_age oder fehlende mx-Einträge. Bleibt ein solcher Fehler zwei Läufe lang bestehen, eröffnet DomainWarn den Incident „MTA-STS fehlerhaft“.
MX-Hosts, die im Modus enforce nicht von der Policy abgedeckt sind, stuft der Check als kritisch ein, weil Absender dann nicht mehr zustellen. Die Modi none und testing, ein max_age unter einem Tag und ein fehlender TLS-RPT-Record erscheinen als Hinweise. Änderungen an Record, Modus oder mx-Liste meldet DomainWarn als „MTA-STS geändert“, eine Abschwächung als „MTA-STS abgeschwächt“.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.