MTA-STS und TLS-RPT einrichten: Verschlüsselten Mail-Empfang erzwingen

7 Minuten Lesezeit · Stand 11.10.2026 · Timo Kessel

Mails zwischen Servern werden meist verschlüsselt übertragen – aber nur „wenn möglich“. Ein Angreifer im Netz kann die Verschlüsselung unterdrücken, und der sendende Server merkt es nicht. MTA-STS schließt diese Lücke: Deine Domain teilt mit, dass Mails an sie nur verschlüsselt und nur an die richtigen Server zugestellt werden dürfen.

Das Problem: STARTTLS ist freiwillig

Wenn ein Mailserver eine Mail an deine Domain zustellt, fragt er per STARTTLS, ob verschlüsselt werden kann. Bietet dein Server das nicht an – oder entfernt ein Angreifer das Angebot unterwegs –, wird die Mail einfach unverschlüsselt übertragen. Zertifikate werden dabei üblicherweise auch nicht streng geprüft.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) dreht das um. Große Anbieter wie Gmail und Microsoft halten sich daran: Sie liefern an deine Domain nur noch verschlüsselt und nur an Server, deren Zertifikat gültig ist und deren Name in deiner Richtlinie steht.

Die drei Teile von MTA-STS

Teil	Wo	Zweck
TXT-Eintrag	`_mta-sts.beispiel.de`	Kündigt an, dass es eine Richtlinie gibt, und nennt ihre Version (`id`)
Richtlinie	`https://mta-sts.beispiel.de/.well-known/mta-sts.txt`	Legt Modus, erlaubte MX-Server und Gültigkeit fest
TLS-RPT (optional, empfohlen)	`_smtp._tls.beispiel.de`	Adresse für tägliche Berichte über Verschlüsselungsfehler

Schritt für Schritt einrichten

Prüfen, ob deine MX-Server sauber verschlüsseln. Jeder Server aus deinen MX-Einträgen braucht STARTTLS und ein gültiges Zertifikat, das auf seinen Namen ausgestellt ist (nicht auf irgendeinen anderen Namen des Hosters). Die Domain-Überwachung von Postwacht zeigt das für jeden MX-Server an.
Die Richtlinie anlegen. Sie ist eine einfache Textdatei, die unter der Subdomain mta-sts per HTTPS erreichbar sein muss – mit gültigem Zertifikat für mta-sts.beispiel.de:
```
version: STSv1
mode: testing
mx: mail.beispiel.de
mx: *.mailserver.example
max_age: 86400
```
Jeder MX-Server muss auf eine mx-Zeile passen. Ein Stern steht für genau einen Namensteil: *.mailserver.example passt auf mx1.mailserver.example, nicht auf a.b.mailserver.example.
Den TXT-Eintrag anlegen:
```
_mta-sts.beispiel.de.  TXT  "v=STSv1; id=20261011T120000"
```
Die id ist frei wählbar, muss sich aber bei jeder Änderung der Richtlinie ändern. Ein Zeitstempel ist praktisch.
Mit mode: testing starten. Im Testmodus wird nichts abgewiesen, Fehler erscheinen nur in den TLS-RPT-Berichten. Nach zwei bis vier Wochen ohne Probleme auf mode: enforce umstellen, max_age auf eine Woche oder mehr erhöhen (z. B. 604800) und die id ändern.

TLS-RPT: Berichte über Fehler

Mit TLS-RPT (RFC 8460) bekommst du – ähnlich wie bei DMARC – täglich Berichte darüber, ob die Zustellung an deine Domain verschlüsselt geklappt hat:

_smtp._tls.beispiel.de.  TXT  "v=TLSRPTv1; rua=mailto:tls-berichte@beispiel.de"

Gerade im Testmodus sind diese Berichte der einzige Weg zu sehen, ob dein Umstieg auf enforce Mails kosten würde.

Typische Fehler

Fehler	Folge
Richtlinie nicht erreichbar oder Zertifikat von `mta-sts.` ungültig	Die Richtlinie wird ignoriert – kein Schutz
Neuer MX-Server, aber nicht in der Richtlinie	Im Modus `enforce` werden Mails an diesen Server nicht zugestellt
Richtlinie geändert, `id` nicht	Sender verwenden bis zu `max_age` lang die alte Fassung
Zertifikat am MX-Server abgelaufen	Im Modus `enforce` kommen keine Mails mehr an
Weiterleitung von `mta-sts.` auf eine andere Adresse	Weiterleitungen sind nicht erlaubt, die Richtlinie gilt als nicht abrufbar

Weil ein abgelaufenes Zertifikat mit enforce sofort Mails kostet, lohnt sich eine Überwachung. Postwacht prüft in der Domain-Überwachung täglich die Richtlinie, ob alle MX-Server darin stehen und wie lange die Zertifikate noch gelten – und meldet sich rechtzeitig vor dem Ablauf.