GoDaddy SPF-record instellen: De handleiding voor 2026

Je hebt het record in GoDaddy geplaatst, de laatste campagne is verstuurd en toch behandelt Gmail de helft van je e-mails alsof ze van een vreemde komen. Vervolgens voegt iemand een CRM toe, een nieuwsbrief-tool en een transactioneel platform, en de hele configuratie begint zich te gedragen als een kluwen losse draden. Dat is meestal het punt waarop een GoDaddy SPF-record ophoudt een simpel vinkje te zijn en verandert in de factor die je afleverbaarheid overeind houdt.

Het pijnlijke is dat SPF-fouten zich zelden duidelijk aankondigen. Er wordt een afzender toegevoegd, de DNS wordt eenmalig bewerkt, en weken later ziet het team dat e-mails in de spam belanden, treden er authenticatiefouten op, of werkt het ene platform wel terwijl het andere van de lijst valt. Als dit bekend in de oren klinkt, heb je te maken met DNS-beheer, recordstructuur en de 10 lookup-limiet, en niet alleen met “e-mailproblemen”.

Waarom je GoDaddy SPF-record belangrijker is dan je denkt

SPF is in theorie simpel, maar in de praktijk meedogenloos. Een ontvangende server controleert het gepubliceerde beleid van het domein in de DNS en vraagt vervolgens of de verzendende server toestemming heeft om namens dat domein te mailen. Als het antwoord niet overeenkomt, kan het bericht als ongeautoriseerd worden beschouwd, zelfs als de afzender legitiem is.

Daarom is een kapot GoDaddy SPF-record schadelijker dan velen beseffen. Zowel Microsoft 365 als Google Workspace vertrouwen op authenticatiesignalen die mailboxproviders achter de schermen evalueren. Een ontbrekend of onjuist geformatteerd SPF-record kan de inbox-aflevering beïnvloeden lang voordat iemand een zichtbare fout opmerkt. Het verschil tussen hardfail en softfail is hier van belang, omdat de afsluitende kwalificatie de ontvanger vertelt of ongeautoriseerde e-mail direct moet worden geweigerd of met argwaan moet worden behandeld.

Het onderdeel dat de meeste teams missen

SPF zegt niet alleen: “is dit domein van jou”. Het zegt: “staat deze afzender op de goedgekeurde lijst die in de DNS is gepubliceerd”. Dat is ook waar SPF-alignment belangrijk wordt, omdat DMARC later controleert of het zichtbare ‘Van’-domein overeenkomt met de geauthenticeerde bron.

Praktische regel: als er een afzender aan de stack is toegevoegd nadat het oorspronkelijke SPF-record was opgesteld, is die afzender waarschijnlijk het probleem geworden, tenzij het DNS-record ook is bijgewerkt.

De eigen richtlijnen van GoDaddy weerspiegelen de moderne aanpak, waarbij SPF wordt gepubliceerd als een TXT-record in plaats van een apart SPF-type record, en de workflow zich richt op DNS-bewerking binnen de domeinportfolio. Die configuratie klinkt alledaags, maar het is precies de reden waarom SPF zo vaak kapot gaat. Het record is makkelijk eenmalig toe te voegen en makkelijk te vergeten nadat de volgende tool is goedgekeurd.

Je eerste SPF-record toevoegen in GoDaddy DNS

Begin in de Domeinportfolio, open DNS en voeg een record toe als TXT. De eigen helpsectie van GoDaddy toont dit pad voor SPF-instellingen, waarbij het SPF-beleid wordt ingevoerd in het veld Waarde en de host wordt ingesteld op de root wanneer het beleid van toepassing is op het gehele domein, terwijl de TTL op Standaard blijft in het gedocumenteerde voorbeeld voor gerelateerde mailrecords GoDaddy’s SPF-record help GoDaddy’s DNS-recordvelden voor e-mailauthenticatie.

De velden die ertoe doen

Type moet TXT zijn, niet SPF. De documentatie van GoDaddy gebruikt TXT omdat dat het standaard publicatieformaat voor SPF is in moderne DNS, en die keuze voorkomt dubbelzinnigheid bij validators.

Naam moet meestal @ zijn voor een root-domeinbeleid. Dat vertelt GoDaddy dat het record bij de top van het domein hoort in plaats van bij een subdomein. Waarde is waar de SPF-string leeft, dus daar plak je het beleid zelf.

TTL kan op Standaard blijven staan als je de gedocumenteerde instellingen van GoDaddy volgt, vooral als je niet midden in een probleemoplossing zit. De exacte veldnamen zijn makkelijk over het hoofd te zien, maar ze maken het verschil tussen een record dat op de domein-root leeft en een record dat ergens nutteloos staat.

Een simpel door GoDaddy beheerd mailvoorbeeld ziet eruit als v=spf1 include:secureserver.net -all, wat de vorm is die GoDaddy toont voor hosting-e-mail. Als je slechts één afzenderbron autoriseert, is dat de vorm die je wilt: één record, één beleid, één plek.

Voor een Gmail-specifieke variant toont deze SPF-handleiding voor Gmail-gebruikers dezelfde TXT-eerst logica in de praktijk.

Als je het recordtype als iets anders dan TXT typt, of de host leeg laat wanneer het beleid op de root moet staan, kan het record wel in de interface bestaan, maar toch falen op de DNS-laag.

Later in het proces wordt de eigen interface van GoDaddy minder belangrijk dan de autoritatieve DNS-zone, maar de eerste winst is het record in het juiste veld invoeren, met het juiste type, bij de juiste host.

SPF-syntax voor de afzenders die je gebruikt

Veel organisaties gebruiken niet één afzender. Ze gebruiken een primair mailbox-account, een marketingplatform, een CRM en een transactioneel systeem. Het SPF-record is de enige verklaring die ze allemaal autoriseert, dus de eigenlijke taak is het kiezen van de juiste mechanismen en de lijst kort genoeg houden om te valideren voordat GoDaddy DNS tegen je begint te werken.

Kant-en-klare SPF-strings voor veelvoorkomende afzenderstacks

Afzenderconfiguratie	SPF-waarde	Gebruikte lookups
Google Workspace	v=spf1 include:_spf.google.com -all	Eén include, daarna de uiteindelijke beleidscontrole
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Eén include, daarna de uiteindelijke beleidscontrole
Google Workspace plus een marketingtool	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Twee includes, plus eventuele geneste lookups in de included records
Microsoft 365 plus een transactionele afzender	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Twee includes, plus eventuele geneste lookups in de included records

Deze strings zijn nuttig omdat ze het patroon laten zien: één record, één beleid, één plek om het in GoDaddy te beheren. Als je stack begint met Google Workspace of Microsoft 365 en vervolgens groeit naar marketing- en transactionele mail, gaat het record meestal niet meer over syntax, maar over hoeveel DNS-lookups elke provider achter de schermen verbruikt.

Wat de mechanismen doen

include zegt dat er een SPF-beleid van een ander domein moet worden gecontroleerd en dat de autorisatie daarvan moet worden overgenomen. Dat is het werkpaard voor Google Workspace, Microsoft 365, Mailchimp, SendGrid en soortgelijke platforms.

ip4 is voor vaste verzendadressen, wat helpt wanneer je de bron-IP beheert en niet afhankelijk wilt zijn van de beleidsketen van een andere provider. all aan het einde stelt de regel in voor alles wat nog niet is geautoriseerd, en de kwalificatie bepaalt hoe streng de fout moet zijn.

Praktische regel: gebruik een strengere afsluiting wanneer je afzenderlijst stabiel is, en een zachtere afsluiting alleen terwijl je de stack nog aan het opschonen bent.

Een nuttig extern perspectief op afzenderplanning is advies voor e-mailcampagnes voor kleine bedrijven, omdat campagneteams vaak tools toevoegen zonder hun impact op DNS te controleren.

Het onderdeel dat echte GoDaddy-configuraties laat struikelen is het lookup-budget. Elke extra include verbruikt dat budget, en een record kan er schoon uitzien terwijl het toch faalt omdat de keten te diep wordt. Bouw de syntax rond de stack die je gebruikt, niet de stack die je zou willen gebruiken.

Meerdere afzenders samenvoegen zonder de lookup-limiet te overschrijden

De grootste fout bij een GoDaddy SPF-record is niet de syntax, maar de opeenstapeling. Een domein begint met één afzender, dan voegt marketing er een toe, dan voegt verkoop een CRM toe, dan voegt operations een transactioneel platform toe, en niemand merkt dat SPF nu meer systemen probeert te valideren dan de standaard toestaat.

De regel is bot en buigt niet. Publiceer nooit meer dan één SPF-record onder dezelfde naam. Als er twee SPF TXT-records voor hetzelfde domein bestaan, kunnen ontvangers het resultaat als ongeldig of dubbelzinnig beschouwen, wat betekent dat het record waarvan je dacht dat het hielp, juist de authenticatie kan verbreken.

Hoe het samenvoegproces werkt

Begin met het opsommen van elke legitieme afzender. Voeg ze vervolgens samen in één TXT-beleid, waarbij je include-statements gebruikt waar de provider zijn eigen verzendinfrastructuur beheert. Als je al een record in GoDaddy hebt, bewerk dat dan in plaats van een tweede kopie te maken.

De tweede valkuil is nesting. Een enkele include kan verschillende extra lookups verbergen in het eigen SPF-beleid van de provider, en dat is de reden waarom domeinen sneller door hun budget heen kunnen raken dan het team verwacht. GoDaddy-gerichte handleidingen waarschuwen gebruikers om onder de limiet van 10 DNS-mechanisme lookups te blijven, en die limiet geldt tijdens de evaluatie, niet achteraf SPF-setup best practices voor GoDaddy-domeinen 2026 SPF-richtlijnen voor GoDaddy-domeinen.

Een schoner bedrijfsmodel

• Controleer eerst elke afzender: verwijder oude tools die geen mail meer versturen, omdat verouderde includes nog steeds budget verbruiken.
• Consolideer tot één beleid: houd alle autorisatie in één TXT-record onder de juiste naam.
• Verifieer het aantal lookups voordat je opslaat: een record dat er netjes uitziet, kan nog steeds falen als geneste includes het over de limiet duwen.

Mail Merge for Gmail past goed in deze logica. Het verstuurt via de geauthenticeerde infrastructuur van Google, dus het heeft geen eigen aparte include nodig en voegt niets toe aan het SPF-budget wanneer je Google Workspace al autoriseert.

De reden waarom dit zo belangrijk is, is simpel. Een team kan maandenlang onder de limiet blijven, en dan duwt één nieuwe leverancier het record over de rand en begint SPF te falen zonder enige duidelijke DNS-fout in de GoDaddy-interface.

Verifiëren of je record echt werkt

Het record opslaan in GoDaddy is geen bewijs. Het betekent alleen dat de wijziging is ingevoerd, niet dat de autoritatieve zone deze serveert, niet dat caches zijn bijgewerkt en niet dat het beleid correct wordt geparseerd.

Drie controles, drie verschillende antwoorden

De eerste controle is een DNS-lookup tegen de live zone. Een dig of nslookup query vertelt je wat de autoritatieve nameservers retourneren, wat belangrijk is omdat de GoDaddy-interface een waarde kan tonen voordat de propagatie is voltooid, en het vertelt je niet of een andere DNS-host de zone bezit.

De tweede controle is een SPF-parser zoals de SPF-check van MXToolbox. Dat soort tools is nuttig omdat ze de syntax lezen en tegelijkertijd de lookups tellen, wat precies is waar geneste includes en ketens die de limiet overschrijden aan het licht komen.

De derde controle is bewijs op berichtniveau. Stuur een test naar Gmail, open het originele bericht en inspecteer de headers. De regel Authentication-Results toont meestal of SPF is geslaagd of mislukt voor het verzendende domein, wat je vertelt hoe een mailboxprovider het bericht heeft geëvalueerd, niet alleen wat de DNS zegt.

Praktische regel: als de DNS correct lijkt maar de headers nog steeds falen, ligt het probleem meestal bij de validatielaag, niet bij de GoDaddy-interface.

Er is ook een propagatie-realiteit die teams negeren op eigen risico. Het TTL-gedrag van GoDaddy is meestal snel, maar DNS-wijzigingen in randgevallen kunnen nog steeds tijd nodig hebben om zich over resolvers te verspreiden. Als je records tussen providers verplaatst, bevestig dan eerst de autoritatieve nameservers en valideer vervolgens tegen de werkelijke zone, niet tegen het configuratiescherm dat je toevallig hebt gebruikt. Voor het van begin tot eind traceren van berichten is deze e-mailtrace-handleiding het schonere begeleidende stuk.

Van SPF-succes naar volledige e-mailauthenticatie

Een SPF-succes voelt geruststellend, maar het lost niet het hele probleem op. SPF autoriseert alleen verzendbronnen, het ondertekent het bericht niet en het voorkomt niet dat een bericht wordt gewijzigd nadat het de afzender heeft verlaten. Daarom kan SPF op zichzelf nog steeds leiden tot edge-cases bij doorsturen en gaten in impersonatie.

Waar DKIM en DMARC passen

DKIM voegt een cryptografische handtekening toe aan het bericht zelf. In door GoDaddy beheerde DNS betekent dit meestal een TXT-record onder de selector-host, en Google Workspace gebruikt vaak google._domainkey als onderdeel van die setup.

DMARC staat bovenop SPF en DKIM. Het vertelt ontvangende systemen wat ze moeten doen wanneer authenticatie mislukt en waar ze rapporten naartoe moeten sturen, meestal via een TXT-record bij _dmarc op het domein. Zonder DMARC hebben mailboxproviders geen gedeeld beleid om te volgen wanneer SPF of DKIM niet overeenkomen.

De belangrijkste conclusie is dat SPF slechts één laag van vertrouwen is. Een vervalst bericht kan nog steeds zwakke alignment uitbuiten als DKIM niet op zijn plaats is, en een doorgestuurd bericht kan zich nog steeds anders gedragen dan een originele verzending, zelfs wanneer SPF bij de bron schoon was.

De praktische stack is eenvoudig. SPF autoriseert de afzender, DKIM ondertekent het bericht en DMARC vertelt ontvangers hoe ze moeten handelen wanneer de twee het niet eens zijn. De eerdere sectie over verificatie is hier belangrijk omdat je het beleid niet wilt aanscherpen voordat je weet dat elke legitieme afzender authenticeert.

Voor een diepere duik in de volledige stack verbindt deze e-mailauthenticatie-handleiding SPF, DKIM en DMARC in één workflow.

SPF schoon houden tijdens echte Mail Merge-campagnes

Een Mail Merge-campagne zet de DNS-werkzaamheden snel onder druk. Verkoop-, werving- of eventteams kunnen de ene dag een schone reeks vanuit Gmail versturen en de volgende week de inhoud de schuld geven wanneer de antwoorden afnemen, ook al was het diepere probleem authenticatie-drift.

Mail Merge for Gmail verstuurt via de geauthenticeerde infrastructuur van Google, dus het creëert geen aparte afzender die zijn eigen SPF-include nodig heeft. Het grotere risico is dat de omliggende stack verandert, de domeineigenaar een ander platform toevoegt en de mailboxproviders een berichtgeschiedenis gaan evalueren die er niet langer consistent uitziet.

Een checklist vóór de campagne die echt helpt

• Bevestig dat SPF slaagt voor het verzendende Google-account: test de exacte mailbox die de campagne zal versturen, niet een willekeurige alias.
• Bevestig dat DKIM is ingeschakeld in Google Workspace-beheer: SPF alleen is te fragiel voor doorgestuurde of opnieuw verpakte mail.
• Bevestig dat DMARC minimaal op p=none staat met rapportage aan: dat geeft je zichtbaarheid voordat je het beleid verhardt.

Een groen SPF-resultaat op zichzelf betekent niet dat de campagne veilig is om te lanceren. Het betekent alleen dat de afzender op dat moment overeenkwam met het huidige DNS-beleid.

De beste gewoonte is om het SPF-record als loodgieterswerk te behandelen. Controleer het vóór de campagne, controleer het wanneer een nieuwe afzender wordt toegevoegd en controleer het opnieuw wanneer een platform zijn verzendpad wijzigt. Zo voorkom je dat een GoDaddy SPF-record veroudert tot een afleverbaarheidsprobleem.

---

Mail Merge for Gmail helpt teams gepersonaliseerde campagnes vanuit Gmail te versturen terwijl het verzendpad gekoppeld blijft aan Google Workspace, wat SPF makkelijker maakt om te beredeneren wanneer de domeinstack druk wordt. Als je een GoDaddy DNS-configuratie aan het opschonen bent vóór je volgende outreach-ronde, bezoek dan Mail Merge for Gmail en bekijk hoe het past in een workflow die al afhankelijk is van het schoonhouden van SPF, DKIM en DMARC.