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; bei Google Workspace hängt es vom Alter der Domain ab: smtp.google.com seit 2023, für ältere Domains der Satz aspmx.l.google.com / *.aspmx.l.google.com / *.googlemail.com
• Die Policy-Datei mta-sts.txt muss per HTTPS auf der Subdomain mta-sts Ihrer 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 Sie auf enforce umstellen

Sie nutzen Microsoft 365 oder Google Workspace für Ihre geschäftlichen E-Mails. Ihre 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 Ihre 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: Sie veröffentlichen einen DNS-Eintrag und eine Policy-Datei, die Ihre autorisierten MX-Server deklarieren und eine gültige TLS-Verbindung voraussetzen.

Dieses Tutorial führt Sie 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 Sie MTA-STS noch nicht kennen, lesen Sie 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 Sie MTA-STS konfigurieren, überprüfen Sie diese drei Punkte für Ihre Domain:

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

Alle Ihre 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 Ihre DNS-Zone

Sie müssen 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. Sie benötigen 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 Ihre 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üfen Sie Ihre 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

Erstellen Sie 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ügen Sie diesen TXT-Eintrag in Ihrer 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. Verwenden Sie 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: Sie können eine Policy für Ihre 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 veröffentlicht je nach Alter der Domain zwei MX-Sätze, und Ihre Policy muss den Satz deklarieren, den Ihre Domain tatsächlich veröffentlicht. Lesen Sie ihn also zuerst aus: dig MX captaindns.com +short.

Seit 2023 dokumentiert Google einen einzigen Eintrag:

MX-Server	Priorität
smtp.google.com	1

Vor 2023 angelegte Workspace-Domains veröffentlichen den historischen Satz, den Google weiterhin unterstützt:

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

Daraus ergeben sich vier mögliche Patterns:

smtp.google.com
aspmx.l.google.com
*.aspmx.l.google.com
*.googlemail.com

Für eine neue Domain genügt das erste, die drei folgenden decken den historischen Satz ab, und alle vier zusammen passen zu einer Domain mitten in der Migration. Ein überzähliges Pattern verhindert keine Zustellung; ein veröffentlichter MX ohne passendes Pattern schon.

Verzichten Sie auf die vielerorts empfohlene Abkürzung *.google.com: RFC 8461 beschränkt den MTA-STS-Wildcard auf ein einziges Label, das am weitesten links stehende. smtp.google.com deckt es zwar ab, bei aspmx.l.google.com bleibt jedoch aspmx.l übrig, und darin steckt ein Punkt. Der Abgleich schlägt fehl, keiner der fünf historischen MX ist abgedeckt. Deshalb *.aspmx.l.google.com für die vier Alternativserver und ein exakter Eintrag für den primären MX.

Policy-Datei für Google Workspace

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

Dieses Beispiel deckt beide Sätze zugleich ab: Es passt unverändert auf eine neue wie auf eine vor 2023 angelegte Domain und trägt auch durch eine Migration von einem Satz zum anderen. Sobald Sie Ihre eigenen MX ausgelesen haben, behalten Sie nur die passenden Zeilen: Eine Policy, die ausschließlich Ihre realen Hosts deklariert, ist strenger. 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 Sie MTA-STS und TLS-RPT aktivieren, erhalten Sie detaillierte Berichte von Google über die TLS-Verhandlungen mit Ihrer Domain. Diese Berichte sind wertvoll, um Probleme zu identifizieren, bevor Sie auf den Modus enforce umstellen.

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. Erstellen Sie ein Repository mit folgender Struktur:

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

Schritte für das Deployment:

1. Erstellen Sie ein Git-Repository (GitHub oder GitLab) mit der Datei .well-known/mta-sts.txt
2. Verbinden Sie es mit Cloudflare Pages: Cloudflare-Dashboard > Pages > Create a project
3. Konfigurieren Sie den Build: Framework preset = None, Build command = (leer), Output directory = /
4. Fügen Sie die benutzerdefinierte Domain hinzu: Settings > Custom domains > mta-sts.captaindns.com
5. Konfigurieren Sie 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 Sie kein Git-Repository nutzen möchten, 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. Erstellen Sie einen Worker: Cloudflare-Dashboard > Workers & Pages > Create application
2. Fügen Sie den Code ein (passen Sie die mx-Zeilen an Ihren Anbieter an)
3. Fügen Sie eine benutzerdefinierte Route hinzu: mta-sts.captaindns.com/*
4. Konfigurieren Sie das DNS: Fügen Sie 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 Ihnen tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Verhandlungen.

TLS-RPT-Eintrag erstellen

Fügen Sie diesen TXT-Eintrag in Ihrer 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. Sie können 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	Ihre 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 überwachen Sie die Berichte 2 bis 4 Wochen lang. Liegt die Fehlerrate bei null oder nahe null, können Sie 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. Erstellen Sie die Policy-Datei im Modus testing mit max_age: 86400
2. Hosten Sie sie auf Cloudflare Pages oder Workers
3. Veröffentlichen Sie den DNS-Eintrag _mta-sts
4. Aktivieren Sie TLS-RPT
5. Validieren Sie mit dem MTA-STS-Prüftool von CaptainDNS

Phase 2: Überwachung (Wochen 2-4)

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

Phase 3: Umstellung auf Enforce

1. Ändern Sie die Policy-Datei: mode: enforce
2. Erhöhen Sie max_age: erst auf 604800 (7 Tage), dann auf 2592000 (30 Tage)
3. Aktualisieren Sie das Feld id im DNS-Eintrag
4. Überwachen Sie 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. Stellen Sie sofort mode: testing in der Policy-Datei wieder her
2. Aktualisieren Sie 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. Identifizieren Sie Ihren E-Mail-Anbieter: Überprüfen Sie Ihre MX-Einträge mit dig MX captaindns.com +short
2. Erstellen Sie die Policy-Datei: Nutzen Sie den MTA-STS-Generator von CaptainDNS mit den MX-Patterns Ihres Anbieters
3. Hosten Sie die Policy: Deployen Sie auf Cloudflare Pages (einfachste und kostenlose Option)
4. Veröffentlichen Sie die DNS-Einträge: Fügen Sie _mta-sts (TXT) und _smtp._tls (TLS-RPT) hinzu
5. Validieren Sie die Konfiguration: Überprüfen Sie mit dem MTA-STS-Syntaxprüfer, ob die Policy korrekt ist
6. Überwachen Sie 2-4 Wochen lang: Analysieren Sie die TLS-RPT-Berichte, bevor Sie auf Enforce umstellen

---

Überprüfen Sie jetzt Ihre MTA-STS-Konfiguration: Nutzen Sie unseren MTA-STS-Prüfer, um Ihre Domain in wenigen Sekunden zu analysieren.

---

FAQ

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

Erstellen Sie eine Datei mta-sts.txt mit der Direktive mx: *.mail.protection.outlook.com, hosten Sie sie per HTTPS auf der Subdomain mta-sts Ihrer Domain und veröffentlichen Sie einen DNS-TXT-Eintrag bei _mta-sts mit v=STSv1; id=<Zeitstempel>. Starten Sie 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 die MX deklarieren, die Ihre Domain tatsächlich veröffentlicht. Seit 2023 dokumentiert Google einen einzigen Eintrag: Eine Zeile mx: smtp.google.com genügt. Eine vor 2023 angelegte Workspace-Domain veröffentlicht den weiterhin unterstützten historischen Satz und braucht drei Zeilen: mx: aspmx.l.google.com, mx: *.aspmx.l.google.com und mx: *.googlemail.com. Der MTA-STS-Wildcard deckt nur ein einziges Label ab, weshalb *.google.com auf keinen Host dieses historischen Satzes passt. 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üfen Sie Ihre 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 (erstellen Sie ein Git-Repository mit der Datei .well-known/mta-sts.txt und fügen Sie die benutzerdefinierte Domain mta-sts.captaindns.com hinzu) oder Cloudflare Workers (deployen Sie 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 Ihnen tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Verhandlungen. Veröffentlichen Sie einen DNS-TXT-Eintrag bei _smtp._tls mit v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Ohne TLS-RPT haben Sie keinerlei Einblick in Probleme Ihres 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 Ihre 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?

Nutzen Sie den MTA-STS-Prüfer von CaptainDNS, um Ihren DNS-Eintrag, die Policy-Datei, das TLS-Zertifikat der Subdomain mta-sts und die Übereinstimmung zwischen den deklarierten MX-Patterns und Ihren tatsächlichen MX-Einträgen zu überprüfen. Sie können 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? Vollständige Fehlerbehebung

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