Diese Anleitung betrifft eine eigene Domain in Google Workspace mit Gmail. Sie beschreibt weder Einstellungen eines privaten Gmail-Kontos noch die Einrichtung eines zusätzlichen Newsletter- oder Websiteversands.
Voraussetzungen und vorhandenen Stand prüfen
Sie benötigen die für diese Aufgabe von Google bezeichnete Superadministrator-Anmeldung sowie Zugriff auf die DNS-Verwaltung der betroffenen Domain. Der Menübereich setzt die Gmail-Einstellungsberechtigung voraus. Prüfen Sie zuerst, welche Domain und welcher Versandweg betroffen sind und ob bereits eine DKIM-Konfiguration arbeitet. Eine automatisch vorbereitete oder bestehende Einrichtung ist kein Anlass, sofort einen neuen Schlüssel zu erzeugen.
DNS kann bei einem anderen Dienst liegen als die Domainregistrierung oder Google Workspace. Bei mehreren Domains wählen Sie jede Domain ausdrücklich aus; deren Schlüsselwerte sind nicht austauschbar. Ein ausgehendes Gateway kann Nachrichten nach der Signierung verändern. Erfassen Sie solche Wege vor der Einrichtung, insbesondere angehängte Footer oder andere Inhaltsänderungen.
Die allgemeine Zuordnung von Signierer, Selektor und DNS erklärt DKIM allgemein einrichten. Die Grundlage für d=, s= und Signaturgrenzen finden Sie im DKIM-Kapitel.
1. Den Schlüssel für die richtige Domain erzeugen
Für eine neue Einrichtung führt der dokumentierte Weg in der Admin Console über Apps → Google Workspace → Gmail → E-Mail authentifizieren (Authenticate email). Wählen Sie die eigene Domain und anschließend Neuen Record generieren (Generate New Record). Oberflächenbezeichnungen können sich mit Sprache und Produktstand ändern.
Wählen Sie 2048 Bit, wenn die DNS-Verwaltung den erforderlichen vollständigen TXT-Wert unterstützt. Google bietet auch 1024 Bit an. Das ist vom DKIM-Standard zu unterscheiden: RFC 8301 schreibt für RSA-Schlüssel beim Signieren mindestens 1024 Bit vor und empfiehlt mindestens 2048 Bit. Ein vorhandener 1024-Bit-Schlüssel ist nicht allein wegen dieser Größe ungültig; für neue Schlüssel ist 2048 Bit der sinnvolle Ausgangspunkt.
Der Standardselektor lautet google. Ist dieser Name bereits durch eine weiter benötigte Konfiguration belegt, verwenden Sie nach Googles Anleitung ein anderes Präfix. Notieren Sie den tatsächlich gewählten Wert. Die spätere DNS-Abfrage muss dazu passen; google ist keine zwingende Universalvorgabe.
Nach Generieren zeigt Google den DNS-Hostnamen und den TXT-Wert an. Kopieren Sie beide vollständig. Google verwaltet den privaten Schlüssel; Sie müssen für diesen Ablauf keinen privaten Schlüssel erzeugen oder hochladen. Klicken Sie noch nicht auf Authentifizierung starten.
Die Abfolge und die Schlüsselauswahl sind in Googles DKIM-Einrichtung, Schritt 1 dokumentiert.
2. Den vollständigen TXT-Record veröffentlichen
Öffnen Sie die aktive DNS-Zone dieser Domain. Übernehmen Sie die Werte aus der Admin Console in die passenden Felder Ihrer DNS-Verwaltung:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| DNS-Feld | Was Sie übernehmen |
|---|---|
| Typ | TXT |
| Name / Host | Den angezeigten Recordnamen, passend zur Eingabeweise der DNS-Verwaltung. Beim Standardselektor ist der relative Name google._domainkey. |
| Wert | Den vollständigen von Google bereitgestellten TXT-Wert, einschließlich Tags und öffentlichem Schlüssel. |
| TTL | Einen zum eigenen DNS-Betrieb passenden Wert; daraus folgt keine garantierte Aktivierungszeit. |
Bei example.com und dem Standardselektor wäre der vollständige Name google._domainkey.example.com. Prüfen Sie, ob die Oberfläche example.com selbst ergänzt. Ein doppelt angehängter Domainsuffix erzeugt einen anderen Namen.
Dieses Beispiel zeigt nur die Form. PUBLIC_KEY_BASE64 ist ein Platzhalter und kein verwendbarer Schlüssel:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"Kürzen Sie den echten Schlüssel nicht. Lange Werte können als mehrere Zeichenketten innerhalb eines TXT-Records dargestellt werden. Die 255-Oktett-Grenze gilt je Zeichenkette. Mehrere getrennte TXT-Records unter demselben Selektor sind keine zulässige Aufteilung des Schlüssels. Die Eingabeweise hängt vom DNS-Anbieter ab; prüfen Sie dessen Vorgaben, bevor Sie wegen eines Oberflächenlimits die Schlüssellänge reduzieren. Google: Fehlerhilfe, RFC 6376, Abschnitt 3.6.2.2.
Für jede weitere Workspace-Domain rufen Sie deren eigene Werte in der Admin Console ab. Ein Record für die Hauptdomain richtet nicht automatisch eine andere Domain oder einen separaten Versanddienst ein.
3. DNS kontrollieren, Authentifizierung starten und Nachricht prüfen
Den veröffentlichten Record kontrollieren
Ersetzen Sie Beispielname und gegebenenfalls Selektor durch Ihre tatsächlichen Werte. Auf einem System mit dig:
dig TXT google._domainkey.example.com +shortUnter Windows mit dem DnsClient-Modul:
Resolve-DnsName -Name google._domainkey.example.com -Type TXT -DnsOnlyVergleichen Sie den vollständigen öffentlichen Wert mit der Admin Console. Die Befehle lesen DNS; sie aktivieren DKIM nicht und prüfen keine Nachricht. Bei leerer oder unklarer Kurzantwort lesen Sie die vollständige DNS-Ausgabe, etwa ohne +short, statt einen fehlenden Schlüssel als bewiesen anzunehmen. DNS-Fehler, Cachezustand und ein falscher Abfragename sind getrennte Möglichkeiten.
Die Aktivierung gesondert kontrollieren
Kehren Sie nach veröffentlichter, passender DNS-Konfiguration zu E-Mail authentifizieren für dieselbe Domain zurück und wählen Sie Authentifizierung starten (Start authentication). Google nennt bei funktionierender Einrichtung den Status Authenticating email with DKIM. Das ist ein Verwaltungsstatus; der Empfangsbefund einer konkreten Nachricht folgt erst danach.
Google weist darauf hin, dass DKIM nach Hinzufügen des Schlüssels bis zu 48 Stunden benötigen kann, bis es funktioniert. Auch der Hinweis, DNS-Records zu aktualisieren, kann laut Google bis zu 48 Stunden weiter erscheinen. Daraus folgt weder eine Pflicht, nach jedem Aktivierungsklick genau 48 Stunden zu warten, noch ein garantierter Abschluss danach. Ein fehlender Aktivierungsschritt oder falscher Record wird durch Warten nicht richtig. Google: Einrichtung.
Eine Nachricht auf dem tatsächlichen Versandweg prüfen
Verwenden Sie eine eigene Nachricht, die über den untersuchten Workspace-Versand an einen gesonderten, von Ihnen berechtigt genutzten Empfang geht. Google empfiehlt für seine Verifikation einen anderen Gmail-/Workspace-Empfänger und schließt die Selbstnachricht als ausreichenden Test aus. Öffnen Sie dort die Originalheader; in Gmail ist dies Original anzeigen (Show original).
Ordnen Sie die erwartete Signatur anhand von d= und s= zu. Lesen Sie anschließend das dazugehörige DKIM-Ergebnis des vertrauenswürdigen Empfängers in Authentication-Results. Ein vorhandener DNS-Schlüssel, eine sichtbare Signatur und dkim=pass beantworten drei unterschiedliche Fragen. Das Ergebnis gilt für die untersuchte Nachricht und den beobachteten Weg. Eine andere From-Adresse, ein anderes Versandprogramm oder ein Gateway kann einen anderen Weg betreffen.
Die Einordnung von Headerbefunden erklärt die Belegwahl. Erfolgreiches DKIM bedeutet noch nicht DMARC-Alignment mit der sichtbaren From-Domain; dafür folgt der DMARC-Abgleich. Auch ein Pass verspricht keine Inboxplatzierung und keinen harmlosen Inhalt. DMARC kann über erfolgreiches ausgerichtetes SPF oder DKIM bestehen. Eine veröffentlichte DMARC-Policy garantiert weder Ablehnung noch Zustellung oder vollständige Phishingabwehr.
Typische Abzweige bei fehlender oder ungültiger Signatur
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Beobachtung | Was Sie als Nächstes prüfen |
|---|---|
google._domainkey liefert keinen passenden Wert | Tatsächlich gewählten Selektor, ausgewählte Domain, aktive Zone und vollständigen Recordnamen abgleichen. default ist nur falsch, wenn der Signierer einen anderen Namen verwendet. |
| Record sichtbar, Status noch nicht authentifizierend | Prüfen, ob Authentifizierung starten für dieselbe Domain ausgeführt wurde. Hinweise auf DNS-Veröffentlichung und Zeitbedarf im richtigen Kontext lesen. |
| Erwartete Signatur fehlt an der Nachricht | Tatsächlichen Workspace-Versandweg, Aktivierung und gewählten Prüfempfänger klären. Eine einzelne Nachricht beweist nicht, dass sämtliche Domainmails unsigniert sind. |
Signatur vorhanden, Empfänger meldet fail | Schlüssel/Selektor und genaue Empfängerdiagnose prüfen; Änderungen durch Footer, Gateway oder Weiterleitung sind mögliche Ursachen, keine aus fail allein bewiesene Diagnose. |
| 2048-Bit-Wert wird von der DNS-Oberfläche abgewiesen | Vollständigen Wert und unterstützte Mehrfachzeichenketten prüfen; keine Kürzung und keine separaten Schlüssel-TXT-Records anlegen. |
| Workspace-Nachricht besteht die DKIM-Prüfung, Newsletter-Nachricht nicht | Den zusätzlichen Dienst separat einrichten und dessen eigene Nachricht prüfen. Der Workspace-Schlüssel konfiguriert diesen Dienst nicht. |
Die offizielle Google-Fehlerhilfe führt durch Verwaltungsstatus, TXT-Werte und Nachrichtenprüfung. Für die genaue Einordnung eines Fehlers braucht es diese Belege, keine vermutete allgemeine Häufigkeitsrangliste.
Einen Schlüsselwechsel vorbereiten
Bei einem bestehenden DKIM-Betrieb ist ein neuer Schlüssel eine Änderung am Versandweg. Notieren Sie vorab Domain, bisherigen Selektor, DNS-Wert und den tatsächlichen Zustand. Verwenden Sie für einen geplanten neuen Schlüssel einen noch nicht belegten Selektor nach Googles Verfahren, statt den weiter benötigten alten DNS-Wert einfach zu überschreiben.
Prüfen Sie vor dem Eingriff die dann aktuelle Google-Anleitung und den Zustand Ihrer Domain. Das Erzeugen eines neuen Records, seine Veröffentlichung und die Verwendung durch den Signierer sind separate Schritte. Diese Anleitung belegt keine unterbrechungsfreie Workspace-Rotation. Nach dem Wechsel prüfen Sie eine neue Nachricht auf s=, d= und das Empfängerergebnis. Erhalten Sie ältere öffentliche Schlüssel so lange, wie sie für noch relevante Nachrichten benötigt werden; DNS-Caches und Nachrichtenlaufzeiten ergeben keine universelle Löschfrist.
Bei einem vermuteten Schlüsselvorfall gilt ein gesonderter Reaktionsplan. Die allgemeine DKIM-Rotation erklärt die Abwägung; hier wird kein automatischer Rotationsdienst zugesagt.
Den passenden Wolf-Prüfweg wählen
Für den veröffentlichten DNS-Stand nutzen Sie den E-Mail-Security-Check mit dem tatsächlich verwendeten Selektor. Er untersucht öffentlich auffindbare Schlüssel innerhalb seines begrenzten Umfangs. Ein fehlender Fund beweist nicht, dass DKIM fehlt; ein Fund beweist keine aktive Signierung. Der DNS-Check liest keine Nachrichten und überwacht spätere Änderungen nicht automatisch.
Für eine neue eigene Nachricht ist die kostenlose DE-Testmail-Beta im begrenzten Startprofil über den E-Mailcheck verfügbar. Prüfen Sie die dortigen Voraussetzungen. Der private Testmailbefund und der Domainbefund bleiben getrennt. Ein vollständiger englischer Funktionsweg ist derzeit nicht freigegeben.
Brauchen Sie nach einer Änderung eine Arbeitsunterlage, erklärt die Reportübersicht den jeweiligen dokumentierten Umfang. Halten Sie Domain, Selektor, Zeitpunkt, beobachteten Versandweg und offene Fragen auseinander. Ein DNS- oder Testmailbefund ist kein umfassender Audit-, Zustell- oder Compliance-Nachweis; ein Kaufweg wird hier nicht angeboten.
Häufige Fragen
Muss der Selektor immer google heißen?
Nein. Das ist das von Google empfohlene Standardpräfix. Bei einem bereits belegten Namen sieht Google ein anderes Präfix vor. Entscheidend sind die übereinstimmenden Werte in Admin Console, DNS und tatsächlich erzeugter Signatur.
Kann ich den TXT-Wert einer anderen Domain verwenden?
Nein. Holen Sie für jede einzurichtende Domain deren eigene Werte aus der Admin Console. Eine bloße Namensänderung an einem fremden Beispielschlüssel richtet die Domain nicht ein.
Warum kommt meine Nachricht trotz dkim=pass im Spam an?
DKIM bewertet eine Signatur. Empfänger berücksichtigen weitere Signale für Annahme und Einordnung. Der Pass allein erklärt weder die Inboxentscheidung noch schließt er andere Probleme aus.
Weiterführende Anleitungen
DKIM-Grundlagen, allgemeine DKIM-Einrichtung, SPF und DMARC-Alignment verstehen ergänzen diese Aufgabe.
Weitere DKIM-Anleitung: Microsoft 365
Quellen und Prüfgrenzen
Google: DKIM einrichten, Google: DKIM-Probleme untersuchen, RFC 6376, RFC 8301, Resolve-DnsName.
Primärquellenprüfung am 29. September 2026; Googles Einrichtungsseite nennt den 24. September 2026 als Aktualisierungsdatum. Kein Workspace-Konto geöffnet, kein Record geändert und keine Nachricht oder Rotation bei Google praktisch geprüft. Die lokalen Signaturproben der allgemeinen DKIM-Anleitung belegen keine Google-Aktivierung oder Zustellung. Die Anbieterbefehle und das schematische DNS-Beispiel wurden hier nicht ausgeführt; Werte und Bedienoberfläche müssen zur konkreten Umgebung passen.