DNS-Sicherheit für Google Workspace — DNSSEC, DANE & CAA
Google Workspace (Gmail) ist Mail-Hoster, nicht DNS-Hoster — DNSSEC, DANE TLSA und CAA werden beim externen DNS-Provider Ihrer Custom-Domain konfiguriert. Diese Anleitung deckt NIS2-konforme Absicherung, CAA mit Google Trust Services, MTA-STS-CAA-Wechselwirkung und DANE-Statusprüfung am Google-MX-Host ab.
DNS-Sicherheit für Google Workspace Custom Domains
Google Workspace stellt Gmail als Mail-Backend bereit, aber das DNS-Hosting läuft beim externen DNS-Provider Ihrer Custom-Domain. DNSSEC, DANE TLSA-Records und CAA-Records werden daher dort konfiguriert. Die offizielle Google-Workspace-Doku (support.google.com/a/answer/174125 für MX-Records, Abruf 2026-05-16) beschreibt die Pflicht-DNS-Records, nennt DNSSEC jedoch nicht explizit als Empfehlung — die DNSSEC-Aktivierung ist Best Practice nach RFC 4033 und NIS2 Art. 21 Abs. 2 lit. h, nicht Google-Mandat.
DANE-Status bei Google: Google Workspace hat in jüngerer Zeit damit begonnen, TLSA-Records an den Gmail-MX-Hostnamen zu veröffentlichen — der genaue Status pro MX-Host (smtp.google.com als neuer Single-MX seit April 2023, Legacy aspmx.l.google.com + alt1-alt4) sollte mit dem dig-Befehl in Schritt 4 verifiziert werden, da sich die Provider-side TLSA-Politik ändern kann. Selbst wenn TLSA-Records an Google-MX-Hosts vorhanden sind: Wenn Ihre eigene Zone nicht DNSSEC-signiert ist, ignoriert der sendende Mailserver die TLSA-Records — DNSSEC am eigenen Apex ist die Voraussetzung. Ergänzend bietet Google MTA-STS als komplementären TLS-Erzwingungs-Mechanismus.
Google Domains: Der Domain-Registrar-Dienst Google Domains wurde 2023 von Squarespace übernommen — bestehende Google-Domains-Kunden wurden zu Squarespace migriert. Wenn Ihre Domain noch bei Squarespace (Ex-Google-Domains) liegt, ist das DNS-Panel jetzt das Squarespace-Domains-Panel. Hardening-Pfad: MX-Record → SPF → DKIM → DMARC → MTA-STS → DNSSEC + DANE + CAA (dieser Guide). Bedrohungs-Cluster: Ein DNSSEC-gesicherter MX-Record schützt vor DNS-Hijacking-Spoofing; CAA-Records auf mta-sts-Subdomain verhindern SubdoMailing-Übernahmen.
DNSSEC beim externen DNS-Provider aktivieren
Google Workspace hat kein eigenes DNS-Hosting. DNSSEC muss beim DNS-Provider Ihrer Custom-Domain aktiviert werden. Bei Squarespace-Domains (ex-Google-Domains) erfolgt die DNSSEC-Konfiguration im Squarespace-Panel.
DNSSEC-Aktivierung pro DNS-Provider
- Cloudflare DNS — Dashboard → DNS → Settings → DNSSEC: Enable. Algorithmus 13 (ECDSAP256SHA256).
- IONOS — Automatische DNSSEC-Verwaltung bei eigenen IONOS-Nameservern.
- deSEC.io — DNSSEC standardmäßig aktiv (kostenlos, Berlin, REST-API).
- Netcup — CCP → Domains → DNS → DNSSEC: aktivieren.
- Squarespace-Domains (Ex-Google-Domains) — DNSSEC im Squarespace-Domains-Panel (Status pro TLD im Panel prüfen).
- Hetzner DNS Console — Status laut Hetzner-Doku Oktober 2018: nicht unterstützt. Panel-Lookup zur Bestätigung empfohlen.
DS-Record beim Registrar hinterlegen
Nach DNSSEC-Aktivierung den DS-Record (Key Tag + Algorithm + Digest Type + Digest) beim Registrar Ihrer Domain eintragen. Bei integrierten Setups (DNS-Provider = Registrar) typischerweise automatisch — bei externem Registrar (united-domains, InterNetX, Squarespace-Domains, Namecheap, GoDaddy) ein manueller Kopier-Schritt.
DS-Record-Propagation typisch 1-24 Stunden. Erst wenn der DS-Record bei der übergeordneten Zone aktiv ist, beginnen Resolver die Chain of Trust zu validieren. Vorher klassifiziert der Resolver die Zone als Insecure (nicht Bogus, aber auch nicht Secure) — DNSSEC ist dann noch wirkungslos.
Wenn Sie Ihre Custom-Domain bereits in der Google Cloud Platform betreiben, kann Google Cloud DNS als DNS-Hoster eingesetzt werden — Google dokumentiert DNSSEC-Support unter cloud.google.com/dns/docs/dnssec (Stand 2026-05-18 leitet auf docs.cloud.google.com/dns/docs/dnssec weiter — die Detail-Verifikation der genauen Algorithmen-Defaults erfordert Login-pflichtigen Cloud-Console-Zugriff und wird hier konservativ markiert). Für reine Google-Workspace-Setups ohne Google Cloud Platform sind die DACH-Alternativen aus Schritt 1 wirtschaftlicher (Cloudflare DNS gratis + DNSSEC mit Algorithmus 13 in 1-Click, deSEC kostenlos mit DNSSEC by default). Squarespace-Domains-Migration: Wer noch von Google Domains zu Squarespace migriert wurde (Übernahme 2023), findet im Squarespace-Domains-Panel den DNSSEC-Status pro TLD — bei .de-Domains ist eine Migration zu IONOS oder deSEC oft komfortabler, weil dort der DENIC-DS-Workflow vollständig integriert ist.
CAA-Records mit Google Trust Services und Let's Encrypt
Wenn Sie CAA-Records nutzen, achten Sie auf zwei CAs: pki.goog (Google Trust Services) für Google-eigene Dienste am Apex, letsencrypt.org für MTA-STS-Zertifikat auf mta-sts-Subdomain. Ohne kompatible CA-Autorisierung schlägt MTA-STS-Zertifikatsausstellung fehl.
; CAA-Records für Google-Workspace-Domain (RFC 8659)
example.com. IN CAA 0 issue "pki.goog" ; Google Trust Services
example.com. IN CAA 0 issue "letsencrypt.org" ; MTA-STS-Cert
example.com. IN CAA 0 issuewild ";" ; keine Wildcards
example.com. IN CAA 0 iodef "mailto:security@example.com"
; Subdomain-spezifischer CAA für mta-sts (RFC 8659 § 3)
mta-sts.example.com. IN CAA 0 issue "letsencrypt.org"Ab dem 15. März 2026 müssen alle öffentlichen CAs DNSSEC bei CAA- und Domain-Control-Validation-Lookups validieren. Wer CAA-Records ohne DNSSEC betreibt, riskiert ab März 2026 Verzögerungen oder Fehlschläge bei TLS-Zertifikatsausstellungen — insbesondere für MTA-STS-Subdomains und bei automatischer Erneuerung mit ACME.
DNSSEC + DANE + CAA verifizieren
Nach der Aktivierung prüfen Sie die vollständige DNSSEC-Kette, den TLSA-Status am Google-MX-Host und die CAA-Records.
# Google-Workspace-MX prüfen
dig MX example.com +short
# Erwartet (Single-MX, ab April 2023): 1 smtp.google.com.
# Oder Legacy: 1 aspmx.l.google.com. + 5 alt1.aspmx.l.google.com. ...
# DNSSEC der eigenen Zone prüfen
dig +dnssec MX example.com | grep -E "RRSIG|ad;"
# Erwartet: "ad" Flag und RRSIG-Records.
# DANE/TLSA am Google-MX-Host prüfen
dig TLSA _25._tcp.smtp.google.com +short
# Stand 2026: Google veröffentlicht TLSA-Records am MX-Host —
# Direktwert ist provider-side und kann sich ändern; prüfen Sie aktuell.
# CAA-Records am eigenen Apex und auf mta-sts-Subdomain
dig CAA example.com +short
dig CAA mta-sts.example.com +short
# Komplette Chain-of-Trust
delv @1.1.1.1 example.com A
# Erwartet: "fully validated"
Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser erkennt Google-Workspace-MX automatisch (sowohl smtp.google.com Single-MX als auch Legacy aspmx.l.google.com-Cluster), validiert die DNSSEC-Kette am externen DNS-Provider, prüft TLSA-Records am Google-MX-Host und CAA am Apex/MTA-STS-Subdomain. DNSViz visualisiert die Chain-of-Trust.
Häufige Fehler bei DNS-Sicherheit für Google Workspace
DNSSEC in Google-Admin-Console gesucht
Problem: DNSSEC-Toggle wird in der Google-Workspace-Admin-Console erwartet. Ursache: Google Workspace ist Mail-Backend, nicht DNS-Hoster. Lösung: DNSSEC beim DNS-Provider aktivieren, der Ihre Zone hostet — bei Squarespace-Domains (Ex-Google-Domains) im Squarespace-Panel.
CAA blockiert MTA-STS-Zertifikat
Problem: CAA erlaubt nur pki.goog am Apex, MTA-STS-Hoster nutzt Let's Encrypt — Zertifikatsausstellung schlägt fehl. Ursache: CAA zu restriktiv. Lösung: Mehrere issue-Tags am Apex oder Subdomain-spezifischen CAA auf mta-sts.example.com mit letsencrypt.org.
TLSA-Vorhandensein bei Google angenommen, ohne dig-Prüfung
Problem: Annahme, dass Google für alle MX-Hosts TLSA-Records hat, ohne dig-Prüfung. Ursache: Provider-side-DANE-Status kann sich pro MX-Host und über Zeit ändern. Lösung: Per dig TLSA _25._tcp.smtp.google.com +short aktuellen Status verifizieren — und im Wolf-Agents-Monitoring überwachen.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Google Workspace
Eine DNSSEC-gesicherte Custom-Domain für Google Workspace mit CAA-Records und MTA-STS-Policy ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung). Google ist DSGVO-konform mit Data-Residency-Optionen für die EU; die externen DNS-Records bleiben in der Hoheit des Domain-Inhabers — für sensible Branchen (Justiz, Gesundheit) bietet ein EU-natives DNS-Hosting bei deSEC, IONOS oder Hetzner zusätzliche Datensouveränität.
Google-Workspace-DNS-Compliance-Stack: NIS2 lit. h (DNSSEC + CAA + MTA-STS) + NIS2 lit. c (DNS-Redundanz via Anycast) + BSI TR-03108 (DNS-Apex-Sicherung extern) + DSGVO Art. 32 lit. b (Verfügbarkeit, Google-EU-Data-Residency). Wolf-Agents-USP: Der Email Security Check erkennt Google-MX-Pattern automatisch (Single-MX smtp.google.com und Legacy-Cluster Stack-Detection), prüft DNSSEC-Kette am DNS-Provider, validiert TLSA-Records am Google-MX-Host und CAA am Apex/MTA-STS-Subdomain — kein anderer DACH-Scanner deckt diese Google-Workspace-spezifischen Drift-Klassen ab. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing.
DNS-Sicherheits-Anleitung für weitere Provider:
Wie steht Ihre Domain bei DNS-Sicherheit · Google Workspace?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.