SPF, DKIM und DMARC in Google Workspace für den Kaltakquise-Versand einrichten
Google Workspace bringt für SPF, DKIM und DMARC eigene Admin-Konsolen-Bereiche mit, die sich in Details von einer reinen DNS-Einrichtung unterscheiden — wer die Schritte in der falschen Reihenfolge macht oder nur den DNS-Teil erledigt, bekommt trotzdem eine unvollständige Authentifizierung. Für B2B-Kaltakquise über ein Google-Workspace-Postfach ist das besonders relevant, weil Google selbst zu den strengsten Empfängerservern gehört, wenn es um unauthentifizierten Kaltversand geht.
- Google Workspace erledigt die DKIM-Schlüsselgenerierung über die Admin-Konsole, der SPF-Eintrag muss dagegen manuell ins DNS.
- Für Domains, die zusätzlich über ein Cold-Email-Tool oder CRM versenden, reicht Googles Standard-SPF-Include allein nicht — beide Quellen müssen in einem gemeinsamen Eintrag stehen.
- DKIM sollte in Google Workspace mit 2048-Bit-Schlüssel aktiviert werden, nicht mit dem älteren 1024-Bit-Default mancher Altkonten.
- Eine dedizierte Subdomain für Kaltakquise entkoppelt die Reputation des Vertriebs-Postfachs von der Hauptdomain, auch innerhalb von Google Workspace.
- Nach jeder Änderung an SPF oder DKIM sollte eine echte Testmail mit Header-Prüfung erfolgen, bevor der nächste Kampagnen-Batch startet.
Warum Google Workspace bei Cold-Sending-Domains besondere Sorgfalt verlangt
Google zählt zu den Empfängerservern, die unauthentifizierten oder schwach authentifizierten Versand am konsequentesten in den Spam-Ordner einsortieren oder gar nicht erst annehmen. Für ein Vertriebsteam, das Kaltakquise-Mails aus einem Google-Workspace-Postfach an Ansprechpartner in Unternehmen verschickt, potenziert sich das Risiko: Fehlt die saubere Authentifizierung, trifft es nicht nur Zustellungen an andere Google-Postfächer, sondern wirkt sich auch auf die generelle Absenderreputation der Domain bei anderen Providern aus.
Die Besonderheit bei Google Workspace ist, dass ein Teil der Einrichtung — insbesondere DKIM — über die Admin-Konsole läuft und nicht rein manuell im DNS erfolgt, während SPF weiterhin ein klassischer, von Hand gesetzter TXT-Eintrag bleibt. Wer das vermischt und etwa den DKIM-Schlüssel nicht aus der Admin-Konsole generiert, sondern einen alten Eintrag von einer anderen Quelle übernimmt, bekommt eine Signatur, die nicht zum tatsächlich genutzten Versanddienst passt.
Für Vertriebsteams kommt eine weitere Ebene hinzu: Google Workspace wird in der Praxis selten isoliert genutzt. Ein Postfach dient gleichzeitig für interne Kommunikation, Kundenkontakt und teils für den eigentlichen Kaltakquise-Versand über ein zusätzliches Tool. Jede dieser Nutzungen muss in derselben Authentifizierungsbasis abgebildet sein, sonst entsteht der Eindruck einer sauberen Einrichtung, während tatsächlich nur ein Teil des Versands wirklich authentifiziert ankommt.
Richtwerte aus der Praxis bei Vertriebsteams mit mehreren parallel genutzten Versandwegen, keine offizielle Google-Statistik.
SPF-Eintrag für Google Workspace im DNS setzen
Der Google-Workspace-eigene SPF-Baustein lautet include:_spf.google.com. Dieser Baustein deckt ausschließlich den Versand über Googles eigene Server ab — jedes zusätzliche Tool, über das im Namen derselben Domain versendet wird, muss als weiterer include in denselben Eintrag aufgenommen werden. Legen Sie dazu im DNS-Bereich Ihres Domain-Providers, nicht in der Google-Admin-Konsole, einen TXT-Eintrag auf Root- oder Subdomain-Ebene an.
Nutzt ein Vertriebsteam zusätzlich zu Google Workspace ein separates Cold-Email- oder CRM-Tool für den eigentlichen Kampagnenversand, gehört dessen Include-Domain oder IP-Bereich in denselben Eintrag. Ein häufiger Fehler ist, für das zweite Tool einen zweiten, separaten SPF-Eintrag anzulegen — DNS wertet aber nur den ersten gefundenen v=spf1-Eintrag aus, der zweite wird stillschweigend ignoriert und die zweite Versandquelle bleibt unautorisiert.
Beachten Sie außerdem das Limit von zehn erlaubten DNS-Lookups pro SPF-Prüfung, das jeder include-Baustein anteilig verbraucht. Bei Google Workspace allein ist das selten ein Problem, doch sobald mehrere Tools für unterschiedliche Zwecke — Kaltakquise, Support-Benachrichtigungen, Formular-Versand — jeweils einen eigenen Include benötigen, lohnt sich vor jeder Ergänzung eine kurze Kontrolle, wie viele Lookups der bestehende Eintrag bereits verbraucht.
v=spf1 include:_spf.google.com include:mail.cold-email-anbieter.de ~all — beide Versandwege in einer Zeile, mit ~all als moderatem Abschluss für die Startphase.
DKIM in der Google-Admin-Konsole aktivieren
Öffnen Sie in der Google-Admin-Konsole den Bereich Apps → Google Workspace → Gmail → DKIM authenticate email für die betreffende Domain. Wählen Sie dort explizit eine Schlüssellänge von 2048 Bit statt der älteren 1024-Bit-Option — 2048 Bit gilt inzwischen als Standard und wird von einigen Empfängerservern bei neuen Einrichtungen sogar vorausgesetzt.
Google generiert daraufhin einen CNAME-Eintrag mit einem Selector-Namen, meist im Muster google._domainkey, den Sie exakt wie angezeigt ins DNS übernehmen. Erst nach dem Setzen dieses Eintrags und einer kurzen Wartezeit für die DNS-Propagation lässt sich in der Admin-Konsole die Schaltfläche zum Aktivieren von DKIM anklicken — versucht man es vorher, meldet Google, dass der Eintrag noch nicht gefunden wurde.
Nach der Aktivierung signiert Google Workspace automatisch jede über seine Server versendete Nachricht. Wichtig: Versendet ein zusätzliches Cold-Email-Tool nicht über Googles SMTP-Relay, sondern über eigene Server, braucht dieses Tool eine eigene DKIM-Signatur mit eigenem Selector — Googles DKIM deckt nur tatsächlich über Google laufenden Versand ab.
Ein Punkt, der bei Altkonten gelegentlich auftaucht: Wurde DKIM bereits vor Jahren mit 1024 Bit eingerichtet und nie erneuert, lohnt sich eine Rotation auf 2048 Bit über denselben Menüpunkt. Google zeigt dafür einen neuen CNAME-Eintrag mit demselben oder einem neuen Selector an; der alte Eintrag sollte erst entfernt werden, nachdem der neue nachweislich aktiv ist, damit während der Umstellung keine Signaturlücke entsteht.
DMARC-Record ergänzen und Reihenfolge einhalten
DMARC wird unabhängig von der Google-Admin-Konsole direkt als TXT-Eintrag unter _dmarc.ihredomain.de im DNS gesetzt. Setzen Sie diesen Eintrag erst, nachdem SPF korrekt steht und DKIM in der Admin-Konsole erfolgreich aktiviert wurde — die Reihenfolge SPF, dann DKIM, dann DMARC verhindert, dass DMARC von Anfang an auf eine unvollständige Authentifizierungsbasis aufsetzt.
Für den Einstieg reicht eine Beobachtungs-Policy mit p=none, die lediglich Berichte an eine von Ihnen festgelegte Adresse sendet, ohne Zustellungen zu beeinflussen. Das ist besonders bei gemischten Versandwegen sinnvoll — etwa wenn ein Teil der Kommunikation über Google Workspace direkt läuft und ein anderer Teil über ein separates Cold-Email-Tool, das eventuell noch nicht vollständig authentifiziert ist.
Legen Sie den Eintrag direkt beim Domain-Provider an, nicht innerhalb der Google-Admin-Konsole, da diese für DMARC keine eigene Eingabemaske bereitstellt. Ein häufiger Anfängerfehler ist, den DMARC-Eintrag unter der falschen Ebene zu setzen, etwa direkt auf der Root-Domain, obwohl tatsächlich über eine Subdomain versendet wird — DMARC muss immer unter dem exakten _dmarc.-Präfix der jeweils versendenden Domain liegen.
Subdomain-Strategie auch innerhalb von Google Workspace
Auch bei Google Workspace lohnt sich eine dedizierte Subdomain für Kaltakquise, etwa outreach.musterfirma.de, während reguläre Geschäftsmails über die Hauptdomain laufen. Google Workspace unterstützt das Einrichten mehrerer Domains und Subdomains innerhalb eines Kontos über den Bereich Konto → Domains, wobei SPF, DKIM und DMARC für jede zusätzliche Domain separat konfiguriert werden müssen.
Für ein Team wie den Vertrieb der Bauer Maschinenbau AG bedeutet das: Das Postfach für Kundenbetreuung bleibt unter vertrieb@bauer-maschinenbau.de, während gezielte Kaltakquise-Kampagnen über ein eigenes Postfach auf einer separat authentifizierten Subdomain laufen — mit eigenem Aufwärmverlauf und eigener Reputation, unabhängig vom Hauptpostfach.
Einrichtung testen, bevor der erste Kampagnen-Batch läuft
Verschicken Sie nach Abschluss aller drei Schritte eine Testmail aus dem Google-Workspace-Postfach an ein externes Konto, dessen Original-Header Sie einsehen können. Im Authentication-Results-Header sollten spf=pass, dkim=pass mit dem korrekten Google-Selector und dmarc=pass stehen. Fehlt einer der drei Werte oder zeigt fail, lohnt sich der Blick zurück auf die Admin-Konsole — häufigste Ursache ist ein noch nicht aktivierter DKIM-Schlüssel oder ein SPF-Eintrag, der nur einen von mehreren genutzten Versandwegen abdeckt.
Prüfen Sie zusätzlich, ob eventuell parallel genutzte Cold-Email- oder CRM-Tools ihre eigene Authentifizierung korrekt einbinden, falls sie nicht über Googles Relay, sondern über eigene Infrastruktur versenden. Erst wenn beide Versandwege — Google Workspace direkt und das zusätzliche Tool — bei einer echten Testmail sauber durchlaufen, ist die Domain bereit für den ersten realen Kaltakquise-Batch.
Technische Einrichtung und rechtliche Anforderungen bleiben getrennt
Eine über Google Workspace sauber authentifizierte Domain sagt nichts darüber aus, ob der Versand einer konkreten Kaltakquise-Mail rechtlich zulässig ist. Für B2B-Kaltakquise in Deutschland bleibt die Grundlage eine Abwägung nach DSGVO sowie die Anforderungen aus § 7 UWG zu unerlaubter Werbung — unabhängig davon, wie sauber SPF, DKIM und DMARC stehen.
Praktisch heißt das: Auch eine technisch einwandfrei authentifizierte Google-Workspace-Domain schützt nicht vor einer Abmahnung, wenn Impressum, Abmeldemöglichkeit oder ein erkennbarer geschäftlicher Bezug in der Mail fehlen. Beide Baustellen — technische Zustellbarkeit und rechtliche Zulässigkeit — gehören vor dem ersten Kampagnenversand geprüft.
Häufige Fragen
Reicht der Standard-SPF-Eintrag include:_spf.google.com allein aus?
Nur, wenn ausschließlich über Google Workspace direkt versendet wird. Sobald ein zusätzliches Cold-Email- oder CRM-Tool im Namen derselben Domain verschickt, muss dessen Quelle in denselben SPF-Eintrag ergänzt werden.
Warum lässt sich DKIM in der Admin-Konsole nicht sofort aktivieren?
Google prüft beim Aktivieren, ob der zuvor angezeigte CNAME-Eintrag im DNS bereits auffindbar ist. Ist die Propagation noch nicht abgeschlossen, schlägt die Aktivierung fehl und muss nach einer Wartezeit wiederholt werden.
Kann ich mehrere Domains in einem Google-Workspace-Konto authentifizieren?
Ja, jede als sekundäre Domain oder Subdomain hinzugefügte Domain benötigt aber eigene SPF-, DKIM- und DMARC-Einträge. Eine automatische Übernahme von der Hauptdomain findet nicht statt.
Was passiert, wenn ich DMARC vor DKIM einrichte?
DMARC selbst lässt sich technisch jederzeit setzen, bewertet aber Nachrichten anhand des aktuellen SPF- und DKIM-Status. Ist DKIM noch nicht aktiv, bestehen Nachrichten die DMARC-Prüfung nur über SPF, was bei Weiterleitungen leicht kippt.
Wie erkenne ich, ob eine Testmail wirklich über Google Workspace signiert wurde?
Im Header-Quelltext der Testmail steht bei erfolgreicher DKIM-Signatur der Google-Selector, etwa dkim=pass header.i=@ihredomain.de header.s=google.
Möchten Sie das in Ihrem Outreach anwenden?
Wir zeigen Ihnen vor Projektstart, wie das für Ihr Segment und Produkt funktioniert.
Gespräch vereinbaren