Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung publiziert deine Domain einen korrekten SPF-Record für Google Workspace — inklusive kombinierter Records für Newsletter-Dienste und CRM.

Voraussetzungen

  • Ein Google-Workspace-Konto mit eigener Domain
  • Zugriff auf die DNS-Verwaltung deiner Domain — die liegt nicht bei Google, sondern bei deinem Domainhost

Was ist SPF?

SPF (Sender Policy Framework) ist ein TXT-Record im DNS deiner Domain. Er listet auf, welche Mailserver E-Mails mit deiner Domain als Absender verschicken dürfen. Empfangende Server prüfen anhand des Eintrags, ob eine Nachricht von einem autorisierten Server stammt. Ohne SPF kann jeder beliebige Server Mails in deinem Namen verschicken — und deine legitimen Mails landen schneller im Spam.

Google macht daraus inzwischen eine harte Anforderung: Absender von Massen-E-Mails (mehr als 5.000 Nachrichten täglich) müssen SPF, DKIM und DMARC eingerichtet haben, sonst nimmt Gmail ihre Mails nicht mehr zuverlässig an.

Die Ausgangslage bei Google Workspace

Wie bei Microsoft 365 gilt: In der Google Admin-Konsole ist für SPF nichts zu tun. Der Record wird beim Domainhost eingetragen — also dort, wo deine DNS-Zone liegt. Wie das dort jeweils geht, zeigen unsere Anleitungen für IONOS, Strato, All-Inkl, Netcup und Hetzner DNS.

Zwei Hinweise aus Googles eigener Doku: SPF kann für deine Domain bereits eingerichtet sein (etwa wenn du die Domain über einen Google-Partner registriert hast) — deshalb erst prüfen, dann ändern. Und der Record soll alle Server enthalten, die für deine Organisation senden, nicht nur Google.

Schritt-für-Schritt-Anleitung

1. Prüfen, ob SPF schon aktiv ist

Am schnellsten im Terminal:

dig TXT beispiel.de +short | grep spf1

Alternativ wirf deine Domain in den kostenlosen MXAudit-Scanner — der prüft den Record gleich auf Syntax und Lookup-Limit mit.

2. Den Record bestimmen

Nur Google Workspace versendet (der Normalfall):

v=spf1 include:_spf.google.com ~all

Der Include verweist inzwischen auf eine flache Liste von Google-IP-Bereichen (IPv4 + IPv6) und kostet genau einen DNS-Lookup. In älteren Anleitungen kursieren noch die verschachtelten _netblocks-Includes — die brauchst du nicht mehr einzutragen.

Weitere Dienste senden mit? Google dokumentiert die Kombination selbst, alle Quellen in einem Record — z. B. mit Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Mit Salesforce:

v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Oder im Parallelbetrieb mit Microsoft 365:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

3. Record beim Domainhost eintragen

Melde dich bei deinem Domainhost an und lege den Wert als TXT-Record auf der Hauptdomain (Host @) an — oder aktualisiere den bestehenden v=spf1-Eintrag. Pro Domain darf es nur einen SPF-Record geben.

4. Subdomains bedenken

Laut Google braucht jede Subdomain, die sendet, einen eigenen SPF-Eintrag — der Record der Hauptdomain gilt nicht automatisch mit.

5. Warten, bis die Änderung aktiv ist

DNS-Änderungen brauchen Zeit: Je nach TTL und Caching kann es einige Stunden dauern, bis alle Server weltweit den neuen Record sehen.

Die Bestandteile im Detail

BestandteilBedeutung
v=spf1Versionskennung, steht immer am Anfang
include:_spf.google.comerlaubt die Google-Versandinfrastruktur (flache IPv4/IPv6-Liste, 1 Lookup)
include: (weitere)erlaubt externe Dienste — je 1 zusätzlicher DNS-Lookup
~allSoftfail: Googles Standard-Empfehlung im Beispiel-Record

Interessanter Kontrast: Google zeigt in allen Beispielen ~all, während Microsoft für 365-Domains -all empfiehlt. Beides ist vertretbar — mit sauberem DKIM und DMARC (das Google für Massenversender ohnehin verlangt) ist die all-Wahl weniger entscheidend, weil DMARC die Durchsetzung übernimmt.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen MXAudit-Scanner — er zeigt dir sofort, ob dein SPF-Record syntaktisch korrekt ist und wie viele DNS-Lookups er verbraucht (das Limit liegt bei 10).

Oder direkt im Terminal:

dig TXT beispiel.de +short | grep spf1

Die Ausgabe muss genau einen Record mit v=spf1 enthalten.

Häufige Fehler

Zweiten SPF-Record angelegt statt den bestehenden ergänzt. Viele Domains haben schon einen Hoster-Record. Der Google-Include gehört dort hinein — zwei v=spf1-Einträge ergeben permerror.

Nicht alle Sender erfasst. Googles Doku ist deutlich: Der Record soll die Server aller sendenden Systeme enthalten — CRM, Rechnungs-Tool, Ticketsystem. Was fehlt, wird beim Empfänger aussortiert.

Veraltete _netblocks-Includes. Alte Anleitungen listen Googles interne Netblock-Records einzeln auf. Unnötig: include:_spf.google.com genügt und bleibt aktuell, wenn Google seine IP-Bereiche ändert.

Subdomains vergessen. Jede sendende Subdomain braucht ihren eigenen SPF-Eintrag.

+all am Ende. Ein +all erlaubt jedem Server das Senden und macht den gesamten Record wirkungslos — nicht übernehmen.

Weiterleitungen schlagen fehl. Leitet ein Empfänger deine Mail automatisch weiter, schlägt SPF beim Endempfänger oft fehl — der weiterleitende Server steht ja nicht in deinem Record. Das ist eine Designschwäche von SPF und kein Konfigurationsfehler; DKIM und DMARC fangen diesen Fall ab.