MTA-STS für Microsoft 365

DNS-Records anlegen, Policy-Datei selbst hosten (Microsoft übernimmt kein Hosting), MX-Wildcard *.mail.protection.outlook.com konfigurieren und von Testing auf Enforce umstellen — mit TLS-RPT für automatisiertes Reporting.

MTA-STS prüfen Plattform entdecken
Microsoft 365 · MTA-STS & TLS-RPT
Von Wolf-Agents Security Team · Aktualisiert: 8. April 2026

MTA-STS bei Microsoft 365 (Exchange Online)

Microsoft 365 unterstützt MTA-STS nativ seit 2022 — sendende Server können die Transport-Verschlüsselung zu Ihrem Exchange Online erzwingen. Die Policy-Datei muss jedoch selbst gehostet werden: Microsoft stellt klar, dass Exchange Online das Hosting nicht für Kunden übernimmt. Die MX-Wildcard *.mail.protection.outlook.com deckt alle Microsoft-MX-Einträge ab.

Das Self-Hosting-Erfordernis ist der wichtigste Punkt bei Microsoft 365: Ohne eine unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt erreichbare Policy-Datei kann kein sendender Server MTA-STS für Ihre Domain validieren. Geeignete Hosting-Optionen sind Azure Static Web Apps, Cloudflare Pages oder GitHub Pages — alle bieten kostenloses HTTPS. Der Wolf-Agents Email Security Scanner vergleicht Policy-MX und DNS-MX zeichengenau: Er erkennt, wenn Sie einzelne MX-Hosts wie ihre-domain-de.mail.protection.outlook.com statt der Wildcard *.mail.protection.outlook.com in der Policy stehen haben, warnt vor zukünftigen MX-Ergänzungen durch Microsoft und prüft das inoffizielle CNAME-Pattern microsoftonline.com als Fehlkonfiguration.

Seit Oktober 2024 unterstützt Microsoft auch DANE (inbound GA) — MTA-STS und DANE sind komplementäre Maßnahmen. MTA-STS funktioniert ohne DNSSEC und ist daher als erster Schritt empfohlen. Für NIS2-pflichtige Unternehmen erfüllt MTA-STS enforce auf Microsoft 365 die Anforderungen aus Art. 21 Abs. 2 lit. h und BSI TR-03108 zur Verschlüsselung des E-Mail-Transports. DSGVO Art. 32 fordert Verschlüsselung personenbezogener Daten bei der Übertragung — Microsoft 365 dokumentiert TLS-Version und Cipher pro Connector in den Message Trace Logs (Exchange Admin Center → Mail Flow → Message Trace), die als TOM-Nachweis bei DSGVO-Audits dienen. Ein gelegentlich kursierendes CNAME-Pattern DOMAIN-TLD.mta-sts.microsoftonline.com ist nicht offiziell dokumentiert — verwenden Sie es nicht.

Ausführliche MTA-STS & TLS-RPT Übersicht

1 Schritt 1 von 4

DNS-Records anlegen (MTA-STS + TLS-RPT)

Zwei TXT-Records sind erforderlich: der MTA-STS-Record unter _mta-sts aktiviert die Policy-Abfrage, der TLS-RPT-Record unter _smtp._tls definiert die Empfangsadresse für TLS-Fehlerberichte. Beide Records sind unabhängig von der Exchange-Online-Konfiguration und werden rein im DNS Ihrer Domain angelegt.

Der id-Wert im MTA-STS-Record dient als Cache-Invalidierung: Sendende Server vergleichen diesen Wert mit dem gespeicherten Wert und laden die Policy neu, wenn er sich ändert. Verwenden Sie einen Zeitstempel oder eine Versionsnummer. Bei jeder Policy-Änderung muss der id-Wert im DNS-Record ebenfalls aktualisiert werden.

DNS-Zone TXT-Records 
# MTA-STS DNS-Record
_mta-sts.ihre-domain.de.  IN TXT  "v=STSv1; id=20260408T120000"

# TLS-RPT DNS-Record
_smtp._tls.ihre-domain.de.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"
2 Schritt 2 von 4

