MTA-STS für Microsoft 365 einrichten: Schritt-für-Schritt-Anleitung
Microsoft 365 und Exchange Online werten eingehende MTA-STS-Richtlinien aus und senden TLS-Berichte. Die eigene Richtliniendatei für Ihre Domäne stellt Exchange Online jedoch nicht selbst bereit. Genau an diesem Punkt scheitern viele Einrichtungen, denn anders als ein DKIM-Schlüssel oder ein SPF-Eintrag lässt sich die MTA-STS-Richtlinie nicht einfach im Microsoft-365-Adminbereich hinterlegen. Sie liegt als Datei auf einer eigenen HTTPS-Subdomäne, die irgendwo erreichbar sein muss.
Diese Anleitung zeigt Schritt für Schritt, wie Sie MTA-STS für Microsoft 365 sauber einrichten: vom DNS-Eintrag über das Hosting der Richtliniendatei bis zum kontrollierten Rollout von testing auf enforce. Die Grundlagen zum Standard selbst finden Sie im Artikel Was ist MTA-STS.
Die Kernreibung: Exchange Online hostet die Richtliniendatei nicht
TL;DR: Für MTA-STS unter Microsoft 365 brauchen Sie drei Dinge: einen TXT-Eintrag unter
_mta-sts, die Richtliniendateimta-sts.txtauf der HTTPS-Subdomänemta-sts.ihre-domain.demit gültigem Zertifikat und in dieser Datei die Empfangshosts untermail.protection.outlook.com. Exchange Online kann diese Datei nicht selbst ausliefern. Hosten Sie sie über einen statischen HTTPS-Host wie eine Azure Static Web App, einen eigenen Webserver oder einen Managed-Dienst, starten Sie im Modustestingund schalten Sie erst nach stabilen TLS-Berichten aufenforce.
Bei MTA-STS gilt es, zwei Richtungen zu unterscheiden. Eingehend, also wenn fremde Server an Ihre Microsoft-365-Domäne zustellen, prüfen diese Server Ihre veröffentlichte Richtlinie. Ausgehend, also wenn Microsoft 365 an andere Domänen sendet, wertet die Plattform deren Richtlinien aus. Letzteres erledigt Microsoft automatisch im Hintergrund. Worum Sie sich kümmern müssen, ist die erste Richtung: das Veröffentlichen Ihrer eigenen Richtlinie.
Und genau hier liegt die Reibung. Die Richtliniendatei muss unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt mit einem gültigen, auf diese Subdomäne ausgestellten Zertifikat abrufbar sein. Exchange Online betreibt für Ihre Domäne keinen Webserver, der Inhalte unter dieser Subdomäne ausliefert. Sie benötigen also einen separaten HTTPS-Endpunkt.
Was Sie für MTA-STS unter Microsoft 365 brauchen
Drei Bausteine müssen zusammenkommen, damit die Einrichtung funktioniert:
| Baustein | Wo | Zweck |
|---|---|---|
TXT-Eintrag _mta-sts | DNS Ihrer Domäne | Signalisiert, dass eine Richtlinie existiert, und trägt eine Versionskennung |
Richtliniendatei mta-sts.txt | HTTPS-Subdomäne mta-sts.ihre-domain.de | Nennt Modus, Gültigkeitsdauer und erlaubte Empfangshosts |
| Gültiges Zertifikat | Für die Subdomäne mta-sts.ihre-domain.de | Stellt sicher, dass die Richtlinie unverfälscht und vertrauenswürdig abgerufen wird |
TXT-Eintrag _smtp._tls | DNS Ihrer Domäne | Optional, aber empfohlen: aktiviert TLS-RPT für Berichte |
Der TXT-Eintrag und der DNS-Verweis auf die Subdomäne liegen in Ihrer Zone und sind schnell gesetzt. Der eigentliche Aufwand steckt im dauerhaften Hosting der Datei und in einem Zertifikat, das nie abläuft.
Schritt für Schritt: MTA-STS für Microsoft 365 einrichten
Schritt 1: Den TXT-Eintrag unter _mta-sts veröffentlichen
Legen Sie in Ihrer DNS-Zone einen TXT-Eintrag an. Name und Wert sehen so aus:
- Name:
_mta-sts.ihre-domain.de - Wert:
v=STSv1; id=2026063001
Die id ist eine frei wählbare Versionskennung, oft im Format Datum plus laufende Nummer. Wichtig ist nur: Ändern Sie später die Richtlinie, müssen Sie auch diese id erhöhen, damit sendende Server die neue Fassung abrufen statt der zwischengespeicherten alten.
Schritt 2: Die Richtliniendatei hosten
Dies ist der entscheidende und gleichzeitig anspruchsvollste Schritt, weil Exchange Online ihn nicht abnimmt. Sie benötigen einen HTTPS-Endpunkt unter der Subdomäne mta-sts.ihre-domain.de, der die Datei mta-sts.txt unter dem Pfad .well-known ausliefert. Für das Hosting gibt es im Wesentlichen drei Wege:
- Managed-Dienst: Ein Dienst wie Conbool MailGuard stellt Subdomäne, Datei und Zertifikat bereit und hält alles automatisch gültig.
- Statischer HTTPS-Host: Eine Azure Static Web App oder ein vergleichbarer statischer Host liefert die Datei aus. Das passt gut in eine bestehende Microsoft-Umgebung, erfordert aber Konfiguration und Pflege des Zertifikats.
- Eigener Webserver: Ein selbst betriebener Webserver mit gültigem Zertifikat. Maximale Kontrolle, maximaler Pflegeaufwand.
Der Inhalt der Datei mta-sts.txt für einen Testlauf sieht so aus:
version: STSv1mode: testingmx: *.mail.protection.outlook.commax_age: 86400
Schritt 3: Die Empfangshosts von Microsoft 365 eintragen
Die Zeilen mx in der Richtliniendatei müssen exakt die Hosts nennen, die für Ihre Domäne Mails annehmen. Bei Microsoft 365 sind das die Endpunkte unter mail.protection.outlook.com. Diese müssen mit Ihrem MX-Eintrag übereinstimmen.
| Konstellation | mx-Zeile in der Richtlinie |
|---|---|
| Microsoft 365 als direkter Empfänger | *.mail.protection.outlook.com |
| Vorgeschaltetes Gateway vor Microsoft 365 | Empfangshosts des Gateways, passend zum MX-Eintrag |
Prüfen Sie Ihren tatsächlichen MX-Eintrag, bevor Sie die mx-Zeilen festlegen. Stimmen Richtlinie und MX-Eintrag nicht überein, lehnen sendende Server im Modus enforce die Zustellung ab, obwohl die Verschlüsselung an sich funktioniert.
Schritt 4: Im Modus testing starten
Belassen Sie mode: testing, bis Sie Vertrauen in die Konfiguration haben. In diesem Modus werten sendende Server Ihre Richtlinie aus und melden Abweichungen, brechen die Zustellung aber nicht ab. So riskieren Sie keinen Mailausfall, während Sie beobachten.
Schritt 5: TLS-RPT aktivieren, um Berichte zu sammeln
Ohne Berichte ist der Testmodus blind. TLS-RPT liefert die nötige Sichtbarkeit. Legen Sie dazu einen weiteren TXT-Eintrag an:
- Name:
_smtp._tls.ihre-domain.de - Wert:
v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de
Sendende Server schicken dann tägliche Berichte an diese Adresse. Daraus lesen Sie ab, wie viele Verbindungen sauber verschlüsselt wurden und woran etwaige Fehlschläge lagen.
Schritt 6: Die Einrichtung verifizieren
Bevor Sie erzwingen, prüfen Sie alles nach. Rufen Sie https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt im Browser auf: Die Datei muss ohne Zertifikatswarnung erscheinen. Prüfen Sie, ob der TXT-Eintrag unter _mta-sts aufgelöst wird und ob die mx-Zeilen Ihrem MX-Eintrag entsprechen. Den Gesamtstatus Ihrer Domäne können Sie mit dem kostenlosen Transportsicherheits-Check prüfen.
Schritt 7: Auf enforce umstellen
Sind die TLS-Berichte über mehrere Tage stabil und sauber, ändern Sie in der Richtliniendatei mode von testing auf enforce und erhöhen die id im TXT-Eintrag. Ab jetzt verweigern sendende Server die Zustellung an Ihre Domäne, wenn die TLS-Verbindung nicht zur Richtlinie passt, statt unverschlüsselt zurückzufallen.
Häufige Stolpersteine bei Microsoft 365
In der Praxis scheitern Einrichtungen meist an wenigen, wiederkehrenden Fehlern:
- CNAME auf der mta-sts-Subdomäne: Microsoft-365-Domänen nutzen oft CNAME-Verweise auf Microsoft-Ziele. Für
mta-sts.ihre-domain.defunktioniert das in der Regel nicht, weil das Zertifikat des CNAME-Ziels diese Subdomäne nicht führt. Verwenden Sie einen A- oder AAAA-Eintrag auf den Host, der die Datei mit passendem Zertifikat ausliefert. - Abgelaufenes Zertifikat: Läuft das Zertifikat der Subdomäne ab, schlägt der Abruf der Richtlinie fehl. Im Modus
enforcekann das im schlimmsten Fall eingehende Zustellungen blockieren. Das Zertifikat muss zuverlässig automatisch erneuert werden. - Richtlinie passt nicht zum MX-Eintrag: Ändern Sie Ihre MX-Konfiguration, etwa durch ein vorgeschaltetes E-Mail-Security-Gateway, müssen die
mx-Zeilen der Richtlinie nachgezogen werden. Sonst kollidiert die Richtlinie mit der tatsächlichen Zustellung.
MTA-STS für Microsoft 365 mit Conbool MailGuard
Die drei genannten Stolpersteine haben eine gemeinsame Ursache: das dauerhafte Bereitstellen von Subdomäne, Datei und Zertifikat. Genau diese Last nimmt Conbool MailGuard ab. Die Subdomäne und die Richtliniendatei werden gehostet, das Zertifikat bleibt automatisch gültig, der Rollout von testing auf enforce erfolgt geführt und die zugehörigen TLS-Berichte laufen an einer Stelle zusammen. Sie pflegen lediglich den TXT-Verweis in Ihrer DNS-Zone, den Rest übernimmt der Dienst.
So lässt sich MTA-STS für Microsoft 365 ohne eigenen Webserver und ohne wiederkehrende Zertifikatspflege betreiben. Die Details zur verwalteten Lösung stehen auf der Seite zu MTA-STS. Wer den verbindlichen Transportschutz ergänzen möchte, findet im Beitrag zu DANE die zertifikatsbasierte Variante über DNSSEC.
Häufig gestellte Fragen
Warum kann Exchange Online die MTA-STS-Richtliniendatei nicht selbst hosten?
Die Richtlinie muss als Datei mta-sts.txt unter der Subdomäne mta-sts über HTTPS mit gültigem Zertifikat erreichbar sein. Exchange Online stellt für Kundendomänen keinen Webserver bereit, der Inhalte unter dieser eigenen Subdomäne ausliefert. Das Hosting übernimmt deshalb ein separater HTTPS-Endpunkt, etwa eine Azure Static Web App, ein eigener Webserver oder ein Managed-Dienst wie Conbool MailGuard. Eingehende Richtlinien anderer Domänen wertet Exchange Online aus, die eigene Richtlinie hostet es nicht.
Welche DNS-Einträge und welche Subdomäne braucht MTA-STS für Microsoft 365?
Erforderlich sind drei Bausteine. Erstens ein TXT-Eintrag unter _mta-sts.ihre-domain.de mit Version und Versionskennung. Zweitens die Subdomäne mta-sts.ihre-domain.de, die per A- oder AAAA-Eintrag auf den Host zeigt, der die Datei ausliefert. Drittens die Datei mta-sts.txt unter dem Pfad .well-known auf dieser Subdomäne, in der die Microsoft-365-Empfangshosts unter mail.protection.outlook.com und der Modus genannt werden. Empfehlenswert ist zusätzlich ein TXT-Eintrag unter _smtp._tls für TLS-RPT.
Wie betreibe ich MTA-STS auf Microsoft 365 zuerst im Testmodus, bevor ich erzwinge?
Setzen Sie in der Datei mta-sts.txt den Eintrag mode auf testing. In diesem Modus werten sendende Server die Richtlinie aus und melden Verstöße über TLS-RPT, brechen die Zustellung bei einer fehlerhaften TLS-Verbindung aber nicht ab. So sehen Sie über die Berichte, ob alle Empfangshosts und das Zertifikat sauber passen, ohne den Mailfluss zu gefährden. Erst wenn die Berichte über mehrere Tage stabil sind, stellen Sie mode auf enforce um.
Funktioniert MTA-STS auch mit Google Workspace?
Ja. Google Workspace wertet eingehende MTA-STS-Richtlinien beim Versand aus und sendet TLS-Berichte. Für die eigene Domäne gilt dasselbe Prinzip wie bei Microsoft 365: Der TXT-Eintrag unter _mta-sts und die Richtliniendatei auf der HTTPS-Subdomäne müssen bereitgestellt werden, hier mit den Google-Empfangshosts unter aspmx.l.google.com statt der Outlook-Hosts. Die Bereitstellung der Datei und des Zertifikats lässt sich plattformunabhängig auslagern.
Warum darf die mta-sts-Subdomäne kein CNAME sein?
Microsoft-365-Domänen verweisen viele Subdomänen per CNAME auf Microsoft-Ziele. Für die Subdomäne mta-sts muss der sendende Mailserver die Richtliniendatei unter genau dieser Subdomäne über HTTPS abrufen können, mit einem Zertifikat, das auf mta-sts.ihre-domain.de ausgestellt ist. Zeigt die Subdomäne per CNAME auf ein fremdes Ziel, das diese Domäne nicht im Zertifikat führt, schlägt der Abruf fehl. Üblich ist daher ein A- oder AAAA-Eintrag auf den Host, der die Datei mit passendem Zertifikat ausliefert.
Fazit
MTA-STS für Microsoft 365 einzurichten ist technisch überschaubar, hat aber eine entscheidende Hürde: Exchange Online liefert die Richtliniendatei nicht selbst aus. Wer den TXT-Eintrag setzt, die Datei auf einer HTTPS-Subdomäne mit gültigem Zertifikat hostet, die Empfangshosts unter mail.protection.outlook.com korrekt benennt und zuerst im Modus testing startet, kann den Schritt auf enforce sicher und ohne Mailausfall gehen.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie auf der Seite zu MTA-STS, wie Conbool MailGuard das Hosting der Richtlinie samt Zertifikat und Rollout übernimmt.
Weiterführende Artikel:
