SEOHostingWebsitesEmergency

• 27 Oct 2026

SPF-Eintrag hinzugefügt und Google Search Console verloren? Darum

Sie legen einen SPF-Eintrag an, damit Ihre E-Mails nicht mehr im Spam landen. Eine Woche später meldet Google Search Console, dass Ihre Website Not verified ist, und niemand hat Search Console angefasst. Beides hängt öfter zusammen, als man denkt, und es ist auch uns passiert.

Die kurze Antwort: SPF und der Google-Verifizierungscode stehen beide im TXT-Eintrag Ihrer Root-Domain. Viele DNS-Oberflächen halten alle diese Werte in einem Eintrag. Wenn Sie diesen Eintrag durch nur die SPF-Zeile ersetzen, ist der Google-Code weg. Search Console prüft ihn regelmäßig, und fehlt er, läuft Ihre Verifizierung ab. Die Lösung: den alten Wert neben SPF wieder eintragen, nie stattdessen.

Warum die eine Änderung die andere kaputt macht

Der TXT-Eintrag Ihrer Root-Domain (example.com, nicht www) ist ein gemeinsames Regal. Typischerweise enthält er:

SPF, die Zeile, die mit v=spf1 beginnt und festlegt, welche Server E-Mails für Ihre Domain senden dürfen.
google-site-verification=…, womit Sie Search Console beweisen, dass die Domain Ihnen gehört.
Weitere Eigentumsnachweise: MS=… für Microsoft 365, facebook-domain-verification=…, apple-domain-verification=… und ähnliche.

Manche DNS-Oberflächen (etwa Cloudflare) zeigen jeden Wert als eigene Zeile, sodass ein neuer Wert die anderen in Ruhe lässt. Andere, etwa AWS Route 53 und mehrere Registrare, zeigen einen TXT-Eintrag mit mehreren Zeilen. Dort löscht das Speichern mit nur Ihrer neuen Zeile jede Zeile, die Sie nicht erneut eingetippt haben. E-Mail-Anleitungen warnen selten davor, weil sie von einem leeren Eintrag ausgehen.

Google ist bei den Folgen eindeutig: Um verifiziert zu bleiben, entfernen Sie den DNS-Eintrag nicht, auch nicht nach erfolgreicher Verifizierung. Search Console prüft regelmäßig, ob der Code noch da ist. Fehlt er, erhalten Sie eine Warnung und nach einer Schonfrist verliert die Property ihre verifizierten Inhaber.

Was bei uns passiert ist

Am 19. Oktober 2026 richteten wir Google-Workspace-E-Mail für sechs Domains ein, die wir betreuen: fünf eigene Produkte und ein Kunden-Webshop. Bei der Einrichtung wurde auf jeder Domain der Root-TXT-Eintrag durch die SPF-Zeile von Workspace ersetzt. Die E-Mail funktionierte einwandfrei. Nichts sah falsch aus.

Sieben Tage später, am 26. Oktober, zeigten zwei dieser Domains in Search Console Not verified. Als wir alle sechs prüften, hatte jede ihren google-site-verification-Wert verloren. Die Ursache fanden wir in zehn Minuten: den aktuellen TXT-Eintrag mit dem Stand von vor einer Woche vergleichen.

So bekamen wir die alten Werte zurück: Die Domains liegen bei AWS Route 53, das jede DNS-Änderung in CloudTrail protokolliert (90 Tage aufbewahrt). Jedes ChangeResourceRecordSets-Ereignis enthielt noch den alten Eintrag samt Google-Code.
Die Lösung: Wir trugen jeden Google-Code wieder neben der SPF-Zeile im selben Eintrag ein und klickten in Search Console auf Verify. Alle sechs waren noch am selben Tag wieder verifiziert.
Der Schaden: Diesmal keiner, weil wir es bemerkten, solange Google noch in der Schonfrist war. Hätten wir nichts getan, wäre uns der Zugriff auf Suchdaten und Einstellungen von sechs Websites verloren gegangen.

Die Lehre, die wir in unser eigenes Runbook geschrieben haben: Bevor Sie einen Root-TXT-Eintrag ändern, listen Sie auf, was darin steht, und behalten Sie alles.

So prüfen Sie Ihre eigene Domain

Öffnen Sie ein Terminal und führen Sie aus:

dig TXT example.com +short

Unter Windows: nslookup -type=TXT example.com. Oder nutzen Sie ein beliebiges Online-DNS-Abfragetool. Sie sollten etwa Folgendes sehen:

"v=spf1 include:_spf.google.com ~all"
"google-site-verification=AbC123..."

