SMTP-TLS für Google Workspace
Google verwaltet die TLS-Konfiguration der Gmail-MX-Hosts vollständig — TLS 1.3 ist Standard. Für regulierte Empfängerdomains konfigurieren Sie Secure-Transport-Compliance-Regeln in der Admin Console und verifizieren die Quote im Postmaster Tools Encryption Dashboard.
SMTP-TLS bei Google Workspace (Gmail)
Google Workspace unterstützt laut offizieller Doku TLS 1.0, 1.1, 1.2 und 1.3 — empfohlen wird TLS 1.3 als primäres Protokoll. Für eigene Workspace-Domains gilt mindestens TLS 1.2, im Postmaster Tools Encryption Dashboard sehen Sie die tatsächliche Verschlüsselungsquote. Strenge TLS-Anforderungen pro Empfängerdomain konfigurieren Sie als "Secure transport (TLS) compliance"-Regel.
Der konkrete MX-Hostname Ihrer Domain hängt vom Workspace-Setup ab: Klassische Tenants nutzen aspmx.l.google.com als primären MX plus mehrere altN.aspmx.l.google.com-Fallbacks. Seit April 2023 vergibt Google für neue Workspace-Domains nur noch smtp.google.com als einzelnen MX-Eintrag. Der Wolf-Agents Email Security Scanner erkennt zeichengenau, welcher MX-Cluster aktiv ist, prüft pro Host die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2 und das Google-Trust-Services-Zertifikat — er warnt insbesondere vor häufigen Fehlkonfigurationen nach Workspace-Migrationen, bei denen ein einzelner MX-Host hartkodiert wurde statt der Wildcard-Cluster.
Für die Compliance-Triple (NIS2 Art. 21 Abs. 2 Buchstabe h zur Kryptografie, BSI TR-03108 zum sicheren E-Mail-Transport, DSGVO Art. 32 Abs. 1 Buchstabe a zur Verschlüsselung als technische Maßnahme) liefert Google Workspace zwei prüfbare Nachweise: Erstens das Postmaster Tools Encryption Dashboard (postmaster.google.com), das pro Domain den TLS-Anteil sowohl ausgehender als auch eingehender Mail zeigt; zweitens die Secure-Transport-Compliance-Regel, mit der Sie pro Empfängerdomain die Zustellung an die Bedingung "TLS plus Zertifikats-Validierung plus Hostname-Match" knüpfen können. Wolf-Agents empfiehlt für Google Workspace die Kombination aus SMTP-TLS-Check und MTA-STS — Google validiert MTA-STS-Policies aktiv beim ausgehenden Mailversand und ist einer der frühesten Adopter.
TLS-Status der Google-MX-Hosts prüfen
Ermitteln Sie zuerst, welche Google-MX-Hosts für Ihre Domain hinterlegt sind — die Variante hängt vom Workspace-Onboarding-Datum ab. Anschließend prüfen Sie den STARTTLS-Handshake auf Port 25 mit openssl s_client. Das Zertifikat wird von Google Trust Services LLC ausgestellt, gültige TLS-Versionen sind 1.2 und 1.3.
Wichtig: Mit dem -servername-Parameter senden Sie den SNI-Hostnamen im TLS-Handshake — sonst antwortet der Google-Load-Balancer mit einem generischen Zertifikat. Bei mehreren MX-Hosts (Legacy-Workspaces mit aspmx.l.google.com + alt1.aspmx.l.google.com + alt2.aspmx.l.google.com) testen Sie jeden einzeln — Wolf-Agents führt das automatisch parallel aus und vergleicht das Ergebnis mit dem MX-Eintrag im DNS.
# TLS-Status der Google-MX-Hosts prüfen
# Klassische Workspace-Domains: aspmx.l.google.com
# Neuere Workspace-Domains: smtp.google.com (seit April 2023)
dig MX ihre-domain.de +short
# Erwartete Ausgabe:
# 1 smtp.google.com.
# (oder bei Legacy-Workspaces:)
# 1 aspmx.l.google.com.
# 5 alt1.aspmx.l.google.com.
# 5 alt2.aspmx.l.google.com.
# TLS-Handshake testen
echo | openssl s_client \
-connect smtp.google.com:25 \
-starttls smtp \
-servername smtp.google.com \
2>/dev/null | grep -E "Protocol|Cipher|subject|issuer"
# Erwartete Ausgabe:
# Protocol : TLSv1.3
# Cipher : TLS_AES_256_GCM_SHA384
# subject=CN = mx.google.com
# issuer=C = US, O = Google Trust Services LLC, CN = WE2
# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type MX | Select-Object NameExchange, PreferenceSecure-Transport-Compliance-Regel pro Empfängerdomain anlegen
Gmail nutzt standardmäßig opportunistic TLS — wenn der Empfangsserver kein STARTTLS anbietet, wird im Klartext zugestellt. Für regulierte Partner-Domains konfigurieren Sie eine Secure-Transport-Compliance-Regel: Pfad in der Admin Console laut Google-Doku (knowledge.workspace.google.com, Abruf 11. Mai 2026) ist Apps → Google Workspace → Gmail → Compliance. Direction lässt sich auf Inbound, Outbound oder Both setzen.
Die Einstellung "Require CA signed certificate" erzwingt die Validierung gegen eine vertrauenswürdige CA — selbst-signierte Zertifikate werden abgelehnt. "Validate certificate hostname" prüft zusätzlich, ob das Zertifikat zum Empfänger-Hostnamen passt (Subject/SAN-Match). Wir empfehlen, beide Optionen für regulierte Empfänger zu aktivieren. Die Regel wird über eine Address List definiert: Sie listen die Empfängerdomain (z.B. partner-bank.de) oder einzelne E-Mail-Adressen — Google wendet die Regel dann für ausgehende Mail an diese Empfänger an.
# Pfad in der Google Admin Console
# admin.google.com → Menu → Apps → Google Workspace → Gmail → Compliance
# (Quelle: knowledge.workspace.google.com, Abruf 11. Mai 2026)
# Compliance-Setting "Secure transport (TLS) compliance"
# 1. Klicken auf "Configure" oder Stiftsymbol
# 2. Name vergeben: z.B. "Forced TLS to Partner Bank AG"
# 3. Direction auswählen: Inbound, Outbound oder Both
# 4. Address lists definieren — z.B. Domain-Filter "partner-bank.de"
# 5. TLS-Options aktivieren:
# [x] Require CA signed certificate
# [x] Validate certificate hostname
# Nach dem Speichern: bis zu 24 Stunden Propagation
# Verifizieren per Test-Mail an die Compliance-relevante Domain
# und Prüfung des Original-Headers (zeigt TLS-Verschlüsselung)TLS-Compliance-Optionen im Detail
- Direction: Inbound für Mail an Ihre Domain, Outbound für Mail von Ihrer Domain nach extern, Both für beide Richtungen — für DSGVO-relevante Partner-Kommunikation typisch "Outbound"
- Address lists: Eine oder mehrere Listen — entweder pro Domain (
partner-bank.de) oder pro Einzeladresse (compliance@partner-bank.de). Mehrere Listen sind erlaubt - Require CA signed certificate: Verlangt ein Zertifikat von einer öffentlich vertrauenswürdigen CA (Let's Encrypt, DigiCert, Sectigo) — blockiert selbst-signierte Zertifikate
- Validate certificate hostname: Prüft das Subject/SAN gegen den Empfangsserver-Hostnamen — vergleichbar mit dem Strict-Modus bei MTA-STS
- Propagationszeit: Bis zu 24 Stunden bis die Regel wirksam wird. Test-Mails an die Compliance-relevante Domain senden und im Original-Header die TLS-Verschlüsselung prüfen
TLS-Quote im Postmaster Tools Encryption Dashboard verifizieren
Das Google Postmaster Tools Dashboard (postmaster.google.com) zeigt pro Domain die TLS-Quote ausgehender Mail (von Ihrer Workspace-Domain) und eingehender Mail (an Ihre Domain). Ein Klartext-Spike ist hier sofort sichtbar — bei 100 % TLS sind alle Mailflüsse verschlüsselt, bei Drops unter 95 % sollten Sie die Compliance-Regeln und MTA-STS-Konfiguration prüfen.
Die Daten kommen direkt von Google: Pro E-Mail wird die TLS-Version und der Verifikationsstatus im Backend gespeichert. Das Dashboard aggregiert auf 90-Tage-Trends — ideal für DSGVO-Audit-Berichte, die typischerweise ein Quartal abdecken. Die Daten sind exportierbar als CSV; zusätzlich gibt es die Gmail Postmaster Tools API für automatisierte Compliance-Reports an Ihr SIEM oder GRC-System. Wolf-Agents kombiniert diese Daten mit dem eigenen Scanner-Output und stellt sie im Monitoring-Dashboard alle 6 Stunden zur Verfügung.
# Postmaster Tools Encryption Dashboard
# https://postmaster.google.com/managedomains
# → Domain hinzufügen → per TXT-Record verifizieren
# → Sektion "Encryption" anzeigen
# Encryption-Dashboard zeigt:
# - "% of mail encrypted in transit" — TLS-Anteil ausgehender Mail
# - "% of mail received with valid certificate" — Eingehende mit gültigem Zertifikat
# - Trend über die letzten 90 Tage
# - Drop-Erkennung bei plötzlichen Klartext-Spikes
# Optional: per Email Routing (Gmail Compliance) für interne Audit-Reports
# Alternative API für Automatisierung: Gmail Postmaster Tools API (REST/v1)Häufige SMTP-TLS-Probleme bei Google Workspace
Die folgenden drei Probleme treten bei Google-Workspace-Setups besonders häufig auf — Encryption-Drop im Postmaster Tools Dashboard nach Migration, Compliance-Regel mit zu strenger Hostname-Validation, und der Empfänger-Mailserver mit selbst-signiertem Zertifikat.
Encryption-Drop im Postmaster Tools nach Workspace-Migration
Symptom: Nach Migration der Mail-Domain zu Google Workspace fällt die TLS-Quote im Postmaster Tools Encryption Dashboard von 98 % auf 70 % — obwohl die Workspace-MX-Hosts selbst TLS 1.3 unterstützen.
Ursache: Empfänger-Mailserver, die früher direkt mit Ihrem Mailserver kommuniziert haben, kommunizieren jetzt mit Google. Manche Empfänger haben einen aktiven Forced-TLS-Connector zu Ihrer alten IP, der nicht auf die Google-IPs umgestellt wurde — diese Mails werden abgelehnt und in Folge im Postmaster Dashboard als "not encrypted" geführt, weil andere Empfänger die Mailflüsse mit suboptimaler TLS bedienen.
Lösung: Informieren Sie regelmäßige Geschäftspartner per E-Mail über den Workspace-Wechsel und bitten Sie um Aktualisierung etwaiger Forced-TLS-Connectors auf den neuen MX-Host. Konfigurieren Sie zusätzlich MTA-STS für Ihre Domain — sendende Server validieren dann automatisch die Google-MX-Hosts und cachen das Ergebnis.
Compliance-Regel "Validate certificate hostname" blockiert Wildcard-Empfänger
Symptom: Nach Aktivierung der Compliance-Regel mit Hostname-Validation für eine Empfängerdomain (z.B. partner-bank.de) werden Mails nicht mehr zugestellt — Bounce-Message zeigt "TLS hostname mismatch".
Ursache: Der MX-Host des Empfängers ist beispielsweise mx1.shared-hosting.partner-provider.com und das Zertifikat ist für *.partner-provider.com ausgestellt — nicht für partner-bank.de. Googles Hostname-Validation prüft gegen den DNS-MX-Hostnamen, nicht gegen die Empfänger-Domain.
Lösung: Prüfen Sie per dig MX partner-bank.de +short, welcher MX-Hostname tatsächlich angesteuert wird. Wenn der Empfänger ein Shared-Hosting-Setup nutzt, ist Hostname-Validation oft nicht möglich — deaktivieren Sie diese Option und behalten nur "Require CA signed certificate". Oder bitten Sie den Partner um einen dedizierten MX-Hostnamen mit eigenem Zertifikat.
Empfänger mit selbst-signiertem Zertifikat — Mail wird abgelehnt
Symptom: Eine Compliance-Regel mit "Require CA signed certificate" blockiert Mails an einen Partner — der Partner verwendet sein eigenes Mailserver-Setup mit einem selbst-signierten Zertifikat. Trace zeigt "Untrusted certificate".
Ursache: Selbst-signierte Zertifikate gelten in Googles TLS-Compliance-Modell als nicht vertrauenswürdig — eine Compliance-Regel mit CA-Validation lehnt sie ab. Das ist beabsichtigt: Im STRIPTLS-Bedrohungsmodell ist ein selbst-signiertes Zertifikat funktional gleichwertig zu Klartext.
Lösung: Bitten Sie den Partner um Umstieg auf ein Let's-Encrypt-Zertifikat — kostenlos, vollautomatisch, von allen großen CAs anerkannt. Übergangsweise können Sie die Compliance-Regel für diese eine Empfängerdomain ausnehmen oder die CA-Validation deaktivieren — beide Optionen senken jedoch das Sicherheitsniveau. Der Wolf-Agents Email Security Scanner erkennt selbst-signierte Zertifikate auf MX-Hosts zeichengenau und liefert die Empfehlung an Ihre Partner.
NIS2, BSI TR-03108 und DSGVO Art. 32: Google Workspace mit TLS-Compliance
NIS2 Art. 21 Abs. 2 Buchstabe h fordert Kryptografie und Verschlüsselung als grundlegende Risikomanagement-Maßnahme — Google Workspace erfüllt das mit opportunistic TLS standardmäßig und mit Secure-Transport-Compliance-Regeln für regulierte Empfänger. Die BSI TR-03108 verlangt sicheren E-Mail-Transport mit TLS plus Perfect Forward Secrecy — Google nutzt TLS 1.3 als primäres Protokoll und ECDHE für PFS. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: Das Postmaster Tools Encryption Dashboard (postmaster.google.com) dokumentiert die TLS-Quote pro Domain über 90 Tage und liefert auditierbare CSV-Exports. Das Google-Trust-Services-Zertifikat der MX-Hosts smtp.google.com bzw. aspmx.l.google.com wird automatisch erneuert — kein Kunden-seitiges Cert-Management nötig. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft pro MX-Host die TLS-Version, die Cipher nach BSI TR-02102-2 und die Zertifikats-Kette zeichengenau — er erkennt Workspace-Migrations-Drifts (alter Hostname noch im MX, neues Workspace ist live) sofort.
Wie steht Ihre Domain bei SMTP-TLS?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.