MTA-STS für Microsoft 365 und Google Workspace einrichten

⚡TL;DR

• Microsoft 365 verwendet das MX-Pattern *.mail.protection.outlook.com in der MTA-STS-Policy; Google Workspace benötigt die Patterns *.google.com und *.googlemail.com
• Die Policy-Datei mta-sts.txt muss per HTTPS auf der Subdomain mta-sts deiner Domain gehostet werden, mit einem gültigen TLS-Zertifikat
• Cloudflare Pages oder Cloudflare Workers ermöglichen kostenloses Hosting der Policy-Datei mit automatischem HTTPS
• Immer zuerst im Modus testing mit aktivem TLS-RPT deployen, bevor du auf enforce umstellst

Du nutzt Microsoft 365 oder Google Workspace für deine geschäftlichen E-Mails. Deine MX-Server sind korrekt konfiguriert, SPF, DKIM und DMARC sind eingerichtet. Aber der Transport zwischen SMTP-Servern bleibt verwundbar: Ohne MTA-STS kann ein Angreifer eine unverschlüsselte Verbindung erzwingen und deine Nachrichten abfangen.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) löst dieses Problem, indem es TLS-Verschlüsselung für den E-Mail-Empfang erzwingt. Das Prinzip ist einfach: Du veröffentlichst einen DNS-Eintrag und eine Policy-Datei, die deine autorisierten MX-Server deklarieren und eine gültige TLS-Verbindung voraussetzen.

