Transportverschlüsselung – dass Post verschlüsselt ankommt, nicht nur meistens

Q: Ist es gefährlich, MTA-STS einzurichten?

Auf testing nicht. Gefährlich ist nur enforce mit einer unvollständigen Liste. Wer die Reihenfolge einhält – testing, Berichte lesen, dann enforce – riskiert nichts.

Q: Wie oft holen sendende Server die Datei neu?

Erst wenn die id im DNS-Eintrag sich ändert oder max_age abgelaufen ist. Deshalb ist das Ändern der id kein Formalismus, sondern der eigentliche Auslöser – eine geänderte Datei ohne neue id bleibt tagelang unbemerkt.

MTA-STS erzwingt verschlüsselte Zustellung an deine Mailserver, TLS-RPT meldet Fehlschläge. Wir zeigen Eintrag, Richtliniendatei und jeden Befund im Einzelnen.

Aktualisiert am 16. September 2026 · Libration Redaktion

Zwischen zwei Mailservern wird heute fast immer verschlüsselt. Das Verfahren dafür heißt STARTTLS, und es hat eine eingebaute Höflichkeit: Der sendende Server fragt, ob Verschlüsselung geht, und wenn der Empfänger nein sagt, schickt er trotzdem – im Klartext. Diese Höflichkeit ist eine Tür. Wer sich zwischen die beiden Server drängt und die Frage einfach mit „nein" beantwortet, bekommt die Nachricht unverschlüsselt zu sehen. Keiner der beiden merkt etwas.

MTA-STS schließt diese Tür. Es ist eine öffentliche Ansage deiner Domain: „Post an uns wird verschlüsselt zugestellt, an genau diese Mailserver, mit gültigem Zertifikat – oder gar nicht." Sendende Server, die sich daran halten, lassen sich dann nicht mehr herunterhandeln. TLS-RPT ist das Gegenstück dazu: Es sagt, wohin gemeldet werden soll, wenn etwas schiefgeht.

Beides betrifft die eingehende Post – es schützt, was andere euch schicken. Damit ergänzt es SPF, DKIM und DMARC, die sich alle um ausgehende Post drehen.

Was wir hier nicht messen können

STARTTLS selbst und die Zertifikate eurer Mailserver prüfen wir nicht. Ausgehende SMTP-Verbindungen sind vom Prüfserver aus gesperrt, und ohne Verbindung gibt es keine Messung. Der Befund sagt deshalb „nicht messbar" statt stillschweigend „in Ordnung". Was wir prüfen, ist alles, was im DNS und über HTTPS von außen sichtbar ist: die MTA-STS-Ansage, die Richtliniendatei und der TLS-RPT-Eintrag.

Wie der Eintrag aussieht

MTA-STS besteht aus zwei Teilen, die zusammengehören. Erstens ein TXT-Eintrag im DNS:

_mta-sts.beispiel-gmbh.de.   TXT   "v=STSv1; id=20260916120000;"

Feld	Bedeutung
`v=STSv1`	Die Kennung.
`id=`	Eine Kennnummer, die sich ändern muss, sobald die Richtliniendatei geändert wird. Ein Zeitstempel ist die bequemste Wahl.

Zweitens eine Datei, die über HTTPS abrufbar ist – unter einer festen Adresse auf einer Unterdomain, die nur dafür da ist:

https://mta-sts.beispiel-gmbh.de/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx00.beispiel-anbieter.de
mx: mx01.beispiel-anbieter.de
max_age: 604800

Zeile	Bedeutung
`mode:`	`enforce` erzwingt, `testing` meldet nur, `none` schaltet ab.
`mx:`	Je eine Zeile pro Mailserver. Alle müssen hier stehen, sonst bricht die Zustellung an die fehlenden ab.
`max_age:`	Wie lange sendende Server die Richtlinie merken dürfen, in Sekunden. 604800 sind sieben Tage.

Der TLS-RPT-Eintrag steht wieder im DNS und ist kurz:

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

Der gefährliche Fehler: enforce mit unvollständiger Liste

Bei SPF und DMARC ist ein Fehler meist ein stiller Verlust an Schutz. Hier ist er etwas anderes: Er kann Post aufhalten.

Steht mode: enforce und fehlt in der Datei einer der Mailserver, die im MX stehen, dann brechen genau die Absender die Zustellung ab, die sich korrekt verhalten. Ihr habt dann einen Ausfall, der nur einen Teil eurer Post betrifft – und zwar den, der von den sorgfältigsten Absendern kommt.

Zustand	Folge
`testing`, Liste unvollständig	Nichts bricht. Ihr bekommt Fehlerberichte, wenn TLS-RPT eingerichtet ist.
`enforce`, Liste vollständig	Der gewünschte Zustand.
`enforce`, Liste unvollständig	Zustellung an die fehlenden Server bricht ab.
DNS-Eintrag da, Datei fehlt	Absender sehen die Ansage und bekommen die Richtlinie nicht. Manche brechen ab.

