MTA-STS einrichten für Google Workspace

MTA-STS für Google Workspace: DNS-TXT plus Policy-Datei auf der mta-sts-Subdomain — testing zuerst, dann enforce.

Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung erzwingt deine Domain verschlüsselte Zustellung (TLS) für eingehende Mails an deine Google-Workspace-Postfächer — über einen DNS-Record und eine per HTTPS bereitgestellte Policy-Datei.

⚠️ Empfangsrisiko: Eine fehlerhafte MTA-STS-Policy im enforce-Modus kann dazu führen, dass andere Server keine Mails mehr an deine Domain zustellen — und max_age hält den Fehler tagelang im Cache. Beginne immer mit mode: testing und werte TLS-RPT-Berichte aus, bevor du erzwingst.

Voraussetzungen

Was ist MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) sagt anderen Mailservern: „Liefere Mail an meine Domain nur über eine gültige, verschlüsselte TLS-Verbindung — sonst gar nicht." Das verhindert Downgrade- und Man-in-the-Middle-Angriffe auf dem Transportweg.

Anders als SPF, DKIM und DMARC besteht MTA-STS aus zwei Teilen:

  1. Ein DNS-TXT-Record unter _mta-sts, der signalisiert „diese Domain hat eine Policy".
  2. Eine Policy-Datei, die über HTTPS unter mta-sts.deine-domain/.well-known/mta-sts.txt liegt und die konkreten Regeln (erlaubte MX, Modus, Gültigkeit) enthält.

Die Ausgangslage bei Google Workspace

Google dokumentiert MTA-STS gut, betont aber: Die DNS-Records kommen zum Domainhost, nicht in die Google Admin-Konsole („Add these records to your domain settings at your domain host, not in your Google Admin console"). Die passenden MX-Werte für die Policy-Datei bekommst du über die Sicherheitsstatus-Seite der Admin-Konsole.

Schritt-für-Schritt-Anleitung

1. Policy-Datei erstellen

Erstelle eine Textdatei mta-sts.txt — Google startet im testing-Modus (empfohlen für 2 Wochen), der nur berichtet, aber noch nichts erzwingt:

Prüfe zuerst, welche MX-Einträge deine Domain tatsächlich nutzt — die mx:-Zeilen der Policy müssen exakt dazu passen:

dig MX beispiel.de +short

Seit 2023 nutzt Google Workspace einen einzigen MX-Wert (smtp.google.com); ältere Setups laufen oft noch auf den aspmx-Legacy-Werten — beide werden weiterhin unterstützt. Für ein modernes Setup:

version: STSv1
mode: testing
mx: smtp.google.com
max_age: 604800

Für ein Legacy-Setup (MX-Werte beginnen mit aspmx):

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

version: STSv1 muss in der ersten Zeile stehen, die übrigen Felder in beliebiger Reihenfolge. mx: listet deine erlaubten Mailserver (bei Google Workspace die Google-MX), max_age die Gültigkeit in Sekunden (604800 = eine Woche).

2. Policy-Datei per HTTPS bereitstellen

Lege eine Subdomain an, deren Name mit mta-sts beginnt (mta-sts.beispiel.de), erstelle darin ein Verzeichnis .well-known und lade die Datei dorthin. Die fertige URL sieht so aus wie in Googles Beispiel: https://mta-sts.solarmora.com/.well-known/mta-sts.txt.

Der Webserver muss SSL/HTTPS mit einem Zertifikat einer vertrauenswürdigen CA bereitstellen — ein self-signed Zertifikat reicht nicht.

3. DNS-TXT-Records anlegen

Beim Domainhost legst du zwei Records an (Google empfiehlt, TLS-RPT zuerst zu aktivieren):

v=TLSRPTv1; rua=mailto:tlsrpt@beispiel.de

v=STSv1; id=20250710T120000

Die id muss 1–32 alphanumerische Zeichen haben und signalisiert externen Servern, dass deine Domain MTA-STS unterstützt. Ein Datums-Zeitstempel ist üblich — Google selbst nutzt für google.com z. B. v=STSv1; id=20210803T010101.

4. Zwei Wochen testen, dann auf enforce

Lass die Policy zwei Wochen im testing-Modus laufen und werte die TLS-RPT-Berichte aus. Wenn keine legitimen Server scheitern, stellst du mode: enforce in der Policy-Datei ein.

Wichtig bei jeder Änderung: Sobald du die Policy-Datei änderst (auch von testing auf enforce), musst du (a) die Datei auf dem Webserver aktualisieren und (b) die id im _mta-sts-TXT-Record auf einen neuen Wert ändern — sonst merken externe Server die Änderung nicht.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen Kuveris-Scanner — er prüft den _mta-sts-Record, ruft die Policy-Datei ab und zeigt sie zusammen mit TLS-RPT und deiner TLS-Lage.

Häufige Fehler

Nur den DNS-Record gesetzt. Ohne erreichbare Policy-Datei unter mta-sts.deine-domain/.well-known/mta-sts.txt ist MTA-STS unwirksam. Beide Teile gehören zusammen.

Ungültiges HTTPS-Zertifikat. Die Policy-Subdomain braucht ein von einer echten CA signiertes Zertifikat — self-signed schlägt fehl.

id nach Policy-Änderung vergessen. Änderst du die Policy, aber nicht die id, ignorieren externe Server die neue Fassung.

Sofort enforce. Ohne testing-Phase riskierst du, dass legitime Absender bei einem TLS-Problem nicht mehr zustellen können. Erst zwei Wochen testing, Berichte lesen, dann enforce.

Weiterführende Links

Verwandter Befund: Was bedeutet dieses Ergebnis?