MTA-STS einrichten für Microsoft 365
MTA-STS für Microsoft 365: DNS-TXT plus selbst gehostete Policy-Datei mit *.mail.protection.outlook.com.
Stand: Juli 2026
Zusammenfassung: Nach dieser Anleitung erzwingt deine Domain verschlüsselte Zustellung für eingehende Mails an deine Exchange-Online-Postfächer — über einen DNS-Record und eine per HTTPS bereitgestellte Policy-Datei.
⚠️ Empfangsrisiko: Eine fehlerhafte MTA-STS-Policy im
enforce-Modus kann dazu führen, dass andere Server keine Mails mehr an deine Domain zustellen — undmax_agehält den Fehler tagelang im Cache. Beginne immer mitmode: testingund werte TLS-RPT-Berichte aus, bevor du erzwingst.
Voraussetzungen
- Ein Microsoft-365-Tenant, dessen MX auf Exchange Online zeigt (
*.mail.protection.outlook.com) - Zugriff auf die DNS-Verwaltung deiner Domain (beim Domainhost)
- Ein Ort, an dem du die Policy-Datei per HTTPS hosten kannst (Microsoft empfiehlt Azure)
Was ist MTA-STS?
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) sagt anderen Mailservern: „Liefere Mail an meine Domain nur über eine gültige, verschlüsselte TLS-Verbindung." Microsoft unterscheidet zwei Szenarien — hier geht es um den eingehenden Schutz, der „den Schutz von Domänen abdeckt, die in Exchange Online mit MTA-STS gehostet werden".
Wie bei Google Workspace besteht MTA-STS aus zwei Teilen: einem DNS-TXT-Record unter _mta-sts und einer Policy-Datei unter https://mta-sts.deine-domain/.well-known/mta-sts.txt.
Die Ausgangslage bei Microsoft 365
Ein zentraler Punkt aus Microsofts Doku: Exchange Online hostet die Policy-Datei nicht für dich. Wörtlich: „MTA-STS-Richtliniendateien sind nichts, das Exchange Online im Namen von Kunden hosten können." Du musst die Datei also selbst bereitstellen — Microsoft nennt dafür Azure als bequeme Option („Azure Dienste können problemlos für das Richtlinienhosting verwendet werden").
Die MX-Werte in der Policy sind bei allen Exchange-Online-Kunden gleich: *.mail.protection.outlook.com.
Schritt-für-Schritt-Anleitung
1. Policy-Datei erstellen
Die Datei mta-sts.txt sieht bei Exchange Online so aus — starte im testing-Modus (Microsofts eigenes Doku-Beispiel steht direkt auf enforce; sicherer ist der Test zuerst):
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
version: STSv1 muss in der ersten Zeile stehen. Zum Vergleich kannst du jederzeit Microsofts eigene Referenz-Policy ansehen: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.
Werte anschließend die TLS-RPT-Berichte aus — auf mode: enforce wechselst du erst in Schritt 4.
2. Policy-Datei per HTTPS bereitstellen
Hoste die Datei unter https://mta-sts.deine-domain/.well-known/mta-sts.txt — mit einem gültigen Zertifikat, das deine Domain enthält. Microsoft stellt für das Hosting via Azure fertige Konfigurationsflows bereit; grundsätzlich geht aber jeder HTTPS-Webserver, der die Subdomain mta-sts.deine-domain mit vertrauenswürdigem Zertifikat bedient.
3. DNS-TXT-Record anlegen
Beim Domainhost legst du den _mta-sts-Record an. Beispiel:
v=STSv1; id=20250710T120000
Die id signalisiert den Sendern, dass sie die Policy (neu) abrufen sollen. Wichtig: „Nachdem MTA-STS-Richtlinien aktualisiert wurden, müssen Sie die ID aktualisieren" — sonst nutzen Sender die zwischengespeicherte alte Policy weiter, bis deren max_age abläuft.
Ergänze außerdem TLS-RPT (_smtp._tls), damit du Berichte über die TLS-Zustellung bekommst.
4. Prüfen und auf enforce anziehen
Wenn die Berichte zeigen, dass alle legitimen Absender sauber über TLS zustellen, stellst du die Policy-Datei auf mode: enforce und aktualisierst die id im DNS.
Ergebnis prüfen
Prüfe deine Konfiguration mit dem kostenlosen Kuveris-Scanner — er prüft den _mta-sts-Record, ruft die Policy-Datei ab und zeigt sie zusammen mit TLS-RPT und deiner TLS-Lage. Microsoft selbst publiziert übrigens v=STSv1; id=20190225000000Z für microsoft.com.
Häufige Fehler
Erwartet, dass Microsoft die Policy hostet. Tut Exchange Online nicht — die Policy-Datei musst du selbst per HTTPS bereitstellen (z. B. über Azure).
Falsche MX in der Policy. Für Exchange Online muss mx: *.mail.protection.outlook.com in der Policy stehen — nicht deine eigene Domain.
id nach Änderung vergessen. Ohne neue id bleiben Sender bei der alten, gecachten Policy.
Sofort enforce ohne Test. Sicherer ist erst testing, TLS-RPT-Berichte prüfen, dann enforce.
Weiterführende Links
- Microsoft Learn: Verbessern des Nachrichtenflusses mit MTA-STS (abgerufen: 10. Juli 2026)
- RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)
Verwandter Befund: Was bedeutet dieses Ergebnis?