MTA-STS für Google Workspace

DNS-Records anlegen, MX-Varianten prüfen (Legacy aspmx vs. smtp.google.com seit April 2023), Policy-Datei mit Wildcard *.google.com selbst hosten und von Testing auf Enforce umstellen — mit TLS-RPT für automatisiertes Reporting.

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

MTA-STS bei Google Workspace (Gmail)

Google Workspace unterstützt MTA-STS für eingehende Mail-Annahme — die Aktivierung erfolgt jedoch ausschließlich über DNS-Records und eine selbst gehostete Policy-Datei, nicht in der Admin Console. Die MX-Konfiguration unterscheidet zwischen Legacy-Records (fünf aspmx.l.google.com-Einträge) und dem neuen smtp.google.com seit April 2023. Die Wildcard *.google.com in der Policy deckt beide Varianten ab.

Der entscheidende Punkt bei Google Workspace ist die MX-Variante: Wenn Sie die Legacy-MX-Records (aspmx.l.google.com, alt1.aspmx.l.google.com etc.) verwenden, müssen diese in der Policy abgedeckt sein. Seit April 2023 bietet Google den vereinfachten MX-Record smtp.google.com an. Die Wildcard *.google.com deckt beide Varianten zuverlässig ab — verwenden Sie diese als Standard. Der Wolf-Agents Email Security Scanner vergleicht Policy-MX und DNS-MX zeichengenau: Er erkennt den typischen Mismatch zwischen Legacy-MX (aspmx.l.google.com) und neuem smtp.google.com seit April 2023, warnt vor hartkodierten einzelnen MX-Hosts statt Wildcard *.google.com und prüft, ob die Policy-Datei nach einem Workspace-Migrations-Auto-Hosting-Verlust verschwunden ist.

Google bietet für einige Workspace-Kunden möglicherweise ein Auto-Hosting der Policy an — verlassen Sie sich jedoch nicht darauf. Self-Hosting über Google Sites, Cloudflare Pages oder einen eigenen Server garantiert, dass Sie die volle Kontrolle über Ihre Policy behalten. Für NIS2-pflichtige Unternehmen erfüllt MTA-STS enforce auf Google Workspace die Anforderungen aus Art. 21 Abs. 2 lit. h und BSI TR-03108 zur TLS-Erzwingung für eingehenden E-Mail-Verkehr. DSGVO Art. 32 fordert technische Maßnahmen zum Schutz personenbezogener Daten — Google Workspace dokumentiert TLS-Erzwingung pro Empfängerdomain im Postmaster-Tools-Dashboard (postmaster.google.com unter Encryption), das als TOM-Nachweis bei DSGVO-Audits dient.

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

1 Schritt 1 von 4

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

Zwei TXT-Records sind erforderlich: _mta-sts aktiviert die Policy-Abfrage durch sendende Server, _smtp._tls definiert die E-Mail-Adresse für TLS-Fehlerberichte. Diese Records sind unabhängig von der Google Admin Console und werden in der DNS-Zone Ihrer Domain angelegt.

Der id-Wert im MTA-STS-Record signalisiert sendenden Servern, wann die Policy aktualisiert wurde. Ändern Sie diesen Wert bei jeder Policy-Änderung — andernfalls laden Server die neue Policy nicht aus dem Cache nach. Verwenden Sie einen Zeitstempel (z.B. 20260408T120000) oder eine aufsteigende Versionsnummer.

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

MX-Records prüfen und Policy-Strategie wählen

Wichtig: Google Workspace aktiviert MTA-STS nicht über die Admin Console. Die offizielle Google-Doku sagt explizit: "Add these records to your domain settings at your domain host, not in your Google Admin console." Die gesamte MTA-STS-Konfiguration erfolgt über DNS-Records (Schritt 1) und die selbst gehostete Policy-Datei (Schritt 3) — die Admin Console regelt nur das ausgehende TLS-Compliance-Profil unter Apps → Google Workspace → Gmail → Compliance, was eine andere Funktion ist als MTA-STS.