Policy-Datei erstellen und hosten

Die Policy-Datei muss unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt per HTTPS erreichbar sein. Microsoft hostet diese Datei nicht — Sie müssen sie selbst bereitstellen. Starten Sie im Testing-Modus, damit fehlerhafte Konfigurationen keinen E-Mail-Verlust verursachen.

Die MX-Wildcard *.mail.protection.outlook.com deckt alle MX-Einträge ab, die Microsoft 365 verwendet — einschließlich regionaler Varianten. Verwenden Sie nicht den konkreten MX-Hostnamen Ihres Tenants (z.B. ihre-domain-de.mail.protection.outlook.com), da Microsoft diesen jederzeit ändern kann.

/.well-known/mta-sts.txt Testing-Modus 
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

Hosting-Optionen für Microsoft 365

  1. Cloudflare Pages: Kostenlos, automatisches SSL, globales CDN — empfohlen für die meisten Setups. Erstellen Sie ein Repository mit /.well-known/mta-sts.txt und verknüpfen Sie die Custom Domain mta-sts.ihre-domain.de
  2. Azure Static Web Apps: Naheliegend im Microsoft-Ökosystem, kostenloser Free-Tier, automatisches SSL. Ideal wenn Sie bereits Azure nutzen
  3. GitHub Pages: Kostenlos, HTTPS über GitHub-Zertifikat, einfachstes Setup. Custom Domain per CNAME-Record auf mta-sts.ihre-domain.de
  4. Eigener Webserver (nginx): Volle Kontrolle, Let's-Encrypt-Zertifikat. Siehe nginx-Konfiguration unten
nginx.conf Self-Hosting 
server {
    listen 443 ssl http2;
    server_name mta-sts.ihre-domain.de;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.ihre-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.ihre-domain.de/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        root /var/www/mta-sts;
    }
}
3 Schritt 3 von 4

Policy verifizieren

Nach dem Anlegen der DNS-Records und dem Hosting der Policy-Datei prüfen Sie beide Komponenten: DNS-Auflösung der TXT-Records und HTTPS-Erreichbarkeit der Policy-Datei. Erst wenn beide korrekt sind, wird MTA-STS von sendenden Servern validiert.

Beachten Sie die DNS-Propagation: Nach dem Anlegen der Records kann es bis zu 24 Stunden dauern, bis alle DNS-Resolver weltweit den neuen Eintrag sehen. Testen Sie zunächst mit dem autoritativen Nameserver Ihrer Domain. Der Wolf-Agents Email Security Scanner zeigt Ihnen den aktuellen MTA-STS-Status als Teil der automatisierten Prüfung.

Terminal / PowerShell Verifikation 
# DNS-Records prüfen (Linux / macOS)
dig _mta-sts.ihre-domain.de TXT +short
dig _smtp._tls.ihre-domain.de TXT +short

# DNS-Records prüfen (Windows PowerShell)
Resolve-DnsName -Name _mta-sts.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
Resolve-DnsName -Name _smtp._tls.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings

# Policy-Datei abrufen
curl -s https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt

# Erwartete Ausgabe:
# version: STSv1
# mode: testing
# mx: *.mail.protection.outlook.com
# max_age: 86400
4 Schritt 4 von 4

Von Testing auf Enforce umstellen

Nach 1-2 Wochen im Testing-Modus ohne Probleme in den TLS-Reports stellen Sie die Policy auf mode: enforce um. Im Enforce-Modus verweigern sendende Server die E-Mail-Zustellung, wenn keine TLS-Verbindung zu Ihrem MX-Host möglich ist — das ist der Schutz vor STRIPTLS-Angriffen.

Erhöhen Sie beim Wechsel auf Enforce den max_age-Wert von 86400 (1 Tag) auf 604800 (7 Tage) oder höher. Aktualisieren Sie den id-Wert im DNS-Record — ohne diese Änderung laden sendende Server die neue Policy nicht. Die TLS-Reports unter der in _smtp._tls definierten Adresse zeigen eventuelle Zustellprobleme.

/.well-known/mta-sts.txt Enforce-Modus 
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
Terminal / DNS-Zone Enforce aktivieren 
# 1. Policy-Datei aktualisieren: mode: testing → mode: enforce, max_age: 604800
# 2. DNS-Record id-Wert aktualisieren (muss sich ändern!):
_mta-sts.ihre-domain.de.  IN TXT  "v=STSv1; id=20260408T150000"

# Verifizieren:
dig _mta-sts.ihre-domain.de TXT +short
curl -s https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt

Häufige Fehler bei M365 MTA-STS

Die folgenden drei Fehler treten bei der MTA-STS-Einrichtung mit Microsoft 365 am häufigsten auf. Jeder einzelne verhindert, dass sendende Server Ihre Policy validieren — die Transport-Verschlüsselung kann nicht erzwungen werden.

Self-Hosting vergessen — Policy nicht erreichbar

Symptom: MTA-STS DNS-Record ist vorhanden, aber sendende Server melden in den TLS-Reports sts-policy-fetch-error. Der Wolf-Agents Scanner zeigt MTA-STS als nicht konfiguriert an.

Ursache: Die Policy-Datei ist unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt nicht erreichbar, weil kein Webserver eingerichtet wurde. Microsoft 365 hostet die Policy-Datei nicht — anders als manche Anleitungen suggerieren.

Lösung: Richten Sie das Hosting über Cloudflare Pages, Azure Static Web Apps oder GitHub Pages ein. Prüfen Sie per curl -sI https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt, ob HTTP 200 und Content-Type: text/plain zurückgegeben wird. Das SSL-Zertifikat muss gültig sein — selbstsignierte Zertifikate werden abgelehnt.

MX-Wildcard falsch — konkreter MX-Host statt Wildcard

Symptom: Policy ist erreichbar, aber TLS-Reports zeigen sts-policy-invalid oder sendende Server ignorieren die Policy. E-Mails kommen an, aber MTA-STS-Schutz ist nicht aktiv.

Ursache: In der Policy steht der konkrete MX-Hostname (z.B. mx: ihre-domain-de.mail.protection.outlook.com) statt der Wildcard. Microsoft kann den MX-Eintrag jederzeit ändern — die Policy stimmt dann nicht mehr überein.

Lösung: Verwenden Sie ausschließlich mx: *.mail.protection.outlook.com in der Policy-Datei. Diese Wildcard deckt alle Microsoft-365-MX-Varianten ab, einschließlich regionaler und Load-Balancing-Hostnamen. Aktualisieren Sie den id-Wert im DNS-Record nach der Änderung.

Inoffizielles CNAME-Pattern verwendet

Symptom: Ein CNAME-Record mta-sts.ihre-domain.de → DOMAIN-TLD.mta-sts.microsoftonline.com wurde angelegt. Die Policy-URL liefert entweder einen Fehler oder eine Microsoft-Default-Seite.

Ursache: Dieses CNAME-Pattern kursiert in Foren und Drittanbieter-Anleitungen, ist aber nicht offiziell von Microsoft dokumentiert und funktioniert nicht zuverlässig. Microsoft bietet kein MTA-STS-Hosting über microsoftonline.com an.

Lösung: Entfernen Sie den CNAME-Record und richten Sie stattdessen Self-Hosting ein. Erstellen Sie einen A-Record oder CNAME auf Ihren Hosting-Provider (Cloudflare Pages, Azure, GitHub Pages). Die Policy-Datei muss unter Ihrer eigenen Subdomain per HTTPS erreichbar sein.

NDR 5.4.8 / 5.7.5 bei ausgehender Zustellung an MTA-STS-Domain

Symptom: Outbound-Mails von Exchange Online an externe Domains lösen Non-Delivery-Reports mit Status 5.4.8 "MX hosts of '{domain}' failed MTA-STS validation" oder 5.7.5 "Remote certificate failed MTA-STS validation" aus. Versendende Nutzer erhalten Bounce-Mails.

Ursache: Exchange Online führt seit der GA-Aktivierung Outbound-MTA-STS automatisch durch (laut Microsoft Learn: "MTA-STS forms part of the security infrastructure of Exchange Online, and it's therefore always turned on"). Wenn die Ziel-Domain eine fehlerhafte MTA-STS-Policy hat (MX-Mismatch bei 5.4.8 oder ungültiges Zertifikat bei 5.7.5), wird die Zustellung verweigert. Bei Outbound-Connectors mit Smart Host validiert Microsoft den Smart Host, nicht die finale Ziel-Domain — wichtig für Filter-Gateways.

Lösung: Die Ursache liegt typischerweise auf der Empfänger-Seite. Setzen Sie sich mit dem Empfänger in Verbindung und bitten Sie um eine Korrektur der Policy oder einen temporären Wechsel auf mode: testing. Für eigene Outbound-Connectors prüfen Sie die MTA-STS-Konfiguration des Smart Hosts. Wolf-Agents kann die fremde Policy mit https://wolf-agents.com/tools/email-security-check nicht direkt fixen, aber für Ihre eigene Domain den Status validieren.

PowerShell-Modul PS.MTA-STS für Automatisierung

Symptom: Sie betreuen mehrere Microsoft-365-Domains und möchten MTA-STS-Konfiguration und Monitoring zentral skripten, ohne Azure-DevOps-Pipelines manuell zu bauen.

Ursache: Microsoft hat ein offizielles PowerShell-Modul PS.MTA-STS veröffentlicht (Microsoft Community Hub, Exchange-Blog 4075210), das Setup, Validierung und Reporting für Exchange Online MTA-STS automatisiert.

Lösung: Installation mit Install-Module -Name PS.MTA-STS, anschließend stehen Cmdlets wie Get-MtaStsRecord und Test-MtaStsConfiguration bereit. Für Multi-Domain-Setups deutlich effizienter als manuelle Azure-DevOps-Konfiguration pro Domain.

NIS2-Compliance mit Microsoft 365 MTA-STS

NIS2 Art. 21 Abs. 2 lit. h und die BSI TR-03108 fordern die Verschlüsselung des E-Mail-Transports nach dem Stand der Technik. MTA-STS enforce auf Microsoft 365 erfüllt diese Anforderung, indem sendende Server nachweislich nur über TLS zustellen können. Zusammen mit TLS-RPT erhalten Sie automatisierte Nachweise über die tatsächliche Verschlüsselungsqualität.

Seit Microsoft auch DANE (inbound, GA Oktober 2024) unterstützt, können NIS2-pflichtige Unternehmen beide Standards parallel betreiben. MTA-STS bietet den breiteren Schutz (funktioniert ohne DNSSEC), DANE den kryptografisch stärkeren. Die BSI TR-03108 empfiehlt explizit die Kombination. Prüfen Sie Ihren aktuellen Status mit dem Wolf-Agents Email Security Scanner — alle MTA-STS-Prüfpunkte sind in den 165 Checks enthalten.

Auth-Komplement: Microsoft schaltet Basic Authentication für SMTP-AUTH (Client Submission Port 587) im März 2026 dauerhaft ab — gestaffelte Phasen bis Dezember 2026. Betroffen sind ausschließlich Submission-Auth-Pfade mit Username/Password, NICHT die Server-zu-Server-MTA-STS-Validierung auf Port 25 (Hauptthema dieser Seite). Details, Migrationspfade (OAuth 2.0/Graph, High Volume Email, Azure Communication Services) und Microsoft-Quellen siehe SMTP-TLS für Microsoft 365.

Microsoft 365 MTA-STS Architektur (Multimodal)

Self-Hosting der Policy-Datei, MX-Wildcard *.mail.protection.outlook.com und Outbound-MTA-STS-Pflicht — die Visualisierung zeigt alle Komponenten und ihre Verbindungen zur Microsoft 365 Corporation (Redmond, Washington, USA).

MTA-STS-Anleitung auch für:

Google WorkspaceIONOSStratoAll-InklHetznerPostfixEximCloudflare DNSGenerisch

Wie steht Ihre Domain bei MTA-STS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten