DKIM in Google Workspace aktivieren: die Schritt-für-Schritt-Anleitung

Von Thomas · virtueller CISO · 2026-07-27

Eine an Google Workspace angebundene Domain versendet vom ersten Tag an DKIM-signierte Post — nur nicht im eigenen Namen. Solange kein Schlüssel in der Admin-Konsole aktiviert wurde, signiert Gmail ausgehende Nachrichten mit einem Standardschlüssel, der an eine technische Google-Domain der Form beispiel-de.20230601.gappssmtp.com gebunden ist. Die Signatur ist kryptografisch gültig, besteht die DKIM-Prüfung beim Empfänger — und bringt DMARC exakt nichts, weil die signierende Domain nicht die aus dem From-Header ist. DKIM auf der eigenen Domain zu aktivieren ist deshalb keine Komfortoption: Es ist der Schritt, der die Signatur für die Authentifizierung überhaupt erst zählen lässt.

Die gute Nachricht: Bei Google passt die ganze Operation in drei Schritte — einen Schlüssel in der Admin-Konsole erzeugen, einen TXT-Eintrag in der DNS-Zone veröffentlichen, die Authentifizierung starten. Die weniger gute: Jeder Schritt birgt eine Feinheit, an der hastige Einrichtungen scheitern — Schlüssellänge, DNS-Propagation, eine zu frisch hinzugefügte Domain, vergessene Alias-Domains.

Diese Anleitung beschreibt den vollständigen Ablauf, von der Admin-Konsole bis zur Kontrolle der Header, und anschließend, was die Aktivierung konkret für das DMARC-Alignment ändert. Die SPF-Seite von Google Workspace ist bereits in dem SPF-Leitfaden für Microsoft 365 und Google Workspace behandelt; daran ändert DKIM nichts, eine Wiederholung erübrigt sich.

Warum DKIM standardmäßig inaktiv bleibt

Der Grund ist struktureller, nicht kommerzieller Natur. DKIM beruht auf einem Schlüsselpaar: Der private Schlüssel signiert die Nachrichten auf der Versandseite, der öffentliche wird im DNS der signierenden Domain veröffentlicht, damit Empfänger die Signatur prüfen können. Auf die DNS-Zonen seiner Kunden hat Google aber keinen Zugriff — dort kann es nichts veröffentlichen. Standardmäßig signiert Gmail deshalb mit der einzigen Domain, die es kontrolliert: einer aus dem Kundennamen abgeleiteten Subdomain von gappssmtp.com.

Konkret trägt eine ohne aktiviertes DKIM von buchhaltung@beispiel.de versandte Nachricht eine Signatur mit d=beispiel-de.20230601.gappssmtp.com. Die DKIM-Prüfung zeigt pass: Die Signatur ist intakt, der öffentliche Schlüssel antwortet. DMARC verlangt jedoch mehr — das Alignment, also die Übereinstimmung zwischen signierender Domain (d=) und From-Domain. gappssmtp.com hat mit beispiel.de nichts zu tun: Das Alignment scheitert, und DMARC ignoriert diese Signatur schlicht und ergreifend.

Die Folge: Eine Google-Workspace-Domain ohne eigenes DKIM stützt DMARC allein auf SPF. Für direkte Flüsse funktioniert das, doch SPF zerbricht an der ersten Weiterleitung; sobald die Policy auf p=quarantine oder p=reject steigt, landen weitergeleitete Nachrichten im Spam. Genau dieses Szenario verhindert die DKIM-Aktivierung — und genau deshalb verträgt sie keinen Aufschub.

Der Weg durch die Admin-Konsole

Die Operation verlangt ein Super-Administrator-Konto auf admin.google.com. Der Pfad: Hauptmenü, dann Apps → Google Workspace → Gmail, und auf der Gmail-Seite der Abschnitt „E-Mails authentifizieren“. Nur dort wird der Schlüssel erzeugt — auf DNS-Seite passiert nichts, solange diese Seite nicht besucht wurde.

Der Abschnitt zeigt ein Auswahlmenü mit allen Domains der Organisation: der primären Domain, den sekundären, den Aliassen. Auch der aktuelle Status erscheint dort — der Hinweis auf die Standarddomain steht genau für die oben beschriebene gappssmtp.com-Signatur. Nach Auswahl der betroffenen Domain öffnet die Schaltfläche „Neuen Eintrag generieren“ den Dialog zur Schlüsselerzeugung, mit zwei Parametern.

Der erste ist die Schlüssellänge, 1024 oder 2048 Bit — der nächste Abschnitt entscheidet diese Frage. Der zweite ist das Selektor-Präfix, standardmäßig google. Dieses Präfix wird zum veröffentlichten Namen vor ._domainkey; es zu ändern lohnt nur, wenn ein Eintrag google._domainkey die Zone bereits belegt, als Überbleibsel einer früheren Einrichtung. Was dieses Etikett genau leistet — und wie Empfänger damit den Schlüssel auffinden —, steht in dem Artikel über die Rolle des Selektors.

Die Schlüssellänge: 2048 Bit, außer die Zone sperrt sich

Die Vorauswahl lautet 2048 Bit, und sie ist richtig. Ein RSA-Schlüssel mit 1024 Bit gilt in den kryptografischen Referenzwerken seit Jahren als zu kurz; die großen Anbieter akzeptieren 1024-Bit-Signaturen zwar noch, aber nichts rechtfertigt es, 2026 einen schwachen Schlüssel neu zu erzeugen. Google selbst schlägt 2048 vor.

Der einzige echte Grund zum Herabstufen ist mechanischer Natur: Ein öffentlicher 2048-Bit-Schlüssel ergibt einen Wert von rund 400 Zeichen, jenseits der Grenze von 255 Zeichen pro Zeichenkette eines TXT-Eintrags. Der DNS-Standard löst das Problem — ein TXT-Eintrag akzeptiert mehrere aneinandergehängte Zeichenketten —, und die meisten modernen Oberflächen teilen den Wert automatisch auf. Einige ältere Panels verweigern jedoch die lange Eingabe. Dann gibt es zwei Auswege: den Wert von Hand in zwei Zeichenketten in Anführungszeichen aufteilen oder, als letztes Mittel, einen 1024-Bit-Schlüssel erzeugen. Die vollständige Abwägung — Stärke, Kompatibilität, Rotation — steht in dem Vergleich der Schlüssel mit 1024 und 2048 Bit. Der gesunde Reflex: zuerst 2048 versuchen und erst nach nachgewiesener Weigerung der Zone herabstufen.

Der TXT-Eintrag google._domainkey und der Start der Authentifizierung

Der Dialog zeigt zwei Werte, die in die DNS-Zone zu übertragen sind: den Hostnamen google._domainkey und den TXT-Wert, der mit v=DKIM1; k=rsa; p= beginnt. Veröffentlicht sieht der Eintrag so aus:

google._domainkey.beispiel.de.  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" )

Zwei Vorsichtsmaßnahmen bei der Eingabe. Zuerst der Hostname: Je nach DNS-Oberfläche erwartet das Feld entweder nur google._domainkey (die Oberfläche ergänzt die Domain) oder den vollen Namen google._domainkey.beispiel.de — der klassische Fehler erzeugt google._domainkey.beispiel.de.beispiel.de, den nie ein Prüfer abfragen wird. Dann der Wert: Der Schlüssel muss vollständig kopiert werden, ohne Streuleerzeichen und ohne Kürzung; ein um ein einziges Zeichen verstümmelter Schlüssel erzeugt unprüfbare Signaturen — schlimmer als gar keine. Ein kurzes dig TXT google._domainkey.beispiel.de zeigt, was die Welt tatsächlich sieht.

Steht der Eintrag, zurück in die Konsole: Die Schaltfläche „Authentifizierung starten“ lässt Google die Präsenz des Schlüssels prüfen und stellt die Signatur ausgehender Nachrichten auf d=beispiel.de mit dem Selektor google um. Scheitert die Prüfung, ist fast immer die Propagation schuld: Je nach TTL und Resolvern braucht der Schlüssel von wenigen Minuten bis zu 48 Stunden, um überall sichtbar zu sein. Der Fehler ist nicht endgültig — die Schaltfläche lässt sich später erneut betätigen. Sobald die Authentifizierung läuft, werden die folgenden Nachrichten sofort signiert; die bereits versandten behalten selbstverständlich die alte Signatur.

Die Prüfung: DKIM-Signature und s=google

Der Beweis steht in den Headern. Der einfachste Test: eine Nachricht von der Domain an ein externes Postfach senden — eine private Gmail-Adresse genügt — und dann in Gmail „Original anzeigen“ öffnen. Die Seite fasst die drei Urteile zusammen (SPF, DKIM, DMARC) und zeigt den vollständigen Header.

Zwei Zeilen zählen. Die erste, DKIM-Signature, muss das richtige Paar aus Domain und Selektor tragen:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=beispiel.de; s=google; h=from:to:subject:date; …

d=beispiel.de und s=google: Die Signatur verpflichtet nun die Domain selbst. Die zweite, Authentication-Results, muss dkim=pass header.i=@beispiel.de zeigen. Nennt das d= weiterhin gappssmtp.com, ist die Authentifizierung nicht wirklich gestartet — oder die Nachricht ging vor der Umstellung hinaus.

Im großen Maßstab kommt die Bestätigung aus den aggregierten DMARC-Berichten: Binnen weniger Tage sollte das von Googles IPs versandte Volumen als DKIM-aligned erscheinen. Eine wichtige Nuance: dkim=pass allein sagt nichts über das Alignment — auch eine intakte gappssmtp.com-Signatur zeigt pass. Den Unterschied macht die Übereinstimmung zwischen dem d= und der From-Domain, und genau die messen die Berichte.

Was die Aktivierung für das DMARC-Alignment ändert

DMARC lässt eine Nachricht passieren, wenn mindestens einer der beiden Mechanismen besteht und aligned ist: SPF gegen die Return-Path-Domain, DKIM gegen die d=-Domain. Auf einer Google-Workspace-Domain ist SPF für den Direktversand meist schon vorhanden und aligned. Die DKIM-Aktivierung ist deshalb nicht redundant: Hinzu kommt das Standbein, das dort überlebt, wo SPF umfällt.

Der entscheidende Fall ist die Weiterleitung. Eine automatisch weitergeleitete Nachricht — ein Weiterleitungspostfach, die Adresse eines früheren Mitarbeiters, eine interne Liste — erreicht den Endempfänger von der IP des weiterleitenden Servers, nicht von Google: SPF scheitert. Die DKIM-Signatur dagegen reist in der Nachricht mit und bleibt prüfbar, solange der signierte Inhalt unangetastet ist. Mit aligned DKIM bestehen diese weitergeleiteten Flüsse DMARC weiterhin; ohne es werden sie in dem Moment zu falschen Positiven, in dem die Policy härter wird.

Deshalb ist die DKIM-Aktivierung faktisch die Voraussetzung für den Übergang zu p=quarantine und dann p=reject: Aus Berichten voller mehrdeutiger Fehlschläge wird eine saubere Basis, in der die verbleibenden Fehlschläge die verdächtigen sind. Die Policy-Stufen und ihre genaue Syntax — p=, rua=, striktes oder gelockertes Alignment über adkim= — werden in den kommentierten DMARC-Eintragsbeispielen durchgespielt, dem natürlichen nächsten Halt, sobald die Signatur steht.

Die Fallstricke: frische Domain, Aliasse, mehrere Domains

Die frisch hinzugefügte Domain. Auf einer gerade erst an Google Workspace angebundenen Domain kann die Schlüsselerzeugung mehrere Stunden lang nicht verfügbar sein, und der Start der Authentifizierung kann scheitern, obwohl der TXT-Eintrag korrekt veröffentlicht ist. Googles eigene Dokumentation nennt eine Frist von bis zu 72 Stunden, nachdem Gmail auf der Domain aktiv geworden ist. Das Symptom — eine wirkungslose Schaltfläche, ein hartnäckiger Fehler — kuriert Geduld, nicht das hektische Neuerzeugen von Schlüsseln.

Die Alias-Domains. Jeder Alias versendet Post unter eigenem Namen, und das DKIM-Alignment wird Alias für Alias beurteilt. Der Schlüssel der Hauptdomain deckt einen Alias nicht ab: Der Alias muss im Auswahlmenü selektiert, mit einem eigenen Schlüssel versehen, in seiner Zone veröffentlicht und eigens gestartet werden. Ein vergessener Alias signiert weiter als gappssmtp.com — und seine Nachrichten scheitern am Tag der Verschärfung am Alignment.

Mehrere Domains. Dieselbe Logik: Die Prozedur wiederholt sich Domain für Domain. Der Selektor google darf in jeder Zone erneut verwendet werden — ein Selektor ist lokal zu seiner Zone. Die aggregierten Berichte bleiben der beste Detektor für eine vergessene Domain.

Die Drittversender. Der in der Konsole erzeugte Schlüssel signiert nur, was Gmail verlässt. Eine E-Mail-Plattform — Mailchimp, Brevo, SendGrid — signiert mit eigenen Schlüsseln, die dort konfiguriert werden. Und auf Microsoft-Seite unterscheidet sich die Mechanik deutlich (zwei CNAME-Einträge, Selektoren selector1/selector2): die entsprechende Anleitung für Microsoft 365 deckt dieses Terrain ab.

Die Schlüsselrotation. Eine spätere Rotation folgt derselben Sequenz — erzeugen, veröffentlichen, neu starten —, wobei der alte öffentliche Schlüssel noch einige Tage publiziert bleibt, damit unterwegs befindliche Nachrichten prüfbar bleiben.

Fazit

Standardmäßig signiert Google Workspace DKIM mit einer technischen gappssmtp.com-Domain, die für DMARC wertlos ist. Die Aktivierung auf der eigenen Domain folgt einem kurzen Pfad: Admin-Konsole (Apps → Google Workspace → Gmail → E-Mails authentifizieren), Erzeugung eines 2048-Bit-Schlüssels, Veröffentlichung des TXT-Eintrags google._domainkey, Start der Authentifizierung, Kontrolle der Header (d= auf der Domain, s=google). Die Operation wiederholt sich für jede Domain und jeden Alias und deckt nur den Gmail-Verkehr ab — Drittplattformen signieren separat. Der Gewinn ist greifbar: ein Authentifizierungs-Standbein, das Weiterleitungen überlebt und den Übergang zu p=reject realistisch macht.

Bleibt, den Ist-Zustand zu messen: Eine kostenlose DMARC-Analyse der Domain zeigt binnen Sekunden, ob der Google-Workspace-Verkehr aligned hinausgeht — und was noch fehlt. Um den Fortschritt in den Berichten zu verfolgen und die Policy im richtigen Tempo zu verschärfen, genügen für die Eröffnung eines Kontos wenige Minuten; die Signatur ihrerseits ist dann bereits an Ort und Stelle.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos