SPF-record toegevoegd en Google Search Console kwijt? Dit is waarom

Je voegt een SPF-record toe zodat je mails niet meer in de spam belanden. Een week later meldt Google Search Console dat je site Not verified is, terwijl niemand aan Search Console heeft gezeten. De twee hangen vaker samen dan je denkt, en bij ons gebeurde het ook.

Het korte antwoord: SPF en de Google-verificatiecode staan allebei in het TXT-record van je hoofddomein. Veel DNS-panelen bewaren al die waarden in één record. Als je dat record vervangt door alleen de SPF-regel, is de Google-code weg. Search Console controleert die regelmatig en als hij ontbreekt, vervalt je verificatie. De oplossing: zet de oude waarde terug naast SPF, nooit in plaats ervan.

Waarom de ene wijziging de andere breekt

Het TXT-record op je hoofddomein (example.com, niet www) is een gedeelde plank. Daarin staat meestal:

• SPF, de regel die begint met v=spf1 en bepaalt welke servers mail mogen versturen voor je domein.
• google-site-verification=…, waarmee je Search Console bewijst dat het domein van jou is.
• Andere eigendomsbewijzen: MS=… voor Microsoft 365, facebook-domain-verification=…, apple-domain-verification=… en dergelijke.

Sommige DNS-panelen (Cloudflare bijvoorbeeld) tonen elke waarde als aparte rij, dus een nieuwe waarde laat de andere met rust. Andere, zoals AWS Route 53 en meerdere registrars, tonen één TXT-record met meerdere regels. Daar wist het opslaan van het record met alleen je nieuwe regel alles wat je niet hebt ingetypt. Handleidingen voor mailinstellingen waarschuwen hier zelden voor, omdat ze uitgaan van een leeg record.

Google is duidelijk over de gevolgen: om geverifieerd te blijven moet je het DNS-record niet verwijderen, ook niet nadat de verificatie gelukt is. Search Console controleert regelmatig of de code er nog staat. Is dat niet zo, dan krijg je een waarschuwing en verliest de property na een uitstelperiode de geverifieerde eigenaren.

Wat er bij ons gebeurde

Op 19 oktober 2026 zetten we Google Workspace-mail op voor zes domeinen die we beheren: vijf van onze eigen producten en één webshop van een klant. Bij die setup werd op elk domein het TXT-record van het hoofddomein vervangen door de SPF-regel van Workspace. De mail werkte prima. Er leek niets mis.

Zeven dagen later, op 26 oktober, stonden twee van die domeinen op Not verified in Search Console. Toen we alle zes controleerden, bleek bij elk de google-site-verification-waarde weg. De oorzaak vonden we in tien minuten: het huidige TXT-record vergelijken met wat erin stond een week eerder.

• Hoe we de oude waarden terugkregen: de domeinen staan op AWS Route 53, dat elke DNS-wijziging logt in CloudTrail (90 dagen bewaard). Elk ChangeResourceRecordSets-event bevatte nog het oude record, inclusief de Google-code.
• De oplossing: we zetten elke Google-code terug naast de SPF-regel, in hetzelfde record, en klikten in Search Console op Verify. Alle zes waren dezelfde dag weer geverifieerd.
• De schade: deze keer geen, want we merkten het op terwijl Google nog in de uitstelperiode zat. Hadden we niets gedaan, dan waren we de toegang tot zoekdata en instellingen van zes sites kwijtgeraakt.

De les die we in ons eigen draaiboek zetten: bekijk vóór elke wijziging aan een TXT-record op het hoofddomein wat erin staat, en behoud alles.

Zo check je je eigen domein

Open een terminal en voer uit:

dig TXT example.com +short

Op Windows: nslookup -type=TXT example.com. Of gebruik een online DNS-lookuptool. Je zou iets als dit moeten zien:

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

Controleer drie dingen:

• Staat je Google-code er nog? Als Search Console voor dit domein is ingesteld en er staat geen google-site-verification-regel, dan vervalt de verificatie.
• Is er precies één SPF-regel? Twee regels die beginnen met v=spf1 is een fout volgens de SPF-standaard (RFC 7208). Ontvangende mailservers beschouwen je SPF dan als kapot. Verstuur je via twee diensten, voeg ze dan samen in één regel: v=spf1 include:_spf.google.com include:mailgun.org ~all.
• Staan je andere bewijzen er nog? Microsoft, Meta, Apple en anderen controleren hun codes ook.

DKIM en DMARC lopen hier geen gevaar: ze staan onder hun eigen namen (selector._domainkey.example.com en _dmarc.example.com), niet op het hoofddomein.

Al kwijt? Zo los je het op

1. Zoek de oude waarde. Kijk in de wijzigingsgeschiedenis of het auditlog van je DNS-provider (Route 53: CloudTrail, 90 dagen bewaard). Sommige registrars houden ook een geschiedenis bij. Geen geschiedenis? Start de verificatie opnieuw in Search Console, dan krijg je een TXT-waarde om toe te voegen.
2. Voeg toe, vervang niet. Zet de Google-code terug als extra regel in hetzelfde TXT-record, naast SPF en al het andere wat er staat.
3. Wacht op DNS. Meestal enkele minuten; maximaal de TTL van het record (vaak een uur).
4. Klik op Verify in Search Console bij de property die op Not verified staat.
5. Controleer of mail nog slaagt. Stuur een test naar een Gmail-adres en zoek spf=pass onder Show original.

Zo voorkom je het de volgende keer

• Kopieer de huidige inhoud van een TXT-record ergens naartoe voordat je het bewerkt.
• Kies DNS-wijzigingen die een waarde toevoegen boven wijzigingen die een record vervangen. In Route 53 betekent dat: eerst de record set lezen en dan de volledige, samengevoegde lijst opslaan.
• Houd per domein een korte lijst bij van wat het TXT-record op het hoofddomein moet bevatten. Het kost vijf minuten en bespaart een week verwarring.
• Controleer na elke DNS-wijziging dezelfde dag Search Console en stuur een testmail.

Problemen met domein, mail en DNS horen bij onze spoedhulp: we zoeken de oorzaak, lossen het op en vertellen je wat er gebeurd is. Meer mailproblemen? Lees waarom de mails van je website niet aankomen.

Lees ook

• Mails komen niet aan of in spam? Oorzaken en oplossing
• SSL-certificaat of domeinnaam verlopen? Zo los je het op
• SEO voor developers: wat je vanaf dag één inbouwt