Dieses Tutorial führt dich Schritt für Schritt durch die Einrichtung von MTA-STS für Microsoft 365, Google Workspace und Cloudflare. Jeder Abschnitt enthält die exakten MX-Patterns, kopierbereite Konfigurationsdateien und die Validierungsbefehle. Falls du MTA-STS noch nicht kennst, lies zuerst unsere Komplettanleitung zu MTA-STS, um die Funktionsweise des Protokolls zu verstehen (siehe Abschnitt „Verwandte Leitfäden" am Ende des Artikels).

Gemeinsame Voraussetzungen für alle Anbieter

Bevor du MTA-STS konfigurierst, überprüfe diese drei Punkte für deine Domain:

1. Gültige TLS-Zertifikate auf deinen MX-Servern

Alle deine MX-Server müssen über ein gültiges TLS-Zertifikat verfügen (mindestens TLS 1.2). Bei Microsoft 365 und Google Workspace ist das standardmäßig der Fall: Microsoft und Google verwalten die Zertifikate ihrer MX-Server selbst.

2. Zugriff auf deine DNS-Zone

Du musst einen TXT-Eintrag bei _mta-sts.captaindns.com und einen CNAME- oder A-Eintrag für die Subdomain mta-sts.captaindns.com erstellen können.

3. HTTPS-Hosting für die Policy-Datei

Die Datei mta-sts.txt muss unter der exakten URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein. Du benötigst HTTPS-Hosting mit einem gültigen Zertifikat für die Subdomain mta-sts.

MTA-STS für Microsoft 365 / Office 365

Das MX-Pattern von Microsoft 365

Microsoft 365 verwendet MX-Server der Form captaindns-com.mail.protection.outlook.com. Das zugehörige Wildcard-Pattern für deine MTA-STS-Policy lautet:

*.mail.protection.outlook.com

Dieses Pattern deckt alle MX-Server von Microsoft 365 ab, einschließlich regionaler Varianten und Konfigurationen mit Exchange Online Protection (EOP).

So überprüfst du deine Microsoft-365-MX-Einträge:

dig MX captaindns.com +short
# Erwartetes Ergebnis: 0 captaindns-com.mail.protection.outlook.com.

Policy-Datei für Microsoft 365

Erstelle die Datei mta-sts.txt mit folgendem Inhalt:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

Direktive	Wert	Erklärung
version	STSv1	Protokollversion
mode	testing	Überwachung ohne Blockierung (Anfangsphase)
mx	*.mail.protection.outlook.com	Deckt alle MX-Server von Microsoft 365 ab
max_age	86400	Cache von 24 Stunden (geeignet für Testing)

DNS-Eintrag für Microsoft 365

Füge diesen TXT-Eintrag in deiner DNS-Zone hinzu:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260207120000"

Das Feld id muss bei jeder Änderung der Policy aktualisiert werden. Verwende einen Zeitstempel im Format YYYYMMDDHHMMSS, um die Nachverfolgung zu erleichtern.

Unterstützt Microsoft 365 MTA-STS?

Microsoft unterstützt MTA-STS beim Versand: Wenn ein Microsoft-365-Server eine E-Mail sendet, prüft er die MTA-STS-Policy der Empfänger-Domain. Microsoft unterstützt MTA-STS auch beim Empfang: Du kannst eine Policy für deine auf Microsoft 365 gehostete Domain veröffentlichen, und sendende Server werden sie beachten.

MTA-STS für Google Workspace

Die MX-Patterns von Google Workspace

Google Workspace verwendet mehrere MX-Server mit unterschiedlichen Namen. Die Patterns, die in deine MTA-STS-Policy aufgenommen werden müssen, lauten:

*.google.com
*.googlemail.com

Diese beiden Patterns decken sämtliche MX-Server von Google Workspace ab, darunter:

MX-Server	Priorität
aspmx.l.google.com	1
alt1.aspmx.l.google.com	5
alt2.aspmx.l.google.com	5
alt3.aspmx.l.google.com	10
alt4.aspmx.l.google.com	10

Policy-Datei für Google Workspace

version: STSv1
mode: testing
mx: *.google.com
mx: *.googlemail.com
max_age: 86400

Beachte, dass zwei mx-Zeilen erforderlich sind: eine für *.google.com und eine für *.googlemail.com. MTA-STS verlangt, dass jedes Pattern in einer eigenen Zeile deklariert wird.

DNS-Eintrag für Google Workspace

Der DNS-Eintrag hat die gleiche Struktur:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260207120000"

Google Workspace und TLS-RPT

Google ist einer der aktivsten Anbieter bei TLS-RPT. Wenn du MTA-STS und TLS-RPT aktivierst, erhältst du detaillierte Berichte von Google über die TLS-Verhandlungen mit deiner Domain. Diese Berichte sind wertvoll, um Probleme zu identifizieren, bevor du auf den Modus enforce umstellst.

MTA-STS auf Cloudflare hosten

Die Policy-Datei muss unter https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein. Cloudflare bietet zwei kostenlose Hosting-Optionen.

Option 1: Cloudflare Pages (empfohlen)

Cloudflare Pages ist die einfachste Lösung. Erstelle ein Repository mit folgender Struktur:

mein-mta-sts-projekt/
  .well-known/
    mta-sts.txt

Schritte für das Deployment:

1. Erstelle ein Git-Repository (GitHub oder GitLab) mit der Datei .well-known/mta-sts.txt
2. Verbinde es mit Cloudflare Pages: Cloudflare-Dashboard > Pages > Create a project
3. Konfiguriere den Build: Framework preset = None, Build command = (leer), Output directory = /
4. Füge die benutzerdefinierte Domain hinzu: Settings > Custom domains > mta-sts.captaindns.com
5. Konfiguriere das DNS: Cloudflare erstellt automatisch einen CNAME-Eintrag

Cloudflare Pages stellt ein automatisches TLS-Zertifikat über Let's Encrypt bereit. Keine weitere Konfiguration erforderlich.

Option 2: Cloudflare Worker

Für mehr Kontrolle oder wenn du kein Git-Repository nutzen möchtest, kann ein Cloudflare Worker die Policy-Datei ausliefern:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/.well-known/mta-sts.txt') {
      const policy = `version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400`;

      return new Response(policy, {
        headers: {
          'Content-Type': 'text/plain; charset=utf-8',
          'Cache-Control': 'public, max-age=3600',
        },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

Schritte:

1. Erstelle einen Worker: Cloudflare-Dashboard > Workers & Pages > Create application
2. Füge den Code ein (passe die mx-Zeilen an deinen Anbieter an)
3. Füge eine benutzerdefinierte Route hinzu: mta-sts.captaindns.com/*
4. Konfiguriere das DNS: Füge einen AAAA-Eintrag mta-sts hinzu, der auf 100:: zeigt (proxied)

Der kostenlose Cloudflare-Workers-Plan umfasst 100.000 Anfragen pro Tag – mehr als ausreichend für MTA-STS.

Welchen Content-Type verwenden?

Die Policy-Datei muss mit dem Content-Type text/plain ausgeliefert werden. RFC 8461 schreibt keinen bestimmten Charset vor, aber text/plain; charset=utf-8 wird für maximale Kompatibilität empfohlen.

TLS-RPT aktivieren, um das Deployment zu überwachen

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist der unverzichtbare Begleiter von MTA-STS. Es liefert dir tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Verhandlungen.

TLS-RPT-Eintrag erstellen

Füge diesen TXT-Eintrag in deiner DNS-Zone hinzu:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Die Berichte werden im JSON-Format, gzip-komprimiert, an die angegebene E-Mail-Adresse gesendet. Du kannst auch eine HTTPS-URL verwenden, um die Berichte per Webhook zu empfangen:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=https://tls-reports.captaindns.com/v1/report"

Was enthalten die TLS-RPT-Berichte?

Jeder Bericht deckt einen Zeitraum von 24 Stunden ab und enthält:

Information	Beschreibung
Policy-Domain	Deine Domain (captaindns.com)
Berichtszeitraum	Start- und Enddatum
Sendende Organisation	Google, Microsoft usw.
Erfolgszähler	Anzahl erfolgreicher TLS-Verbindungen
Fehlerzähler	Anzahl fehlgeschlagener Verbindungen
Fehlertyp	starttls-not-supported, certificate-expired, validation-failure usw.

Berichte interpretieren

Im Modus testing überwachst du die Berichte 2 bis 4 Wochen lang. Liegt die Fehlerrate bei null oder nahe null, kannst du bedenkenlos auf den Modus enforce umstellen.

Die häufigsten Fehler in den Berichten:

Fehler	Wahrscheinliche Ursache	Maßnahme
certificate-expired	Abgelaufenes TLS-Zertifikat auf einem MX-Server	Zertifikat erneuern
certificate-host-mismatch	MX-Hostname nicht vom Zertifikat abgedeckt	SAN des Zertifikats überprüfen
validation-failure	Unvollständige Zertifikatskette	Zwischenzertifikate installieren
sts-policy-fetch-error	Datei mta-sts.txt nicht erreichbar	HTTPS-Hosting überprüfen
sts-webpki-invalid	Ungültiges Zertifikat der Subdomain mta-sts	Zertifikat erneuern

Von Testing zu Enforce: Migrationsplan

Phase 1: Initiales Deployment (Woche 1)

1. Erstelle die Policy-Datei im Modus testing mit max_age: 86400
2. Hoste sie auf Cloudflare Pages oder Workers
3. Veröffentliche den DNS-Eintrag _mta-sts
4. Aktiviere TLS-RPT
5. Validiere mit dem MTA-STS-Prüftool von CaptainDNS

Phase 2: Überwachung (Wochen 2–4)

1. Analysiere die täglichen TLS-RPT-Berichte
2. Behebe identifizierte Fehler (Zertifikate, nicht abgedeckte MX-Server)
3. Stelle sicher, dass die TLS-Erfolgsrate 100 % erreicht

Phase 3: Umstellung auf Enforce

1. Ändere die Policy-Datei: mode: enforce
2. Erhöhe max_age: erst auf 604800 (7 Tage), dann auf 2592000 (30 Tage)
3. Aktualisiere das Feld id im DNS-Eintrag
4. Überwache weiterhin die TLS-RPT-Berichte

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 2592000

Notfall-Rückfall auf Testing

Falls nach der Umstellung auf enforce E-Mails abgelehnt werden:

1. Stelle sofort mode: testing in der Policy-Datei wieder her
2. Aktualisiere das Feld id im DNS-Eintrag
3. Die sendenden Server laden die Policy erneut herunter und stellen die Ablehnung ein

Die Propagationszeit hängt vom vorherigen max_age ab. Deshalb wird empfohlen, max_age schrittweise zu erhöhen.

Empfohlener Aktionsplan

1. Identifiziere deinen E-Mail-Anbieter: Überprüfe deine MX-Einträge mit dig MX captaindns.com +short
2. Erstelle die Policy-Datei: Nutze den MTA-STS-Generator von CaptainDNS mit den MX-Patterns deines Anbieters
3. Hoste die Policy: Deploye auf Cloudflare Pages (einfachste und kostenlose Option)
4. Veröffentliche die DNS-Einträge: Füge _mta-sts (TXT) und _smtp._tls (TLS-RPT) hinzu
5. Validiere die Konfiguration: Überprüfe mit dem MTA-STS-Syntaxprüfer, ob die Policy korrekt ist
6. Überwache 2–4 Wochen lang: Analysiere die TLS-RPT-Berichte, bevor du auf Enforce umstellst

---

Überprüfe jetzt deine MTA-STS-Konfiguration: Nutze unseren MTA-STS-Prüfer, um deine Domain in wenigen Sekunden zu analysieren.

---

FAQ

Wie konfiguriere ich MTA-STS für Microsoft 365?

Erstelle eine Datei mta-sts.txt mit der Direktive mx: *.mail.protection.outlook.com, hoste sie per HTTPS auf der Subdomain mta-sts deiner Domain und veröffentliche einen DNS-TXT-Eintrag bei _mta-sts mit v=STSv1; id=<Zeitstempel>. Starte im Modus testing mit einem max_age von 86400 Sekunden (24 Stunden).

Wie konfiguriere ich MTA-STS für Google Workspace?

Die Policy-Datei muss zwei mx-Zeilen enthalten: mx: *.google.com und mx: *.googlemail.com. Diese Patterns decken alle MX-Server von Google Workspace ab (aspmx.l.google.com und seine Alternativen). Die restliche Konfiguration (DNS-Eintrag, HTTPS-Hosting) ist identisch mit Microsoft 365.

Welches MX-Pattern verwende ich für Office 365 in der MTA-STS-Policy?

Das korrekte Pattern ist *.mail.protection.outlook.com. Dieses Wildcard deckt alle MX-Server von Microsoft 365 ab, einschließlich regionaler Varianten und Exchange Online Protection. Überprüfe deine MX-Einträge mit dig MX captaindns.com +short, um zu bestätigen, dass sie diesem Pattern entsprechen.

Wie hoste ich die Datei mta-sts.txt auf Cloudflare?

Zwei Optionen: Cloudflare Pages (erstelle ein Git-Repository mit der Datei .well-known/mta-sts.txt und füge die benutzerdefinierte Domain mta-sts.captaindns.com hinzu) oder Cloudflare Workers (deploye ein Skript, das den Inhalt der Policy mit dem Content-Type text/plain zurückgibt). Beide Optionen sind kostenlos und stellen ein automatisches TLS-Zertifikat bereit.

Sollte ich TLS-RPT gleichzeitig mit MTA-STS konfigurieren?

Ja, dringend empfohlen. TLS-RPT (RFC 8460) sendet dir tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Verhandlungen. Veröffentliche einen DNS-TXT-Eintrag bei _smtp._tls mit v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Ohne TLS-RPT hast du keinerlei Einblick in Probleme deines MTA-STS-Deployments.

Funktioniert MTA-STS mit einem kostenlosen Cloudflare Worker?

Ja. Der kostenlose Cloudflare-Workers-Plan umfasst 100.000 Anfragen pro Tag – mehr als ausreichend für MTA-STS. Sendende Server rufen deine Policy nur gelegentlich ab (beim ersten Versand und nach Ablauf des max_age-Caches). Ein kostenloser Worker deckt problemlos Millionen von E-Mails pro Monat ab.

Unterstützen Microsoft und Google MTA-STS nativ?

Ja, beide. Google unterstützt MTA-STS beim Versand (es prüft die Policies der Empfänger-Domains) und veröffentlicht TLS-RPT-Berichte. Microsoft 365 unterstützt MTA-STS beim Versand seit 2020 und sendet ebenfalls TLS-RPT-Berichte. Beide Anbieter verwalten die TLS-Zertifikate ihrer MX-Server automatisch.

Wie überprüfe ich, ob mein MTA-STS-Eintrag gültig ist?

Nutze den MTA-STS-Prüfer von CaptainDNS, um deinen DNS-Eintrag, die Policy-Datei, das TLS-Zertifikat der Subdomain mta-sts und die Übereinstimmung zwischen den deklarierten MX-Patterns und deinen tatsächlichen MX-Einträgen zu überprüfen. Du kannst auch manuell prüfen mit dig TXT _mta-sts.captaindns.com und curl https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Glossar

• MTA-STS: Mail Transfer Agent Strict Transport Security. Standard RFC 8461, der TLS-Verschlüsselung für den E-Mail-Empfang erzwingt.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Mechanismus zur Berichterstattung über erfolgreiche und fehlgeschlagene TLS-Verhandlungen.
• Exchange Online Protection (EOP): E-Mail-Filterdienst von Microsoft 365, der die MX-Server *.mail.protection.outlook.com verwaltet.
• Cloudflare Pages: Hosting-Service für statische Websites von Cloudflare mit automatischem HTTPS und Git-basiertem Deployment.
• Cloudflare Workers: Serverless-Plattform von Cloudflare zur Ausführung von JavaScript möglichst nah am Nutzer.
• max_age: Direktive der MTA-STS-Policy, die die Cache-Dauer in Sekunden angibt.

Verwandte MTA-STS-Leitfäden

• MTA-STS: Die Komplettanleitung zur Absicherung des E-Mail-Transports
• MTA-STS funktioniert nicht? Komplette Fehlerbehebungsanleitung (demnächst)

Quellen

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• Google Support - Strengthen email security with MTA-STS and TLS reporting
• Microsoft Learn - SMTP MTA-STS