Solange du nicht in der Admin-Konsole einen Schlüssel erzeugst und auf Authentifizierung starten klickst, trägt keine DKIM-Signatur deine eigene Domain. DMARC hat auf der DKIM-Seite nichts, womit es sich ausrichten könnte, und muss allein über SPF bestehen. Dieser Leitfaden zeigt, warum DKIM ab Werk aus ist, wie du mit genau einem SPF-Eintrag auskommst, was Gmail von dir als Massenversender verlangt, wann smtp.gmail.com der falsche Weg ist und wie du das Ergebnis an einem echten Versand mit Unspam prüfst.
Google Workspace erzeugt im Normalfall keinen DKIM-Schlüssel für deine Domain, und Google dokumentiert dazu nur zwei Ausnahmen: Ist Squarespace dein Domain-Anbieter, wird der Schlüssel automatisch erzeugt und deinen DNS-Einträgen hinzugefügt. Und du musst DKIM womöglich gar nicht einrichten, wenn deine Domain es bereits standardmäßig mitbringt oder du sie bei der Anmeldung über einen Google-Partner gekauft hast.
Für eine Domain, die ausschließlich über Workspace versendet, veröffentlicht Google genau einen Wert: v=spf1 include:_spf.google.com ~all, als TXT-Eintrag auf der Root-Domain mit @ im Hostfeld. Zwei Dinge machen das kaputt. Ein zweiter SPF-Eintrag auf demselben Namen ist ein permanenter Fehler, und dann wird keiner von beiden verwendet, genau das passiert beim dritten Tool, das dich auffordert, diesen TXT-Eintrag anzulegen. Und Google dokumentiert eine Obergrenze von zehn include:-Tags, die ein Helpdesk, eine Rechnungs-App und eine Marketing-Plattform schneller erreichen, als irgendwer erwartet.
Googles Absenderrichtlinien behandeln dich als Massenversender, sobald du mehr als 5.000 Nachrichten pro Tag an private Gmail-Konten schickst, gezählt je primärer Domain. Googles eigenes Beispiel sind 2.500 von solarmora.com plus 2.500 von promotions.solarmora.com, die zusammen die Grenze reißen. Massenversender müssen DMARC veröffentlichen, die Policy darf dabei p=none sein, und die From-Domain muss sich entweder mit der SPF-Domain oder mit der DKIM-Domain ausrichten. Google schreibt außerdem, dass der Status als Massenversender kein Ablaufdatum hat und dass Post, die die Anforderungen nicht erfüllt, im Spam-Ordner landet oder mit dem Fehler 5.7.26 abgewiesen wird.
Konten im Testzeitraum sind auf 500 Nachrichten und 500 eindeutige externe Empfänger pro Tag begrenzt. Ein bezahltes Konto steigt auf 2.000 Nachrichten pro Tag, deckelt aber zugleich bei 3.000 externen Empfängern und 2.000 eindeutigen externen Empfängern, und über SMTP, POP oder IMAP verschickte Nachrichten nehmen höchstens 100 Empfänger je Nachricht. Die Zähler laufen über ein gleitendes 24-Stunden-Fenster und nicht über den Kalendertag, es setzt also um Mitternacht nichts zurück und ein Versand, der gut angelaufen ist, bricht mittendrin ab.
Bei smtp.gmail.com authentifizierst du dich mit der eigenen Adresse eines Kontos plus einem App-Passwort, und Google deckelt diesen Weg bei 2.000 Nachrichten pro Tag. Das ist damit ein Weg für ein Postfach und keiner für eine Anwendung.
DKIM signiert einen Hash des Nachrichtentexts, jede Änderung nach dem Signieren macht die Signatur also ungültig, und der Empfänger protokolliert im Authentication-Results-Header „body hash did not verify“. Googles Seite zur DKIM-Fehlerbehebung nennt als übliche Ursache ausgehende Gateways, speziell solche, die jeder ausgehenden Nachricht eine Fußzeile anhängen, und sagt dir, du sollst sicherstellen, dass das Gateway ausgehende Nachrichten nicht verändert. Dieselbe Seite weist darauf hin, dass Gmail nur die ersten fünf DKIM-Signaturen einer Nachricht auswertet, eine gültige Signatur an sechster Stelle im Stapel also nie geprüft wird.
Google schreibt keine DNS-Einträge für dich. Jeder Eintrag hier unten liegt bei deinem Domain-Anbieter, die Admin-Konsole erzeugt nur die Werte und prüft sie hinterher. SPF und DKIM kommen zuerst, und danach bittet dich Google, 48 Stunden zu warten, bevor du DMARC ergänzt. Die gesamte DKIM-Arbeit passiert unter Apps > Google Workspace > Gmail > E-Mail authentifizieren, und du musst als Super Admin angemeldet sein.
| Eintrag | Standard | das Problem | die Lösung |
|---|---|---|---|
| SPF | Es ist nichts veröffentlicht, außer du hast es selbst veröffentlicht. Googles MX-Einträge hinzuzufügen legt keinen SPF-Eintrag an. | Ohne Eintrag gibt es kein SPF pass, mit dem sich etwas ausrichten ließe. Liegen zwei Einträge auf demselben Namen, wird keiner von beiden verwendet. Jenseits von zehn include:-Tags bricht die Auswertung ab, und alle Absender scheitern auf einen Schlag. | Veröffentliche einen einzigen TXT-Eintrag auf der Root-Domain, Hostfeld @, Wert v=spf1 include:_spf.google.com ~all. Nimm jeden weiteren Absender in genau diesen Eintrag auf, statt einen zweiten anzulegen. Google empfiehlt ~all statt -all und weist darauf hin, dass SPF-Änderungen bis zu 48 Stunden brauchen können, bis sie wirken. |
| DKIM | Bei den meisten Domains aus. Google nennt zwei Ausnahmen: Bei einer bei Squarespace gehosteten Domain wird der Schlüssel automatisch erzeugt und eingetragen, und eine Domain, die DKIM bereits standardmäßig mitbringt oder bei der Anmeldung über einen Google-Partner gekauft wurde, braucht womöglich gar keine Einrichtung. Überall sonst musst du nach dem Aktivieren von Gmail 24 bis 72 Stunden warten, bis die Admin-Konsole überhaupt einen Schlüssel erzeugt, und bis du fertig bist, steht auf der Seite E-Mail authentifizieren, dass du die DNS-Einträge für diese Domain aktualisieren musst. | Ohne eigenen Schlüssel gibt es keine Signatur, die deine Domain trägt, DMARC muss also allein über SPF bestehen. Das hält bis zur ersten Weiterleitung oder Mailingliste, die SPF bricht und das DMARC-Ergebnis gleich mitnimmt. | Wähl unter Apps > Google Workspace > Gmail > E-Mail authentifizieren die Domain aus, behalte das voreingestellte Präfix google als Selektor, nimm die Schlüssellänge 2048 Bit, wenn dein DNS-Anbieter sie unterstützt, veröffentliche den TXT-Eintrag auf google._domainkey und klick dann dort auf Authentifizierung starten. Der Status wechselt auf E-Mail wird mit DKIM authentifiziert, sobald Google den Eintrag verifiziert hat. |
| DMARC | Nicht veröffentlicht, und Google veröffentlicht ihn auch nie für dich. | Gmail verlangt von Massenversendern einen DMARC-Eintrag, und Google sagt dir, du sollst nach dem Einrichten von SPF oder DKIM 48 Stunden warten, bevor du einen anlegst, damit du keine Policy gegen eine Authentifizierung durchsetzt, die noch gar nicht propagiert ist. | Veröffentliche einen TXT-Eintrag auf _dmarc.yourdomain.com, beginnend mit v=DMARC1; p=none und einer rua-Adresse, lies die aggregierten Berichte und zieh dann auf p=quarantine und p=reject an. Richte rua auf eine eigene Gruppe oder ein eigenes Postfach: Google warnt, dass große Organisationen Hunderte oder Tausende Berichte pro Tag bekommen können. |
| Additional domains | Die Seite E-Mail authentifizieren hat ein Menü Ausgewählte Domain mit allen Domains deines Kontos, und jede startet ohne eigenen Schlüssel. | Teams erzeugen einen Schlüssel für die primäre Domain, versenden dann aber von einer zweiten Domain, die keinen hat, und jede Nachricht von dort scheitert am DKIM-Alignment, während die primäre Domain tadellos aussieht. | Googles Anweisung ist eindeutig: Richtest du DKIM für mehr als eine Domain ein, führ die Schritte für jede Domain durch und hol dir für jede einen eigenen DKIM-Schlüssel aus der Admin-Konsole. Veröffentliche google._domainkey unter jeder Domain, von der du versendest, nicht nur unter der primären. |
Wenn du diese Einträge aktualisiert hast, prüfe mit den kostenlosen Tools von Unspam, ob alles passt: SPF-Check, DKIM-Check und DMARC-Check.
Unspam verbindet sich nicht mit Google Workspace. Es gibt keine Anbindung an die Gmail API, keinen Admin-Zugriff, und Unspam meldet sich nie in deinem Konto an. Du bekommst eine Test-Adresse, schickst ihr eine echte Nachricht auf demselben Weg, auf dem sie deine Empfänger bekommen, und Unspam liest aus, was angekommen ist. Sollen die Tests nach Zeitplan laufen, kannst du SMTP-Zugangsdaten für automatische Inbox-Placement-Tests hinterlegen, und das sind die einzigen Zugangsdaten, die Unspam jemals hält.
Starte in Unspam einen Spam-Test oder einen Inbox-Placement-Test und kopiere die Adresse, die dabei erzeugt wird. Placement-Tests stellen an Test-Postfächer bei Gmail, Outlook, Yahoo und fünf weiteren Anbietern zu und melden, wo jede Kopie gelandet ist. Ein Inbox-Placement-Test erzeugt außerdem eine Test-ID. Füge sie vor dem Versand in den Betreff oder in den Text ein, sonst erreicht die Nachricht zwar die Test-Postfächer, wird aber nie deinem Test zugeordnet.
Geht es um Post, die eine Person in Gmail schreibt, verschick sie als dieser Benutzer und nicht aus deinem Super-Admin-Konto, das meist andere Signaturen, andere Gruppen und eine andere Historie hat. Geht es um eine Anwendung, löse die Anwendung aus, damit die Nachricht über den Host rausgeht, den sie im Produktivbetrieb nutzt, smtp.gmail.com oder smtp-relay.gmail.com. Der Weg verändert das Ergebnis: Über das Relay darf eine App als jede Adresse in deiner Organisation versenden, während smtp.gmail.com das From auf das authentifizierte Konto festnagelt.
Prüfe im Unspam-Report die SPF-, DKIM- und DMARC-Ergebnisse. Die signierende Domain ist der Verräter. Steht in d= eine Subdomain von gappssmtp.com statt deiner eigenen Domain, hast du die Schritte in der Admin-Konsole nie zu Ende gebracht, und DMARC ruht allein auf SPF, falls es überhaupt besteht. Derselbe Report bewertet Inhalt, Links und Header, du siehst also, ob die Authentifizierung die ganze Geschichte ist oder nur ihr erster Teil.
Ein Spam-Score sagt dir, wie ein Filter die Nachricht bewertet. Ein Inbox-Placement-Test sagt dir, wo die Kopien bei den Test-Anbietern tatsächlich gelandet sind, und genau das war deine Frage. Die Verteilung ist selten gleichmäßig: Eine Domain, der Gmail seit Jahren vertraut, kann anderswo trotzdem gefiltert werden, und dieses Muster deutet auf Reputation und Inhalt statt auf dein DNS.
DNS ist hier der langsame Teil. Google sagt, dass SPF-Änderungen bis zu 48 Stunden brauchen können und dass die Admin-Konsole die DNS-Warnung noch bis zu 48 Stunden anzeigen kann, nachdem du den DKIM-Eintrag korrekt angelegt hast. Prüfe die veröffentlichten Werte mit den Werkzeugen Dig und Check MX der Google Admin Toolbox, statt dem Banner zu glauben, und schick dann erneut an eine frische Test-Adresse. Ist dein Volumen hoch genug, nimm die Domain in die Postmaster Tools auf und beobachte die Spam-Rate: Gmail bittet dich, sie unter 0,10 % zu halten und 0,30 % nie zu erreichen.
Derselbe Test rendert deine Kampagne in über 50 echten E-Mail-Clients, darunter Gmail, Outlook, Apple Mail, iPhone und Android, jeweils im hellen und im dunklen Modus, über Client-Vorschauen, damit du Platzierung und Darstellung in einem Durchgang prüfst.
Googles eigene Dokumentation sagt, dass die Seite E-Mail authentifizieren dich noch bis zu 48 Stunden nach dem korrekten TXT-Eintrag auffordern kann, deine DNS-Einträge zu aktualisieren, und warnt separat davor, auf Authentifizierung starten zu klicken, bevor der Eintrag wirklich veröffentlicht ist. Behandle das Banner als Dekoration, nicht als Diagnose. Bestätige den Live-Wert mit dem Werkzeug Dig der Admin Toolbox und lies im Authentication-Results-Header einer echten Nachricht DKIM=pass.
DNS begrenzt eine einzelne Zeichenkette auf 255 Zeichen, und ein 2048-Bit-Schlüssel ist länger. Googles Lösung ist, die Zeichen des Schlüssels auf mehrere Textstrings zu verteilen, jeden in eigenen Anführungszeichen, innerhalb des einen Eintrags. Manche DNS-Oberflächen machen das für dich, manche weisen die Eingabe zurück, und manche nehmen sie an und speichern einen abgeschnittenen Wert, was der schlimmste Ausgang ist, weil der Eintrag veröffentlicht aussieht und trotzdem nie verifiziert. Kann dein Anbieter ihn wirklich nicht speichern, bietet Google für genau diesen Fall die Variante mit 1024 Bit.
Google dokumentiert: Gehört der Absender nicht zu einer deiner Domains, ändert das Relay den Envelope-Absender von user@domain_you_don't_own auf postmaster@your_domain. Bounces kommen dann an deiner postmaster-Adresse an, und der Return-Path passt nicht mehr zum From. Google markiert außerdem die Option Beliebige Adressen als nicht empfohlen, weil sie dich anfälliger für Missbrauch macht, sei es durch Schadsoftware auf den Geräten deiner Nutzer oder durch falsche SMTP-Einstellungen.
Google sagt es unmissverständlich: Die Absenderrichtlinien gelten nicht für Nachrichten an Google-Workspace-Konten. Post, die du an eine Kollegin auf deiner eigenen Domain schickst oder an ein anderes Unternehmen, das Workspace nutzt, wird nicht so bewertet wie Post an ein privates Gmail-Konto. Wenn dein einziger Test dein eigener Posteingang ist, testest du genau den Weg, der nie scheitern konnte. Schick stattdessen an Test-Postfächer bei echten Anbietern für Privatkunden.
Die häufigsten Probleme mit der Zustellbarkeit bei Google Workspace-Absendern, jeweils mit der passenden Lösung.
Dahinter stecken zwei verschiedene Dinge. Googles Dokumentation sagt, dass die Meldung noch bis zu 48 Stunden nach einem korrekten Eintrag stehen bleiben kann, die Konsole ist also oft schlicht veraltet. Die andere Ursache ist der ausgelassene letzte Klick: Den Schlüssel zu erzeugen und den TXT-Eintrag zu veröffentlichen bewirkt für sich genommen nichts, und der Status wechselt erst auf E-Mail wird mit DKIM authentifiziert, nachdem du auf E-Mail authentifizieren zurückgehst, auf Authentifizierung starten klickst und Google den Eintrag verifiziert hat.
Die Lösung Prüf den veröffentlichten Eintrag direkt mit dem Werkzeug Dig der Google Admin Toolbox auf google._domainkey.yourdomain.com, statt der Konsole zu glauben. Schick dann eine Nachricht an eine externe Adresse und lies den Authentication-Results-Header: DKIM=pass mit d= auf deiner eigenen Domain heißt, die Sache ist erledigt, was auch immer das Banner behauptet. Ist der Eintrag korrekt und Authentifizierung starten geklickt, sitz die 48 Stunden aus.
Ein öffentlicher 2048-Bit-Schlüssel ist länger als die 255 Zeichen, die eine einzelne DNS-Zeichenkette maximal fasst, der Schlüssel muss also als mehrere in Anführungszeichen gesetzte Strings innerhalb eines TXT-Eintrags gespeichert werden. Manche Oberflächen teilen ihn für dich auf, manche verweigern die Eingabe rundheraus, und manche nehmen sie an und schneiden still ab, was der schlimmste Fall ist: Der Eintrag existiert, sieht in der Oberfläche richtig aus und validiert nie.
Die Lösung Teil den Schlüssel selbst in mehrere Textstrings auf, jeden in eigenen Anführungszeichen innerhalb desselben TXT-Eintrags, genau so steht es auf Googles Seite zur DKIM-Fehlerbehebung. Prüf danach mit Dig, dass das Zurückgelieferte Zeichen für Zeichen dem Wert in der Admin-Konsole entspricht. Kann dein Anbieter ihn wirklich nicht speichern, erzeug den Schlüssel neu mit 1024 Bit; genau diese Länge bietet Google für Anbieter an, die 2048-Bit-Schlüssel nicht unterstützen.
Die App authentifiziert sich bei smtp.gmail.com mit der Adresse eines Nutzers und einem App-Passwort. Google dokumentiert, dass auf diesem Weg die From-Adresse zum authentifizierten Konto passen muss, jedes andere From wird also ersetzt. Die Post ist authentifiziert und wird zugestellt, sie kommt nur nicht von der Adresse, die Kunden erwarten, und Antworten landen im falschen Postfach.
Die Lösung Verleg die App auf das SMTP-Relay. Geh in der Admin-Konsole zu Apps > Google Workspace > Gmail > Routing, richte den SMTP-Relay-Dienst ein und setz Zugelassene Absender auf Nur Adressen in meinen Domains, damit die App als billing@ versenden darf. Richte die App auf smtp-relay.gmail.com auf Port 587 mit TLS und authentifiziere sie über SMTP-Authentifizierung erforderlich oder über die Option, nur E-Mails von den angegebenen IP-Adressen anzunehmen. Beachte, dass Googles zwei Seiten die Obergrenze des Relays unterschiedlich angeben, einmal als 10.000 Nachrichten pro Nutzer in 24 Stunden und einmal als 10.000 Empfänger pro Nutzer und Tag, dimensioniere deine Chargen also nach der niedrigeren Lesart.
Das Limit, das dich gestoppt hat, war wahrscheinlich nicht die Zahl der Nachrichten. Ein kostenpflichtiges Workspace-Konto bekommt 2.000 Nachrichten pro Tag, aber nur 3.000 externe Empfänger und 2.000 eindeutige externe Empfänger, und Nachrichten über SMTP, POP oder IMAP sind auf 100 Empfänger je Nachricht begrenzt. Ein Lauf über 600 Nachrichten, in dem Verteilerlisten stecken, sprengt die Empfängerzähler lange vor dem Nachrichtenzähler. Die Limits laufen über einen rollierenden 24-Stunden-Zeitraum und nicht über einen Kalendertag, um Mitternacht setzt sich also nichts zurück.
Die Lösung Zähl Empfänger, nicht Versände, und finde heraus, welchen Zähler du gerissen hast, bevor du irgendetwas änderst. Ist das Volumen echt und wiederkehrend, hol es aus dem Postfach heraus: Das SMTP-Relay erlaubt 10.000 Nachrichten pro Nutzer in 24 Stunden, und echtes Marketing gehört auf eine Plattform, die dafür gebaut ist. Im Testzeitraum rechne mit 500 Nachrichten und 500 eindeutigen Empfängern pro Tag, bis für die Domain $100 USD oder der Gegenwert bezahlt sind, und beachte: Google sagt, dass die Anhebung danach bis zu 75 Tage dauern kann.
Der Workspace-Schlüssel signiert nur Post, die Googles Server verlässt. Ein Newsletter aus einer Marketing-Plattform berührt diesen Schlüssel nie, er braucht also einen eigenen DKIM-Eintrag für deine Domain, auf dem Selektor, den dir diese Plattform nennt. Googles Seite zur DMARC-Fehlerbehebung schickt dich für genau diesen Fall in die Dokumentation des Drittanbieters. Dasselbe gilt für Helpdesks, E-Commerce-Belege, CRM-Benachrichtigungen und alles andere, was als deine Domain versendet.
Die Lösung Nimm jedes System auf, das als deine Domain versendet, und authentifiziere jedes einzeln: Veröffentliche den DKIM-Eintrag der Plattform auf ihrem eigenen Selektor und falte ihren SPF-Mechanismus in deinen einen SPF-Eintrag. Nutz die aggregierten DMARC-Berichte an deiner rua-Adresse, um die vergessenen Absender zu finden, genau dafür sind diese Berichte da. Schick dann aus jeder Quelle eine Testnachricht an eine Test-Adresse, damit du die d=-Domain je System ablesen kannst, statt zu raten.
Weil DMARC die signierende Domain prüft, nicht die Signatur. Ausgehende Workspace-Post wird auf einer Infrastruktur-Domain von Google signiert, einer Subdomain von gappssmtp.com, und dieser d=-Wert kann nie zu deiner From-Domain passen. Googles Absenderrichtlinien verlangen, dass sich die Domain im From-Header entweder mit der SPF-Domain oder mit der DKIM-Domain ausrichtet. Erst ein eigener Schlüssel unter Apps > Google Workspace > Gmail > E-Mail authentifizieren macht die DKIM-Hälfte dieses Alignments möglich.
Ist Workspace dein einziger Absender, dann ein TXT-Eintrag auf der Root-Domain, Hostfeld @, Wert v=spf1 include:_spf.google.com ~all. Versendest du zusätzlich über eine Marketing-Plattform, ein Helpdesk oder ein Abrechnungssystem, nimm deren Mechanismen in genau diesen Eintrag auf. Veröffentliche nie einen zweiten SPF-Eintrag auf demselben Namen und behalte Googles dokumentierte Grenze von zehn include:-Tags im Blick.
Google empfiehlt ~all und beschreibt es so, dass empfangende Server Nachrichten als Spam markieren sollen, wenn sie von Servern kommen, die nicht im Eintrag stehen. -all bittet die Empfänger, rundheraus abzuweisen, und das ist erst sicher, wenn du dir bei jedem legitimen Absender im Eintrag sicher bist. Da SPF nur einer von zwei Wegen ist, DMARC zu erfüllen, bringt der strengere Qualifier weniger, als die meisten annehmen, und kostet mehr an dem Tag, an dem jemand ein neues Tool ergänzt.
Einen, geprüft im August 2026. Der Eintrag führte früher weiter zu _netblocks, _netblocks2 und _netblocks3, und viele Ratschläge gehen bis heute davon aus. Heute antwortet _spf.google.com mit einem einzigen Eintrag aus ip4- und ip6-Bereichen ohne verschachtelte Includes und verbraucht damit einen deiner zehn Lookups. Prüf das selbst nach, bevor du wegen eines alten Blogbeitrags mit SPF-Flattening anfängst, denn es ist Googles Eintrag, und Google kann ihn ändern.
Erst wenn du 5.000 Nachrichten pro Tag an private Gmail-Konten überschreitest, gezählt über deine primäre Domain und ihre Subdomains zusammen und nicht je Subdomain. Das Tageslimit von 2.000 Nachrichten pro Nutzer macht das aus einem einzelnen Postfach schwer und über ein Team oder ein Relay leicht. Google sagt, der Status hat kein Ablaufdatum, er bleibt dir also, sobald du die Grenze einmal gerissen hast. Für Nachrichten an Google-Workspace-Konten gelten die Anforderungen nicht.
Nein. Unspam bindet die Gmail API nicht an und meldet sich nie in deinem Konto oder deiner Admin-Konsole an. Es gibt genau zwei Berührungspunkte: eine Test-Adresse, an die du eine echte Nachricht schickst, und, für Tests nach Zeitplan, SMTP-Zugangsdaten, die du selbst für automatische Inbox-Placement-Tests hinterlegst. Alles im Report wird aus der Nachricht ausgelesen, die angekommen ist. Der Free-Plan deckt 10 Spam-Tests und 3 Inbox-Placement-Tests pro Monat ohne Kreditkarte ab; kostenpflichtige Pläne starten bei $9 pro Monat mit 14 Tagen Geld-zurück-Garantie.
Die Angaben zur Plattform Google Workspace wurden anhand öffentlich zugänglicher Dokumentation geprüft (Stand: August 2026) und können sich seitdem geändert haben. Google Workspace ist eine Marke des jeweiligen Inhabers. Unspam ist weder mit Google Workspace verbunden noch wird Unspam von Google Workspace unterstützt.