Deshalb die Reihenfolge: erst testing, ein paar Wochen Berichte lesen, dann enforce. Und bei jedem Wechsel des Postfach-Anbieters gehört die Datei mit auf die Umzugsliste, bevor die MX-Einträge angefasst werden.

So richtest du es ein

Was ihr braucht: eine Unterdomain mta-sts.eure-domain.de, die über HTTPS mit gültigem Zertifikat erreichbar ist, und dort eine einzige Textdatei. Ein Webspace-Paket genügt vollkommen; ein eigener Server ist nicht nötig.

Anbieter	Wo die Bausteine hingehören
IONOS	Unterdomain im Domainbereich anlegen, auf den Webspace zeigen lassen, SSL aktivieren; TXT-Einträge im DNS-Bereich
STRATO	Unterdomain in der Domainverwaltung, Datei per FTP in den zugehörigen Ordner; TXT unter DNS-Einstellungen
Host Europe	Unterdomain im KIS anlegen, Zertifikat aktivieren, Datei in das Webverzeichnis
All-Inkl	Unterdomain im KAS, Let's-Encrypt-Zertifikat dort einschalten, Datei ins Verzeichnis
Hetzner, eigener Server mit Plesk oder cPanel	Unterdomain im Panel, Zertifikat automatisch, Datei ins Dokumentenverzeichnis
Microsoft 365, Google Workspace	Nichts einzustellen – die `mx:`-Zeilen enthalten die MX-Namen, die diese Dienste euch vorgeben
Brevo, CleverReach, Rapidmail, Mailchimp, SendGrid	Nicht betroffen; sie versenden, sie empfangen nicht

Der Weg bei IONOS:

Im DNS-Bereich die Unterdomain mta-sts.deine-domain.de anlegen und auf den Webspace zeigen lassen. SSL für diese Unterdomain aktivieren.
Im Webspace das Verzeichnis .well-known anlegen und darin die Datei mta-sts.txt ablegen, mit version, mode, den mx-Zeilen und max_age.
Mit mode: testing beginnen. Die mx-Zeilen aus den eigenen MX-Einträgen abschreiben – alle, ohne Ausnahme.
Die Adresse https://mta-sts.deine-domain.de/.well-known/mta-sts.txt im Browser öffnen. Es muss der reine Text erscheinen, ohne Zertifikatswarnung.
Im DNS einen TXT-Eintrag anlegen, Hostname _mta-sts, Wert v=STSv1; id= gefolgt von einem Zeitstempel.
Einen zweiten TXT-Eintrag anlegen, Hostname _smtp._tls, Wert v=TLSRPTv1; rua=mailto:tls@deine-domain.de.
Zwei bis vier Wochen Berichte lesen. Bleibt es ruhig, in der Datei auf mode: enforce wechseln – und dabei die id im DNS-Eintrag ändern, sonst merkt es niemand.
Zum Schluss die Domain im Mail-Check prüfen.

Die Befunde im Einzelnen

Mehrere MTA-STS-Einträge

Gemessen: Unter _mta-sts stehen zwei oder mehr TXT-Einträge mit v=STSv1.

Erlaubt ist einer. Mehrere machen die Angabe unbrauchbar – sendende Server können nicht entscheiden, welcher gilt, und ignorieren die Ansage.

Was zu tun ist: Auf einen Eintrag zusammenführen. Meist ist der zweite ein Rest aus einem Versuch mit einer alten Kennnummer.

MTA-STS im Testbetrieb

Gemessen: In der Richtliniendatei steht mode: testing.

Im Testbetrieb wird nichts erzwungen; Abweichungen werden nur gemeldet. Als Einstieg ist das genau richtig gedacht – der Schutz wirkt aber noch nicht.

Was zu tun ist: TLS-RPT einrichten, falls noch nicht geschehen, und ein paar Wochen die Berichte lesen. Bleiben sie ohne Fehlschläge, auf mode: enforce wechseln und die id im DNS-Eintrag hochsetzen.

MTA-STS abgeschaltet (mode: none)

Gemessen: In der Richtliniendatei steht mode: none.

Die Richtlinie ist damit ausdrücklich außer Kraft. Meist ein Rest aus einer Abschaltung während einer Umstellung, den danach niemand zurückgedreht hat.

Was zu tun ist: Entscheiden und aufräumen. Soll MTA-STS gelten, auf testing oder enforce setzen und die id ändern. Soll es nicht gelten, Datei und beide DNS-Einträge entfernen – eine halbe Ansage hilft niemandem.

MTA-STS mit sehr kurzer Gültigkeit

Gemessen: max_age liegt unter einem Tag.

Damit merken sendende Server die Richtlinie kaum. Wer sie nicht gespeichert hat, kann auch nicht bemerken, dass sie plötzlich fehlt – genau das soll MTA-STS aber verhindern. Ein kurzer Wert hebt den Schutz praktisch auf.

Was zu tun ist: max_age auf mindestens 86400 setzen; üblich sind 604800, also sieben Tage. Kurz halten lohnt nur, solange man an der Datei arbeitet – danach hochsetzen.

Richtlinie nennt nicht alle Mailserver

Gemessen: In der Richtliniendatei fehlen Mailserver, die in den MX-Einträgen stehen. Der Modus ist testing.

Im Testbetrieb bricht dadurch nichts ab, aber ihr bekommt Fehlerberichte – und genau dafür ist der Testbetrieb da. Auf enforce umgestellt wäre das ein Ausfall.

Was zu tun ist: Die fehlenden Namen in die Datei aufnehmen, eine mx:-Zeile je Server. Danach die id im DNS-Eintrag ändern. Erst wenn die Liste vollständig ist, über enforce nachdenken.

Erzwungene Richtlinie schließt eigene Mailserver aus

Gemessen: Der Modus ist enforce, aber in der Datei fehlen Mailserver aus euren MX-Einträgen.

Das ist der eine Befund auf dieser Seite, der sofort schadet. Absender, die sich an eure Ansage halten, brechen die Zustellung an die fehlenden Server ab – eure eigene Post kommt nicht an, und zwar ausgerechnet die von den sorgfältigsten Absendern.

Was zu tun ist: Sofort handeln. Entweder alle MX-Namen in die Datei aufnehmen oder vorübergehend auf mode: testing zurückstellen, bis die Liste stimmt. In beiden Fällen die id im DNS-Eintrag ändern – sonst holen sendende Server die geänderte Datei tagelang nicht ab.

MTA-STS-Eintrag ohne Richtliniendatei

Gemessen: Im DNS steht ein MTA-STS-Eintrag, die Datei unter https://mta-sts.<domain>/.well-known/mta-sts.txt ist aber nicht abrufbar.

Absender, die den Eintrag sehen und die Datei nicht bekommen, wissen nicht, woran sie sind; ein Teil bricht ab. Typische Ursachen: Die Unterdomain existiert nicht, ihr Zertifikat gilt nicht für mta-sts.…, der Ordner .well-known wird vom Webserver ausgeblendet, oder die Datei wird als Download statt als Text ausgeliefert.

Was zu tun ist: Die Adresse im Browser öffnen und ansehen, was wirklich kommt. Fehlt die Datei dauerhaft, den DNS-Eintrag entfernen, bis sie steht – eine Ansage ohne Inhalt ist schlechter als keine Ansage.

TLS-RPT ohne Empfängeradresse

Gemessen: Unter _smtp._tls steht ein Eintrag mit v=TLSRPTv1, aber ohne rua=.

Ohne Empfängeradresse werden keine Berichte zugestellt. Damit fehlt genau das, was den Testbetrieb sinnvoll macht: die Rückmeldung, ob eure Richtlinie in der Praxis trägt.

Was zu tun ist: rua=mailto:tls@deine-domain.de ergänzen und dafür sorgen, dass diese Adresse existiert. Die Berichte sind klein und selten – ein einfaches Postfach oder eine Weiterleitung genügt.

Häufige Fragen

Brauchen wir MTA-STS, wenn unser Anbieter ohnehin verschlüsselt?

Verschlüsselt wird meistens ohnehin. MTA-STS beantwortet eine andere Frage: Was passiert, wenn es einmal nicht klappt? Ohne die Ansage schickt der Absender im Klartext, und niemand erfährt davon. Mit ihr schickt er gar nicht – und ihr bekommt einen Bericht.

Ist es gefährlich, MTA-STS einzurichten?

Auf testing nicht. Gefährlich ist nur enforce mit einer unvollständigen Liste. Wer die Reihenfolge einhält – testing, Berichte lesen, dann enforce – riskiert nichts.

Warum eine eigene Unterdomain für eine einzige Textdatei?

Weil die Datei nicht dort liegen darf, wo eure Website liegt: Eine Website wird häufig umgebaut, umgezogen und von Dienstleistern angefasst. Die feste Adresse mta-sts.<domain> sorgt dafür, dass die Richtlinie diese Umbauten übersteht.

Wie oft holen sendende Server die Datei neu?

Erst wenn die id im DNS-Eintrag sich ändert oder max_age abgelaufen ist. Deshalb ist das Ändern der id kein Formalismus, sondern der eigentliche Auslöser – eine geänderte Datei ohne neue id bleibt tagelang unbemerkt.

Der E-Mail-Check misst genau das, was auf dieser Seite steht – an deiner eigenen Domain, in ein bis drei Sekunden und ohne Anmeldung.

Domain jetzt prüfen →