MX-Varianten bei Google Workspace

  1. Legacy-MX (Standard): aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com — fünf Einträge mit unterschiedlichen Prioritäten
  2. Neuer MX (seit April 2023): Ein einzelner smtp.google.com mit Priorität 1 — vereinfacht die Konfiguration und ist von Google empfohlen
  3. Empfohlene Wildcard: *.google.com deckt beide Varianten ab — verwenden Sie diese in der Policy-Datei, um bei einem späteren MX-Wechsel keine Änderung zu benötigen

id-Format nach Google-Doku

  1. Constraint: Der id-Wert muss laut Google-Doku 1 bis 32 alphanumerische Zeichen lang sein
  2. Empfohlenes Format: UTC-Zeitstempel im Format YYYYMMDDTHHMMSS (z.B. 20260408T120000) — selbsterklärend und automatisch aufsteigend
  3. Pflicht-Update: Bei jeder Policy-Änderung (z.B. Wechsel von testing zu enforce) muss id erhöht werden, sonst laden sendende Server die alte Policy aus dem Cache
3 Schritt 3 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. Verwenden Sie die Wildcard *.google.com, die sowohl die fünf Legacy-MX-Records als auch den neuen smtp.google.com-Eintrag abdeckt. Starten Sie im Testing-Modus.

Google bietet für einige Workspace-Kunden möglicherweise Auto-Hosting an. Da Google dieses Feature jedoch nicht für alle Kunden garantiert und jederzeit ändern kann, empfiehlt sich Self-Hosting über Cloudflare Pages, Google Sites oder einen eigenen Server. So behalten Sie die volle Kontrolle über Ihre MTA-STS-Policy.

/.well-known/mta-sts.txt Empfohlen (Wildcard) 
version: STSv1
mode: testing
mx: *.google.com
max_age: 86400

# Die Wildcard *.google.com deckt beide MX-Varianten ab:
# - Legacy: aspmx.l.google.com, alt1-4.aspmx.l.google.com
# - Neu (seit April 2023): smtp.google.com

Hosting-Optionen für Google Workspace

  1. Cloudflare Pages: Kostenlos, automatisches SSL, globales CDN — empfohlen. Repository mit /.well-known/mta-sts.txt erstellen und Custom Domain mta-sts.ihre-domain.de verknüpfen
  2. Google Sites: Im Google-Ökosystem naheliegend, aber eingeschränkte Kontrolle über den Dateipfad /.well-known/. Prüfen Sie, ob die Datei unter dem korrekten Pfad erreichbar ist
  3. GitHub Pages: Kostenlos, automatisches HTTPS. Custom Domain per CNAME-Record auf mta-sts.ihre-domain.de einrichten
  4. Eigener Webserver: Volle Kontrolle mit nginx oder Apache und Let's-Encrypt-Zertifikat. Stellen Sie sicher, dass Content-Type: text/plain zurückgegeben wird
4 Schritt 4 von 4

Verifizieren und Enforce aktivieren

Prüfen Sie DNS-Records und Policy-Erreichbarkeit, bevor Sie auf Enforce umstellen. Im Testing-Modus senden Server TLS-Reports, liefern aber auch bei Fehlern zu. Nach 1-2 Wochen ohne Probleme wechseln Sie auf mode: enforce — dann verweigern Server die Zustellung bei fehlender TLS-Verbindung.

Prüfen Sie zunächst mit dig, welche MX-Records Ihre Domain verwendet — Legacy oder smtp.google.com. Die Wildcard *.google.com in der Policy muss mit dem tatsächlichen MX übereinstimmen. Der Wolf-Agents Email Security Scanner zeigt Ihnen den aktuellen MTA-STS-Status automatisch.

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

# MX-Records prüfen (welche Variante nutzen Sie?)
dig ihre-domain.de MX +short

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

# Erwartete Ausgabe:
# version: STSv1
# mode: testing
# mx: *.google.com
# max_age: 86400
/.well-known/mta-sts.txt Enforce-Modus 
version: STSv1
mode: enforce
mx: *.google.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 Google Workspace MTA-STS

Die folgenden drei Fehler treten bei der MTA-STS-Einrichtung mit Google Workspace besonders häufig auf. Jeder einzelne kann dazu führen, dass die Transport-Verschlüsselung nicht erzwungen wird oder im Enforce-Modus E-Mails abgelehnt werden.

Legacy-MX stimmt nicht mit Policy-MX überein

Symptom: TLS-Reports zeigen sts-policy-invalid oder sts-webpki-invalid. Im Enforce-Modus werden E-Mails von bestimmten Sendern abgelehnt. Der Wolf-Agents Scanner meldet MTA-STS als fehlkonfiguriert.

Ursache: Die Domain wurde von Legacy-MX (aspmx.l.google.com) auf den neuen smtp.google.com migriert, aber die Policy-Datei enthält noch die alten einzelnen MX-Hosts — oder umgekehrt.

Lösung: Verwenden Sie die Wildcard mx: *.google.com in der Policy. Diese deckt beide MX-Varianten ab und macht die Policy robust gegen zukünftige MX-Änderungen. Aktualisieren Sie den id-Wert im DNS nach der Änderung.

Wildcard vs. einzelne MX-Hosts verwechselt

Symptom: Policy funktioniert, aber nur für einen Teil der MX-Records. TLS-Reports zeigen sporadische sts-policy-invalid-Einträge für bestimmte MX-Hosts.

Ursache: In der Policy stehen einzelne MX-Hosts (z.B. mx: aspmx.l.google.com) statt der Wildcard. Wenn Google einen MX-Hostnamen ändert oder hinzufügt, greift die Policy nicht mehr.

Lösung: Ersetzen Sie alle einzelnen mx:-Zeilen durch eine einzige Zeile mx: *.google.com. Die Wildcard-Notation ist bei Google Workspace die robusteste Lösung, da sie alle aktuellen und zukünftigen MX-Hostnamen unter google.com abdeckt.

Auf Auto-Hosting verlassen — Policy verschwindet

Symptom: MTA-STS funktionierte, aber plötzlich zeigen TLS-Reports sts-policy-fetch-error. Die Policy-URL https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt liefert HTTP 404 oder eine Fehlermeldung.

Ursache: Google hat das Auto-Hosting der Policy-Datei deaktiviert oder geändert. Dieses Feature ist nicht für alle Workspace-Kunden garantiert und kann ohne Vorankündigung entfallen.

Lösung: Richten Sie Self-Hosting über Cloudflare Pages, GitHub Pages oder einen eigenen Server ein. Erstellen Sie einen CNAME-Record für mta-sts.ihre-domain.de auf Ihren Hosting-Provider. Prüfen Sie die Erreichbarkeit regelmäßig per curl -sI https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt. Ein Monitoring-Alert auf HTTP-Statuscode ist empfehlenswert.

NIS2-Compliance mit Google Workspace 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. Google Workspace mit MTA-STS enforce gewährleistet TLS-Erzwingung für eingehenden E-Mail-Verkehr — sendende Server müssen nachweislich über eine verschlüsselte Verbindung zustellen. TLS-RPT liefert die dokumentierten Nachweise für die Compliance-Dokumentation.

Google unterstützt sowohl MTA-STS als auch DANE — die BSI TR-03108 empfiehlt die parallele Implementierung beider Standards. MTA-STS ist der pragmatische erste Schritt (funktioniert ohne DNSSEC), DANE bietet den kryptografisch stärkeren Schutz. Prüfen Sie Ihren aktuellen Status mit dem Wolf-Agents Email Security Scanner — alle MTA-STS- und DANE-Prüfpunkte sind in den 165 Checks enthalten.

Google Workspace MX-Wildcard Modell (Multimodal)

Legacy-MX (aspmx.l.google.com mit alt1-alt4) vs. neuer MX smtp.google.com seit April 2023 — die Wildcard *.google.com deckt beide Varianten ab. Quelle: Google LLC, Mountain View, Kalifornien, USA.

MTA-STS-Anleitung auch für:

Microsoft 365IONOSStratoAll-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