Stand: Juli 2026

Zusammenfassung: MTA-STS lässt sich bei den großen deutschen Shared-Hostern (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain) nicht per Klick aktivieren. Der DNS-Teil ist trivial — die Hürde ist die per HTTPS bereitgestellte Policy-Datei. Dieser Artikel erklärt, warum, und zeigt die Wege, die dir bleiben.

Was MTA-STS verlangt

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) sorgt dafür, dass andere Mailserver Nachrichten an deine Domain nur über eine Verbindung zustellen, die „authenticated with a valid public certificate” und „encrypted with TLS 1.2 or higher” ist. Das schließt eine gefährliche Lücke: Normalerweise gilt, „if a TLS connection can’t be created, servers often send the message anyway” — also im Klartext. Genau das macht SMTP anfällig, denn „SMTP connections are at risk for man-in-the-middle and other types of malicious attacks”.

Der Haken: MTA-STS besteht aus zwei Teilen — und nur einer davon ist DNS.

  1. DNS-TXT-Record unter _mta-sts.deine-domain (v=STSv1; id=…). Das kann jeder Hoster, der TXT-Records erlaubt — also alle.
  2. Policy-Datei unter https://mta-sts.deine-domain/.well-known/mta-sts.txt. Und hier wird es unbequem.

Warum die Policy-Datei die Hürde ist

Die Policy-Datei muss laut Standard über HTTPS erreichbar sein — auf einer Subdomain, deren Name mit mta-sts beginnt, mit einem gültigen, von einer echten CA signierten Zertifikat. Konkret brauchst du:

  • eine Subdomain mta-sts.deine-domain, die auf einen Webserver zeigt,
  • ein gültiges TLS-Zertifikat für genau diese Subdomain,
  • die Möglichkeit, unter /.well-known/ eine statische Textdatei auszuliefern,
  • und die Disziplin, bei jeder Policy-Änderung die id im DNS hochzuzählen.

Managed-Mailserver nehmen dir das ab — Mailcow etwa „hosts the policy file centrally to simplify management”, generiert die Policy dynamisch und pflegt die id selbst. Google Workspace und Microsoft 365 dokumentieren MTA-STS ausführlich, verlangen aber, dass du die Policy-Datei hostest (Microsoft schlägt Azure vor).

Die deutschen Shared-Hoster bieten schlicht keine MTA-STS-Funktion — weder einen Schalter noch ein zentrales Policy-Hosting. Sie kennen deine MX-Konfiguration nicht als „Feature” und stellen keine Policy-URL bereit.

Die Wege, die dir bei einem Shared-Hoster bleiben

Du kannst MTA-STS trotzdem umsetzen — nur eben manuell:

A) Policy-Datei auf deinem Webspace hosten. Hast du beim selben Hoster ein Webhosting-Paket, richte die Subdomain mta-sts.deine-domain ein, besorge ein Zertifikat (meist Let’s Encrypt per Ein-Klick im Hoster-Panel) und lege die Datei unter /.well-known/mta-sts.txt ab. Die Policy-Datei selbst ist simpel:

version: STSv1
mode: testing
mx: mail.dein-hoster.de
max_age: 86400

Die mx-Zeilen müssen exakt die Hostnamen deiner MX-Records enthalten. Starte mit mode: testing, werte TLS-RPT-Berichte aus, wechsle dann auf enforce.

B) Einen externen MTA-STS-Host nutzen. Es gibt spezialisierte Dienste und Self-Hosting-Vorlagen (statischer Webspace, ein kleiner Cloud-Bucket mit HTTPS, oder ein Cloudflare Worker), die nur die Policy-Datei ausliefern. Deine Domain-DNS bleibt beim Hoster, nur die mta-sts-Subdomain zeigt woandershin.

C) Erst das Fundament, dann MTA-STS. Ehrlich gesagt: MTA-STS ist die Kür. Wenn SPF, DKIM und DMARC noch nicht sauber stehen, hol das zuerst — der Sicherheitsgewinn pro Aufwand ist dort deutlich höher.

Und TLS-RPT?

Anders als MTA-STS ist TLS-RPT ein reiner DNS-TXT-Record ohne HTTPS-Datei — den kannst du bei jedem Shared-Hoster problemlos setzen. Es lohnt sich, TLS-RPT auch dann zu aktivieren, wenn du MTA-STS (noch) nicht umsetzt: Die Berichte zeigen dir, wie oft Mail an deine Domain über TLS zugestellt wird.

Ergebnis prüfen

Der kostenlose MXAudit-Scanner prüft, ob dein _mta-sts-Record existiert, ob die Policy-Datei erreichbar ist und ob ihr Zertifikat gültig ist — zusammen mit TLS-RPT und deiner allgemeinen TLS-Lage.