MX für Google Workspace einrichten
Schritt-für-Schritt-Anleitung: MX-Record für Google Workspace konfigurieren — neuer Single-MX seit April 2023 (smtp.google.com), Legacy mit 5 Records (aspmx + alt1-alt4) und Migrations-Pfad. Inklusive DNSSEC, Postmaster Tools und dig-Verifikation.
MX-Records für Google Workspace
Seit April 2023 empfiehlt Google für neue Setups einen einzelnen MX-Record: smtp.google.com mit Priorität 1. Hinter diesem Hostnamen steht Googles globale Mail-Infrastruktur mit automatischem Failover über mehrere Regionen. Vor April 2023 nutzte Google ein 5-Server-Setup (aspmx.l.google.com Prio 1, plus alt1.aspmx.l.google.com bis alt4.aspmx.l.google.com mit Prio 5 und 10) — diese Legacy-Konfiguration funktioniert weiterhin, aber Google empfiehlt die Migration zum einzelnen Record. Beide Setups liefern Multi-Region-Redundanz; ein eigener Backup-MX ist nicht nötig und öffnet bei falscher Konfiguration ein MX-Bypass-Risiko.
Als Maßnahme nach NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) und BSI TR-03108 ist die MX-Konfiguration die Basis für SPF (include:_spf.google.com), DKIM-2048-Bit und DMARC. Google als EU/US-Auftragsverarbeiter (DSGVO Art. 28) liefert AVV und Data Residency Option für EU-Kunden (Daten-Speicherort in EU-Rechenzentren wählbar). Der Wolf-Agents Email Security Check prüft beide Google-MX-Muster (neu + Legacy), warnt bei parallelen Records aus früheren Hostern, validiert die A/AAAA-Auflösung von smtp.google.com und scannt den PTR/FCrDNS-Status Google-seitig.
Hardening-Pfad: Nach dem MX-Record folgt direkt SPF für Google Workspace mit v=spf1 include:_spf.google.com ~all, danach DKIM und DMARC. MTA-STS wird von Google bevorzugt für Transport-Verschlüsselung. Bedrohungs-Cluster: Ein korrekt gehärteter MX-Record schließt zwei Klassen von Angriffen — DNS-Hijacking-Spoofing und SubdoMailing über Legacy-aspmx-Subdomains (FBI IC3 2024: 21.442 BEC-Beschwerden, 2,77 Mrd. USD Schaden).
MX-Hostname für Google Workspace bestimmen
Für neue Setups (seit April 2023): ein einzelner Record mit smtp.google.com und Priorität 1. Für Legacy-Setups: 5 Records mit aspmx + alt1-alt4. Google leitet E-Mails an beide Konfigurationen korrekt zu — eine Migration zum neuen Single-MX ist optional, aber empfohlen.
; Empfohlen seit April 2023 — ein einzelner MX-Record
ihre-domain.de. IN MX 1 smtp.google.com.; Legacy-Setup (vor April 2023) — 5 Records mit Round-Robin
ihre-domain.de. IN MX 1 aspmx.l.google.com.
ihre-domain.de. IN MX 5 alt1.aspmx.l.google.com.
ihre-domain.de. IN MX 5 alt2.aspmx.l.google.com.
ihre-domain.de. IN MX 10 alt3.aspmx.l.google.com.
ihre-domain.de. IN MX 10 alt4.aspmx.l.google.com.Wenn Sie vom Legacy- zum neuen Single-MX migrieren, löschen Sie zuerst alle 5 Legacy-Records und legen dann den neuen smtp.google.com-Record an. Eine parallele Konfiguration mit 6 MX-Records (Single + Legacy) führt zu unklarem Routing und verstößt gegen die Best-Practice — der sendende Server würde nach Priorität sortieren und den Single-MX als Prio 1 sehen, aber die Legacy-aspmx-Records ebenfalls als Prio 1 — ein „split horizon“, das DMARC-Reports erschweren kann.
Sobald Ihre MX-Records auf Google zeigen und Sie regelmäßig E-Mails versenden, registrieren Sie Ihre Domain unter postmaster.google.com. Google zeigt dort Spam-Rate, DKIM/SPF/DMARC-Validierungsraten, IP-Reputation und Domain-Reputation — kostenlos, ohne Setup-Aufwand. Für Bulk-Sender (über 5.000 Mails/Tag) ist Postmaster Tools faktisch Pflicht, da Google die Spam-Schwelle dort ablesbar macht (Ziel: dauerhaft unter 0,3% Spam). Quelle: support.google.com/a/answer/174125 (abgerufen 2026-05-14).
Google empfiehlt explizit in der aktuellen Doku (knowledge.workspace.google.com): „Jedes Konto kann den neuen Single-MX-Record-Wert verwenden, aber die älteren MX-Record-Werte werden weiterhin unterstützt.“ Eine Migration vom 5-Record-Legacy-Setup auf smtp.google.com Prio 1 ist optional, nicht zwingend. Empfohlene Migrations-Sequenz: (1) TTL der Legacy-Records 24 h vorher auf 300 s reduzieren, (2) alle 5 aspmx.l.google.com + alt1-alt4 Records gleichzeitig durch den Single-MX ersetzen, (3) nach Propagation per Wolf-Agents Email Security Check verifizieren. Niemals parallel betreiben — das führt zu „split horizon“-Routing und erschwert DMARC-Report-Auswertung. Quelle Cross-Reference: support.google.com/a/answer/16004259 (abgerufen 2026-05-16, Redirect auf knowledge.workspace.google.com).
MX-Record bei DNS-Provider anlegen
Google verwaltet keinen eigenen DNS-Server für Kundendomains — Sie tragen den MX-Record beim Provider Ihrer Wahl ein (Cloudflare DNS, Hetzner DNS, IONOS, Route 53, etc.). Manche Registrare bieten eine automatische Domain-Verifikation für Google Workspace an („Domain Connect“-Protokoll), die den Record im Hintergrund setzt.
Menüpfad in der Google Admin Console
- Anmelden bei admin.google.com
- Navigieren zu Apps → Google Workspace → Gmail → Wichtige Mailserver oder Account → Domänen
- Google zeigt den einzutragenden MX-Record an:
1 smtp.google.com. - Im DNS-Panel Ihres Providers MX-Record anlegen: Host
@· Priorität1· Wertsmtp.google.com. - Alle anderen MX-Records (aus früheren Hostern oder Legacy-Google-Setup) löschen
- Speichern — Propagation 5-30 Minuten, max. 72 Stunden bei langen TTLs
Bei manchen DNS-Providern (Cloudflare DNS UI, Hetzner DNS Console) wird der Trailing-Dot automatisch ergänzt — bei anderen muss er manuell gesetzt werden. Ohne Trailing-Dot interpretiert mancher Provider den Wert als relativen Hostnamen und hängt Ihre Domain an, was zu falschen MX-Lookups führt (z.B. smtp.google.com.ihre-domain.de). Im Zweifel den Trailing-Dot explizit setzen.
DNSSEC + Postmaster Tools aktivieren
Google signiert die Apex-Zone Ihrer Domain nicht — DNSSEC ist Aufgabe Ihres DNS-Providers. Cloudflare DNS aktiviert DNSSEC mit einem Klick und synchronisiert den DS-Record automatisch zum Registrar; Hetzner DNS bietet die gleiche Funktion. Ergänzend: Domain in Postmaster Tools registrieren für Reputations-Monitoring und Spam-Rate-Tracking.
Google Mail-Server haben sowohl A- als auch AAAA-Records mit gültigen PTR-Records — das ist Google-intern und benötigt keine Aktion des Kunden. Für Bulk-Sender (über 5.000 Mails/Tag) verlangt Google seit Februar 2024 funktionierendes IPv6 mit PTR-Records auf der Sender-Seite; eingehend zu Google ist IPv6 automatisch.
MX-Record verifizieren
Nach dem Speichern prüfen Sie die DNS-Propagierung. Google gibt 5-30 Minuten an, mit bis zu 72 Stunden bei langen TTL-Werten.
# Linux / macOS
dig MX ihre-domain.de +short
# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type MX
# Erwartete Ausgabe (neu):
# 1 smtp.google.com.
# DNSSEC-Validierung
dig +dnssec MX ihre-domain.de | grep -E "RRSIG|ad;"Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser erkennt das Google-MX-Pattern automatisch (Stack-Detection), warnt bei paralleler Single + Legacy-Konfiguration, validiert die DNSSEC-Kette und prüft auf Restbestände alter MX-Records aus früheren Hostern. Das Monitoring überwacht den Record alle 6 Stunden und alarmiert bei Abweichungen.
Häufige Fehler bei Google Workspace MX-Records
Single-MX + Legacy parallel aktiv
Problem: Bei Migration auf den neuen smtp.google.com-Record bleiben die 5 Legacy-Records (aspmx.l.google.com + alt1-alt4) bestehen. Ursache: Migration nur „neuen Eintrag hinzufügen“, alte nicht entfernt. Lösung: Alle 5 Legacy-Records vollständig löschen, danach den einzelnen Single-MX-Record anlegen. Wolf-Agents Email Security Check zeigt parallele MX-Hostnamen explizit an.
Falscher Hostname (com vs. l.google.com)
Problem: MX-Eintrag mit aspmx.google.com (ohne l.) oder smtp.l.google.com (mit zusätzlichem l.). Ursache: Verwechslung zwischen neuem (smtp.google.com) und Legacy (aspmx.l.google.com) Pattern. Lösung: Bei Single-MX-Setup ist es smtp.google.com, bei Legacy aspmx.l.google.com + alt1-alt4.aspmx.l.google.com. Werte exakt aus Google Admin Console kopieren.
Eigener Backup-MX trotz Google-Multi-Region
Problem: Google als Prio 1 + eigener Mailserver als Prio 20 als „Backup“. Ursache: Konzeptioneller Fehler — Annahme, dass Google ausfallen könnte. Lösung: Backup-MX entfernen, Google-Multi-Region-Failover reicht. Andernfalls können Angreifer den Google-Filter via direkter Zustellung an den Backup-MX vollständig umgehen — der klassische MX-Bypass-Angriff.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Google Workspace
Ein korrekt konfigurierter Google-Workspace-MX-Record mit DNSSEC ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung). Google als EU/US-Auftragsverarbeiter (DSGVO Art. 28) liefert AVV und Data Residency Option für EU-Kunden — die Speicherung erfolgt für EU-Tenants in EU-Rechenzentren (Belgien, Niederlande, Deutschland-Frankfurt). Google Workspace Compliance-Center dokumentiert die TOM nach DSGVO Art. 32 inklusive Transport-Verschlüsselung (TLS 1.2/1.3), Verschlüsselung at-Rest (AES-256) und Multi-Region-Backup.
Google Workspace MX-Compliance-Stack: NIS2 lit. h (DNSSEC für MX, kundenseitig zu aktivieren) + BSI TR-03108 (MX-Redundanz Google-intern + FCrDNS Google-managed) + DSGVO Art. 32 lit. b (Verfügbarkeit Google-managed mit Data Residency). Wolf-Agents-USP: Der Email Security Check erkennt Google-MX-Pattern automatisch (Stack-Detection), unterscheidet Single-MX und Legacy-Setup, validiert DNSSEC am Apex und prüft auf parallele Records. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing über Legacy-aspmx-Subdomains.
Wie steht Ihre Domain bei MX-Infrastruktur · Google Workspace?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.