SPF-record voor Gmail: Uw stapsgewijze handleiding voor 2026

U verstuurt een klantenupdate, een wervingsmail of een verkoopreeks vanuit Gmail. De tekst is sterk. De lijst is schoon. Vervolgens vertragen de antwoorden tot een slakkengang, of erger nog, iemand vertelt u dat uw bericht in de spam is beland.

Bij kleine teams zorgt dit er meestal voor dat men eerst naar onderwerpregels, sjablonen en het verzendvolume kijkt. Dat is begrijpelijk. Maar een van de meest voorkomende oorzaken bevindt zich buiten Gmail, in uw DNS-instellingen. Uw SPF-record bepaalt of ontvangende mailservers Gmail behandelen als een goedgekeurde afzender voor uw domein.

Dat is nog belangrijker als u onderzoek doet naar tools voor e-mailcampagnes op basis van Gmail. Wees voorzichtig met productnamen die algemeen klinken, vooral Mail Merge for Gmail. De term beschrijft zowel een categorie als een specifiek product, dus het is eenvoudig om installatieadvies dat bedoeld is voor een andere mail merge-tool toe te passen op het verkeerde systeem.

Waarom uw Gmail SPF-record belangrijk is

Een handige manier om over SPF na te denken is als een gastenlijst voor uw domein. Wanneer uw e-mail een andere mailserver bereikt, controleert die server of de afzender op de lijst staat. Als Gmail erop staat, heeft uw bericht een veel grotere kans om als legitiem te worden behandeld. Als Gmail er niet op staat, heeft de ontvanger een reden om het bericht te wantrouwen nog voordat de ontvanger de onderwerpregel heeft gelezen.

Dat vertrouwensprobleem duikt op in alledaagse zakelijke situaties. Een oprichter verstuurt onboarding-e-mails. Een HR-manager verstuurt uitnodigingen voor sollicitatiegesprekken. Een school verstuurt evenementupdates naar ouders. Alles ziet er prima uit in Gmail, maar de ontvangende server ziet geen duidelijke autorisatie voor uw domein en begint die berichten voorzichtiger te behandelen.

Wat SPF beschermt

SPF doet twee dingen tegelijk:

• Bezorgingsbescherming: Het helpt ontvangende servers herkennen dat Google namens uw domein mag verzenden.
• Merkbescherming: Het maakt het moeilijker voor iemand anders om uw domein te spoofen in uitgaande e-mail.

SPF vertelt de buitenwereld welke verzendsystemen namens uw domein spreken en welke niet.

Als u probeert het succes van e-mailmarketing te vergroten, is dit een van de eerste technische controles die de moeite waard is. Betere teksten kunnen niet compenseren voor een domein dat niet correct is geverifieerd.

Waarom kleine fouten voor grote problemen zorgen

Het frustrerende is dat SPF-problemen er vaak niet uitzien als SPF-problemen. Berichten kunnen nog steeds worden verzonden. Sommige ontvangers krijgen ze misschien nog steeds. Anderen zien mogelijk spam-plaatsing, waarschuwingen of stille filtering. Die inconsistentie is wat mensen in verwarring brengt.

Als uw e-mails al in de junk-mappen belanden, is het de moeite waard om deze installatiehandleiding te combineren met een praktische uitleg over hoe u voorkomt dat e-mail in de spam belandt. SPF is niet het hele verhaal van de bezorgbaarheid, maar het is een van de weinige oplossingen die direct het vertrouwen op domeinniveau verbetert in plaats van alleen de inhoud aan te passen en op het beste te hopen.

Uw basis Gmail SPF-record aanmaken

Als uw domein alleen e-mail verstuurt via Gmail of Google Workspace, is de installatie eenvoudig. Het officiële SPF-record van Google is de exacte reeks die gedocumenteerd is in de Google Workspace Admin Help:

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

Die waarde moet worden gepubliceerd als één TXT-record aan de root van uw domein. In de meeste DNS-dashboards is de host @. Google adviseert ook een TTL van 3600 seconden (1 uur), en DNS-wijzigingen kunnen volgens diezelfde Google Workspace-documentatie tot 48 uur duren om volledig te propageren, afhankelijk van uw provider.

Wat u moet invoeren in DNS

Of uw DNS nu wordt beheerd in GoDaddy, Cloudflare, Namecheap of een andere provider, de velden komen meestal als volgt overeen:

1. Type: TXT
2. Host of Naam: @
3. Waarde of Inhoud: de SPF-reeks hierboven
4. TTL: 3600 als uw provider u dit handmatig laat instellen

De meest gemaakte fout hier is het overdenken van het recordtype. Veel DNS-panelen bieden geen apart SPF-recordtype meer aan. Dat is normaal. U wilt een TXT-record.

Een snelle visuele rondleiding kan helpen als dit de eerste keer is dat u DNS bewerkt:

Wat werkt en wat niet

Hier is de praktische versie.

• Werkt: één TXT-record toevoegen aan de root van het domein met de exacte Gmail SPF-waarde.
• Werkt niet: extra spaties toevoegen, de waarde splitsen in afzonderlijke SPF-records of deze publiceren onder de verkeerde host, zoals een subdomein, wanneer uw mail wordt verzonden vanaf het hoofddomein.

Praktische regel: Kopieer de SPF-waarde exact, publiceer deze één keer en weersta de drang om later een tweede SPF-record aan te maken wanneer u een andere afzender toevoegt.

Als u zich in een eenvoudige Gmail-omgeving bevindt, is dit meestal voldoende om uw basis SPF-record voor Gmail correct in te stellen. Sla het record op, wacht op propagatie en verifieer het voordat u iets anders wijzigt.

Omgaan met meerdere e-mailafzenders en Mail Merge

Een veelvoorkomende opzet voor kleine bedrijven ziet er als volgt uit. Medewerkers versturen reguliere mail vanuit Google Workspace, marketing voert campagnes uit vanuit een mail merge-tool en een CRM of helpdesk verstuurt geautomatiseerde berichten vanuit hetzelfde domein. SPF moet ze allemaal dekken, anders begint een van die systemen met het falen van de authenticatie.

Dat is waar veel Gmail SPF-configuraties misgaan. Het basis Google-record is eenvoudig. De complexiteit begint wanneer elke nieuwe tool u vraagt om een andere include:-vermelding toe te voegen en niemand controleert wat die toevoegingen doen met het volledige record.

De twee regels die het belangrijkst zijn

Regel één: publiceer één SPF TXT-record voor het domein.

Regel twee: houd de volledige SPF-evaluatie onder de 10 DNS-lookups. Die limiet omvat geneste lookups binnen elke include:. Een record kan er kort uitzien in uw DNS-paneel en toch falen omdat het SPF-record van één leverancier uitbreidt naar verschillende andere controles. Deze analyse van DMARC Report legt uit waarom het aantal lookups belangrijk is bij de Gmail SPF-configuratie.

Omgevingen met meerdere afzenders bereiken die limiet sneller dan mensen verwachten. Google Workspace plus een mail merge-afzender, een CRM en een ondersteuningsplatform kunnen u in de problemen brengen, zelfs als de instructies van elke leverancier technisch gezien correct zijn. De fout is om elke afzender als een apart DNS-project te behandelen in plaats van als één gecombineerd autorisatiebeleid.

Hoe een juiste samenvoeging eruitziet

Als Gmail en een andere goedgekeurde service beide mail versturen voor uw domein, voeg dan beide afzenders toe aan hetzelfde SPF-record.

Scenario	Correct samengevoegd SPF-record
Alleen Gmail	v=spf1 include:_spf.google.com ~all
Gmail plus één externe afzender	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail plus meerdere afzenders	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

Die voorbeelden tonen de structuur. Uw werkelijke externe waarden moeten afkomstig zijn uit de documentatie van elke provider. Het praktische punt blijft ongewijzigd. Eén domein krijgt één SPF-record.

Wat meestal kapot gaat in de praktijk

Ik zie meestal drie foutpatronen.

• Er wordt een tweede SPF-record gepubliceerd. Iemand voegt een nieuwe TXT-vermelding toe die begint met v=spf1 in plaats van het bestaande record te bewerken.
• Oude services blijven voor altijd geautoriseerd. Een bedrijf stopt met het gebruik van een tool, maar de include: blijft in DNS staan en verbruikt lookups.
• Mail merge wordt behandeld als “gewoon Gmail”. Sommige tools versturen via de infrastructuur van Google, terwijl andere versturen via hun eigen servers of een verbonden provider. Dat verschil verandert of SPF een andere include nodig heeft.

Het derde punt wordt vaak gemist. Als uw team een op Sheets gebaseerde workflow gebruikt, bevestig dan hoe die tool mail verstuurt voordat u DNS aanraakt. Een handleiding over mail merge vanuit Google Sheets kan u helpen de workflow in kaart te brengen, maar SPF hangt nog steeds af van de verzendinfrastructuur achter die workflow.

Hoe u onder de limiet van 10 lookups blijft

Begin met een inventarisatie van afzenders. Maak een lijst van elk systeem dat mail mag versturen als uw domein. Neem marketingplatforms, CRM’s, ondersteuningstools, facturatie-apps, websiteformulieren en elk mail merge-product op.

Snoei daarna hard.

Verwijder afzenders die u niet meer gebruikt. Controleer of twee tools via dezelfde provider versturen, waardoor één include overbodig kan zijn. Als een leverancier meer dan één SPF-optie aanbiedt, kies dan degene die ze documenteren voor uw use-case in plaats van elk record dat u kunt vinden te plakken.

Als het record nog steeds te groot is, is het antwoord niet een tweede SPF-record. Het antwoord is om het aantal geautoriseerde verzendpaden te verminderen, of in sommige gevallen een subdomein te gebruiken voor een afzonderlijke mailstroom, zodat het SPF-record van het hoofddomein beheersbaar blijft.

Als u een nieuwe afzender toevoegt, behandel dit dan als een beoordeling van DNS-wijzigingen. Bevestig dat de afzender nog steeds nodig is, werk het enige SPF-record bij en controleer het aantal lookups voordat u opslaat.

Hoe u verifieert of uw SPF-record werkt

Zodra u het record hebt opgeslagen, moet u er niet vanuit gaan dat u klaar bent. Bij verificatie vangt u de stille fouten op, vooral als uw DNS-paneel de invoer heeft geaccepteerd, maar de syntaxis of het aantal lookups nog steeds onjuist is.

Gebruik eerst een validator

Begin met een openbare SPF-checker zoals MxToolbox of dmarcian SPF Surveyor. Deze zijn nuttig omdat ze niet alleen bevestigen dat er een TXT-record bestaat. Ze inspecteren ook de structuur en, in het geval van meer geavanceerde lookups, helpen ze u inzien of uw includes te veel DNS-lookups creëren.

Voer uw domeinnaam in en bekijk het resultaat zorgvuldig. U zoekt naar drie dingen:

• Het record is gevonden: de tool kan uw SPF TXT-record zien in de openbare DNS.
• De syntaxis is geldig: geen misvormde mechanismen, verdwaalde spaties of dubbele SPF-vermeldingen.
• De keten is beheersbaar: de includes breiden niet uit naar een defect resultaat.

Hoe een goed resultaat eruitziet

Een gezonde controle ziet er meestal saai uit, en dat is precies wat u wilt. De tool vindt één SPF-record, parseert het netjes en markeert geen permanente fout.

Een falend resultaat valt meestal in een van deze categorieën:

• Geen SPF-record gevonden: het record is nog niet gepropageerd, is opgeslagen onder de verkeerde host of is nooit gepubliceerd.
• Meerdere SPF-records gevonden: u hebt een tweede v=spf1 TXT-record toegevoegd in plaats van het bestaande record te bewerken.
• Te veel lookups: uw gecombineerde afzenderlijst is te groot of te genest.

Controleer ook een live e-mail

Validators zijn goed voor de structuur. Een echt bericht bevestigt het gedrag.

Stuur een test-e-mail naar een Gmail-inbox waar u toegang toe hebt. Open het bericht, gebruik de optie van Gmail om de oorspronkelijke berichtbron te bekijken en inspecteer de authenticatieresultaten. Als SPF slaagt, is dat een sterk teken dat uw openbare DNS en uw werkelijke verzendpad op elkaar zijn afgestemd.

Validatietools vertellen u of het DNS-record publiceerbaar is. Een live test vertelt u of uw werkelijke mailstroom overeenkomt met het DNS-beleid.

Als de validator slaagt maar live berichten zich nog steeds misdragen, ligt het probleem mogelijk elders in uw authenticatiestack in plaats van alleen in SPF.

Veelvoorkomende SPF-recordfouten oplossen

SPF-problemen worden meestal direct na een wijziging duidelijk. Een klein bedrijf begint voorstellen te versturen vanuit Google Workspace, voegt een mail merge-tool toe en merkt vervolgens dat antwoorden vertragen of berichten in de spam belanden. In de praktijk is het probleem vaak één DNS-fout, geen ingewikkeld mailprobleem.

Meerdere SPF-records gevonden

Symptoom: uw validator rapporteert meerdere SPF-records, of ontvangende servers retourneren een permanente SPF-fout.

Oorzaak: uw domein heeft meer dan één TXT-record dat begint met v=spf1. Ik zie dit nadat een bedrijf een tweede afzender heeft toegevoegd, zoals een CRM of outreach-platform, en de installatiehandleiding van de nieuwe leverancier letterlijk is gevolgd. SPF voegt die records niet samen. Ontvangers zien het conflict en behandelen het als ongeldig.

Oplossing: houd één SPF-record voor het domein en voeg elke goedgekeurde afzender samen in die ene TXT-vermelding. Als u al afzonderlijke records hebt, kies er dan één als master, combineer de benodigde mechanismen en verwijder vervolgens de extra’s.

Te veel DNS-lookups

Symptoom: het record ziet er compleet uit, maar SPF faalt nog steeds met een lookup-limiet of permerror-resultaat.

Oorzaak: SPF-controles kunnen slechts een beperkt aantal DNS-lookups volgen. Dit is de fout die basis Gmail SPF-handleidingen vaak overslaan. Het komt voor in echte omgevingen waar Google Workspace slechts één afzender is onder meerdere, vooral als u ook mail merge-software, een helpdesk, een facturatiesysteem en een marketingplatform van hetzelfde domein gebruikt. Elke include: kan meer includes eronder ophalen, dus een record dat er kort uitziet, kan de limiet nog steeds overschrijden.

Oplossing: snoei de afzenderlijst voordat u iets slims probeert. Verwijder services die geen mail meer versturen voor uw domein. Vraag elke leverancier of al hun gepubliceerde includes nodig zijn voor uw use-case. Als uw stack nog steeds te groot is, splits mailstromen dan per subdomein. Houd bijvoorbeeld reguliere medewerkersmail op uw hoofddomein en verplaats outreach of bulkmail naar een subdomein met zijn eigen SPF-beleid. Die aanpak is vaak de schoonste oplossing in een opstelling met meerdere afzenders omdat het de lookup-druk vermindert en voorkomt dat één opgeblazen record alles kapot maakt.

Syntax-problemen en ontbrekende records

Symptoom: het record bestaat in DNS, maar de validator markeert opmaakfouten of er wordt helemaal geen SPF-record gevonden.

Oorzaak: dit komt meestal door slecht knippen en plakken, de verkeerde hostwaarde of het publiceren van de SPF-reeks in het verkeerde veld. In cPanel, GoDaddy, Cloudflare en vervangers van Google Domains verschillen de labels net genoeg om beginnende beheerders in verwarring te brengen. Een record dat bedoeld is voor het root-domein kan worden ingevoerd onder www, of de TXT-waarde kan onjuist worden gesplitst.

Oplossing: vergelijk de gepubliceerde TXT-waarde teken voor teken met het beoogde record. Bevestig dat de host correct is voor het domein dat u verifieert en zorg ervoor dat u een TXT-record hebt gemaakt, geen ander recordtype. Als de syntaxis in orde is maar mail nog steeds faalt, bekijk dan de bredere e-mailauthenticatie-installatie voor aangepaste domeinen, omdat het SPF-record geldig kan zijn terwijl een andere authenticatiecontrole het probleem veroorzaakt.

Een praktische volgorde voor probleemoplossing

Gebruik deze volgorde wanneer SPF faalt:

1. Controleer op dubbele SPF-records. Dit is het snelste probleem om te bevestigen en op te lossen.
2. Bekijk de recordtekst nauwkeurig. Zoek naar typefouten, ontbrekende spaties, extra aanhalingstekens of de verkeerde host.
3. Breng elke verzendservice in kaart. Neem Google Workspace, mail merge-tools, CRM’s, ondersteuningsplatforms en al het andere dat verstuurt als uw domein op.
4. Tel lookup-intensieve includes. Als de lijst vol is, vereenvoudig deze dan of verplaats sommige afzenders naar een subdomein.

Deze volgorde bespaart tijd omdat het overeenkomt met hoe SPF meestal faalt in de praktijk. Kleine teams gaan er vaak vanuit dat de nieuwste tool het probleem heeft veroorzaakt, maar oude DNS-rommel komt net zo vaak voor. Als u een bredere operationele checklist wilt terwijl u dit opschoont, is Simply Tech Today’s handleiding voor e-mailbeveiliging een nuttige referentie.

Voorbij SPF: uw volgende stappen in e-mailauthenticatie

Een klein bedrijf kan een correct SPF-record publiceren en nog steeds zien dat berichten in de spam belanden zodra facturen, outreach en follow-ups vanuit verschillende systemen worden verstuurd. Dat gebeurt meestal in gemengde opstellingen, vooral wanneer Google Workspace dagelijkse mail afhandelt en een andere tool campagnes of mail merge verstuurt vanuit hetzelfde domein.

SPF dekt slechts een deel van de beslissing die een ontvangende mailserver neemt. Het controleert of de verzendende server uw domein mag gebruiken. Dat is belangrijk, maar het bewijst niet dat het bericht correct is ondertekend en vertelt de ontvangende server niet wat hij moet doen als de authenticatie mislukt.

Dat is waar DKIM en DMARC om de hoek komen kijken, en ze zijn nog belangrijker in omgevingen met meerdere afzenders.

DKIM voegt een cryptografische handtekening toe aan het bericht, zodat ontvangende servers kunnen bevestigen dat het bericht legitiem is en niet is gewijzigd nadat het uw systeem heeft verlaten. DMARC staat bovenop SPF en DKIM en vertelt mailboxproviders hoe ze die controles voor uw domein moeten evalueren. Het geeft u ook rapportage, wat vaak het eerste duidelijke beeld is van een afzender waarvan u was vergeten dat deze uw domein gebruikte.

Dit is het punt dat veel basis SPF-handleidingen missen. Als u Google Workspace, een mail merge-tool, een CRM en een ondersteuningsplatform gebruikt, kan SPF moeilijk te onderhouden zijn vanwege de limiet van 10 lookups. DKIM helpt de afhankelijkheid van alleen SPF te verminderen en DMARC geeft u een beleidslaag zodat uw domein niet alleen wordt beoordeeld op basis van één overvol TXT-record.

Voor de volgende technische stap na SPF, bekijk deze handleiding over e-mailauthenticatie voor aangepaste domeinen. Het biedt het praktische installatiepad voor DKIM en DMARC nadat uw SPF-record op zijn plaats staat.

Als u een bredere operationele checklist wilt, is Simply Tech Today’s handleiding voor e-mailbeveiliging een nuttige aanvullende lectuur.

De praktische conclusie is eenvoudig. SPF regelt de toestemming. DKIM bewijst de integriteit van het bericht. DMARC geeft u controle, zichtbaarheid en een veiligere manier om een domein te beheren dat mail verstuurt vanuit meer dan één systeem.