Prüfen Sie drei Dinge:

Ist Ihr Google-Code da? Wenn Search Console für diese Domain eingerichtet ist und keine google-site-verification-Zeile existiert, läuft die Verifizierung ab.
Gibt es genau eine SPF-Zeile? Zwei Zeilen, die mit v=spf1 beginnen, sind nach dem SPF-Standard (RFC 7208) ein Fehler. Empfangende Mailserver werten Ihr SPF dann als defekt. Versenden Sie über zwei Dienste, fassen Sie sie in einer Zeile zusammen: v=spf1 include:_spf.google.com include:mailgun.org ~all.
Sind Ihre anderen Nachweise noch da? Microsoft, Meta, Apple und andere prüfen ihre Codes ebenfalls.

DKIM und DMARC sind hier nicht gefährdet: Sie liegen unter eigenen Namen (selector._domainkey.example.com und _dmarc.example.com), nicht auf der Root-Domain.

Schon verloren? So beheben Sie es

Alten Wert finden. Sehen Sie im Änderungsverlauf oder Audit-Log Ihres DNS-Anbieters nach (Route 53: CloudTrail, 90 Tage aufbewahrt). Manche Registrare führen ebenfalls einen Verlauf. Kein Verlauf? Starten Sie die Verifizierung in Search Console neu, dann erhalten Sie einen TXT-Wert zum Eintragen.
Hinzufügen, nicht ersetzen. Tragen Sie den Google-Code als zusätzliche Zeile im selben TXT-Eintrag ein, neben SPF und allem anderen, was dort steht.
Auf DNS warten. Meist Minuten; höchstens die TTL des Eintrags (oft eine Stunde).
Auf Verify klicken in Search Console bei der Property, die Not verified anzeigt.
Prüfen, ob die E-Mail weiter durchgeht. Senden Sie eine Testmail an eine Gmail-Adresse und suchen Sie unter Show original nach spf=pass.

So vermeiden Sie es beim nächsten Mal

Kopieren Sie vor dem Bearbeiten eines TXT-Eintrags dessen aktuellen Inhalt irgendwohin.
Bevorzugen Sie DNS-Änderungen, die einen Wert hinzufügen, gegenüber solchen, die einen Eintrag ersetzen. In Route 53 heißt das: erst das Record-Set lesen und dann die vollständige, zusammengeführte Liste speichern.
Führen Sie pro Domain eine kurze Liste, was der Root-TXT-Eintrag enthalten muss. Das dauert fünf Minuten und erspart eine Woche Verwirrung.
Prüfen Sie nach jeder DNS-Änderung noch am selben Tag Search Console und senden Sie eine Testmail.

Probleme mit Domain, E-Mail und DNS gehören zu unserer Notfallhilfe: Wir finden die Ursache, beheben sie und erklären Ihnen, was passiert ist. Mehr zu E-Mail-Problemen lesen Sie unter warum die E-Mails Ihrer Website nicht ankommen.

Häufige Fragen

Warum steht meine Website in Google Search Console auf „Not verified“?

Meistens wurde der TXT-Wert google-site-verification aus Ihrem DNS entfernt, zum Beispiel als ein SPF-Eintrag hinzugefügt wurde, indem man den bestehenden TXT-Eintrag ersetzt hat. Search Console prüft den Code regelmäßig und warnt Sie, wenn er fehlt.

Können SPF und google-site-verification im selben TXT-Eintrag stehen?

Ja. Eine Domain kann auf Root-Ebene viele TXT-Werte haben. Lassen Sie die SPF-Zeile und den Google-Code nebeneinander stehen; Sie dürfen nur nie zwei getrennte SPF-Zeilen haben.

Darf ich zwei SPF-Einträge haben?

Nein. Der SPF-Standard (RFC 7208) verbietet mehr als einen SPF-Eintrag pro Domain; empfangende Server melden dann einen Fehler. Fassen Sie alle Absender in einer Zeile zusammen, die mit v=spf1 beginnt.

Wie bekomme ich meinen Google-Verifizierungscode zurück?

Suchen Sie den alten Wert im Änderungsverlauf oder Audit-Log Ihres DNS-Anbieters. Gibt es keinen, starten Sie die Verifizierung in Search Console neu und tragen den neuen TXT-Wert neben Ihrer SPF-Zeile ein.

Betrifft das DKIM oder DMARC?

Nein. DKIM- und DMARC-Einträge liegen unter eigenen Namen (selector._domainkey und _dmarc), nicht auf der Root-Domain. Das Ersetzen des Root-TXT-Eintrags berührt sie daher nicht.