
MTA-STS für Microsoft 365 einrichten: Diese Anleitung erklärt, warum Exchange Online die Richtliniendatei nicht selbst bereitstellt, welche DNS-Einträge und HTTPS-Subdomäne nötig sind und wie der Rollout von testing auf enforce sauber gelingt, inklusive TLS-RPT und Conbool MailGuard.
Die neuesten Beiträge aus unserem Blog.

DANE verankert das TLS-Zertifikat eines Mailservers über DNSSEC im DNS und schützt so vor Downgrade und Zertifikatsfälschung. Dieser Guide erklärt, was DANE und TLSA sind, wie die Zertifikatsbindung…

Ein Directory Harvest Attack, kurz DHA, sammelt über SMTP gültige E-Mail-Adressen für spätere Spam- und Phishing-Wellen. Dieser Guide erklärt, was ein Verzeichnisangriff ist, wie er sich von…

MTA-STS macht TLS für den E-Mail-Transport verbindlich und schützt vor Downgrade-Angriffen. Dieser Guide erklärt, was MTA-STS ist, wie die Richtlinie technisch funktioniert, worin sie sich von…
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.
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.
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.
Legen Sie in Ihrer DNS-Zone einen TXT-Eintrag an. Name und Wert sehen so aus:
_mta-sts.ihre-domain.dev=STSv1; id=2026063001Die 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.
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:
Der Inhalt der Datei mta-sts.txt für einen Testlauf sieht so aus:
version: STSv1mode: testingmx: *.mail.protection.outlook.commax_age: 86400Die 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.
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.
Ohne Berichte ist der Testmodus blind. TLS-RPT liefert die nötige Sichtbarkeit. Legen Sie dazu einen weiteren TXT-Eintrag an:
_smtp._tls.ihre-domain.dev=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.deSendende 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.
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.
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.
In der Praxis scheitern Einrichtungen meist an wenigen, wiederkehrenden Fehlern:
mta-sts.ihre-domain.de funktioniert 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.enforce kann das im schlimmsten Fall eingehende Zustellungen blockieren. Das Zertifikat muss zuverlässig automatisch erneuert werden.mx-Zeilen der Richtlinie nachgezogen werden. Sonst kollidiert die Richtlinie mit der tatsächlichen Zustellung.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.
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.
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.
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.
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.
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.
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: