Een IP-adres toevoegen aan uw SPF-record (stapsgewijze handleiding)

Om een IP-adres aan je SPF-record toe te voegen, bewerk je het bestaande SPF TXT-record van je domein in de DNS en voeg je een `ip4:`- (of `ip6:`-) mechanisme toe vóór het `all`-mechanisme. Bijvoorbeeld:

v=spf1 ip4:192.0.2.1 include:_spf.google.com -all

Belangrijk: Maak GEEN tweede SPF-record aan. U moet uw bestaande record bewerken en, voordat u een onbewerkte IP-adres toevoegt, controleren of uw verzendservice in plaats daarvan een `include:`-waarde biedt, wat op de lange termijn meestal de betere keuze is.

Deze handleiding leidt u door het volledige proces, van het opzoeken van uw huidige record en het kiezen tussen `ip4` en `include` tot het aanpassen van uw DNS-instellingen bij populaire providers, het controleren van het resultaat en het vermijden van de fouten die elk jaar bij duizenden domeinen onopgemerkt de e-mailverbinding verstoren.

Wat is een SPF-record en waarom is dit belangrijk in 2026?

SPF (Sender Policy Framework) is een DNS-TXT-record waarin de IP-adressen en diensten worden vermeld die bevoegd zijn om e-mail te verzenden vanaf uw domein. Als het IP-adres van een server niet op de lijst staat, kunnen ontvangende mailservers het bericht weigeren of markeren.

Google is in februari 2024 begonnen met het handhaven van in februari 2024 authenticatievereisten voor bulkverzenders, waarbij SPF of DKIM plus DMARC verplicht is voor iedereen die meer dan 5.000 berichten per dag verstuurt. 

Vanaf november 2025 worden e-mails die niet aan de vereisten voldoen definitief geweigerd; het gaat niet om tijdelijke uitstelmaatregelen, maar om harde bounces. Yahoo heeft op hetzelfde tijdstip identieke vereisten ingevoerd. Microsoft volgde in mei 2025, waarbij niet-geverifieerde bulk-e-mails direct worden geweigerd met 550-foutmeldingen.

Zonder een correct SPF-record loopt uw domein het risico op spoofing en kunnen zelfs uw legitieme e-mails worden geweigerd door Gmail, Yahoo en Outlook. Als uw SPF-record niet klopt, komen uw e-mails gewoon niet meer aan, zonder dat u daar een melding van krijgt. Ze mislukken stilletjes bij de ontvanger, en u komt er pas achter als een klant of collega u vertelt dat hij of zij uw bericht nooit heeft ontvangen.

Uitleg over de syntaxis van SPF-records (met voorbeelden)

Voordat je iets aan je record toevoegt, moet je weten wat elk onderdeel doet. Hier volgt een overzicht van de opbouw van een standaard SPF-record:

v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all

Hier volgen drie praktijkvoorbeelden met verschillende niveaus van complexiteit:

Eenvoudig (één mailserver):

v=spf1 ip4:198.51.100.25 -all

Een typisch MKB-bedrijf (Microsoft 365 + één marketingtool):

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

Complexe onderneming (meerdere diensten):

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all

Moet je een dossier helemaal opnieuw opbouwen? 

Gebruik de gratis SPF-recordgenerator van PowerDmarc om direct een syntactisch correct record aan te maken.

Hoe voeg je een IP-adres toe aan je SPF-record (stap voor stap)

Het toevoegen van een IP-adres aan je SPF-record is een van de meest directe manieren om een afzender te autoriseren. Dit is meestal nodig wanneer je gebruikmaakt van een dedicated server, een systeem voor transactionele e-mail of een andere infrastructuur waarover je zelf de controle hebt.

Hoewel de wijziging op zich eenvoudig is, is nauwkeurigheid van groot belang, omdat onjuiste gegevens of opmaakfouten de authenticatie en de afleverbaarheid kunnen beïnvloeden. In de onderstaande stappen wordt uitgelegd hoe u een IP-adres correct aan uw SPF-record toevoegt, zonder uw huidige configuratie te verstoren.

Stap 1: Zoek je huidige SPF-record

Veel domeinen hebben al een SPF-record uit een eerdere configuratie. Als je zonder dit te controleren een nieuw record aanmaakt, krijg je er twee en dat zorgt ervoor dat alles niet meer werkt.

U kunt uw huidige gegevens op twee manieren opzoeken. 

Gebruik de gratis SPF-checker van PowerDMARC voor een direct visueel resultaat of voer een commandoregelquery uit:

nslookup -type=TXT uwdomein.com

dig TXT uwdomein.com

Ontdek hoe u uw SPF-record direct kunt controleren en configuratieproblemen kunt opsporen die de afleverbaarheid van e-mails kunnen beïnvloeden

Zoek naar een TXT-record dat begint met v=spf1. Als je er een ziet, is dat je SPF-record en ga je dit in stap 3 bewerken. Als je twee records ziet die allebei beginnen met v=spf1, heb je al een probleem; voeg ze samen tot één record voordat je verdergaat.

Stap 2: Zoek het IP-adres op of vul de waarde in die je moet toevoegen

Er zijn hier twee scenario's, en de juiste keuze hangt af van wat je autoriseert:

Scenario A: U voegt een specifiek IP-adres toe. Dit is van toepassing wanneer u uw eigen mailserver op een statisch IP-adres draait, of wanneer u een eigen verzend-IP-adres hebt waarover u de controle hebt. U hebt het exacte IPv4- of IPv6-adres van de server nodig.

Scenario B: U autoriseert een externe dienst. Dit geldt voor diensten zoals Mailchimp, SendGrid, HubSpot, Google Workspace of Microsoft 365. In dit geval hebt u de waarde 'include:' uit de documentatie van die dienst nodig, niet hun IP-adressen.

Lees, voordat je een onbewerkte IP-adres toevoegt, eerst het onderstaande gedeelte over `ip4` versus `include`. Voor de meeste diensten van derden is `include:` op de lange termijn de betere keuze.

Stap 3: Bewerk je SPF-record in DNS

Log in bij je DNS-provider (je domeinregistrar of hostingprovider), zoek de TXT-records voor je domein op en bewerk het bestaande SPF-record. Voeg het nieuwe `ip4:`- of `include:`-mechanisme toe VÓÓR het `all`-mechanisme.

Hieronder lees je hoe je dit bij de meest gangbare providers kunt doen:

• Cloudflare: Ga naar DNS → Records. Zoek het bestaande TXT-record voor uw domein (@ of root) dat begint met v=spf1. Klik op Bewerken. Voeg het nieuwe mechanisme toe vóór de tag all. Klik op Opslaan.
• GoDaddy: Ga naar Mijn producten → DNS → DNS-records. Zoek het TXT-record met v=spf1. Klik op Bewerken. Wijzig het veld Waarde zodat het nieuwe mechanisme vóór all staat. Sla op.
• Namecheap: Ga naar Domeinlijst → Beheren → Geavanceerde DNS. Zoek onder TXT-records de SPF-vermelding. Bewerk deze om het nieuwe mechanisme toe te voegen. Sla op.
• AWS Route 53: Open Hosted Zones → selecteer uw domein → zoek het TXT-record met v=spf1. Klik op Bewerken. Werk de waarde bij (houd de aanhalingstekens eromheen). Sla op.
• cPanel: Ga naar E-mailbezorgbaarheid → klik op Beheren naast uw domein → scroll naar Voorgesteld SPF-record → klik op Aanpassen. Voeg het nieuwe IP-adres toe in het gedeelte IP-adres. Klik op Installeren.

Stap 4: Controleer of je bijgewerkte SPF-record correct is

Eén verkeerd geplaatste spatie, een ontbrekende dubbele punt of een dubbel record kan er stilletjes voor zorgen dat de e-mail voor uw hele domein niet meer werkt. De controle duurt 30 seconden en bespaart u uren aan probleemoplossing.

Loop deze checklist na elke wijziging van de SPF door:

1. Controleer je domein met een SPF-checker en zorg ervoor dat het record foutloos wordt geparseerd.
2. Controleer of je slechts ÉÉN SPF-record ziet (en niet twee TXT-records die beginnen met v=spf1).
3. Controleer het totale aantal DNS-opzoekingen. Dit mag maximaal 10 zijn.
4. Controleer of het hele mechanisme helemaal aan het einde van de plaat staat.
5. Stuur een testmail naar een Gmail- of Yahoo-account, open het bericht, bekijk de originele headers en zoek naar spf=pass.

Voor een volledige beveiligingscontrole die verder gaat dan SPF, kunt u uw domein door de PowerDMARC-domeinanalysator halen. Deze controleert SPF, DKIM, DMARC, MTA-STS en BIMI in één keer.

Stap 5: Houd de resultaten van de SPF-verificatie in de loop van de tijd bij

Het toevoegen van het IP-adres is stap één. Nagaan of het daadwerkelijk werkt en opmerken wanneer het later niet meer werkt, is stap twee.

Geaggregeerde DMARC-rapporten zijn de belangrijkste manier om continu inzicht te krijgen in de slagings- en mislukkingspercentages van SPF per afzender. Zonder monitoring tast u in het duister. Veel beheerders ontdekken pas dat een SPF-record niet klopt als klanten legitieme e-mails als spam gaan markeren, of als een factureringstool wekenlang vanaf een niet-geautoriseerd IP-adres verstuurt zonder dat iemand dit opmerkt.

ip4 versus include: welke moet je gebruiken? (Keuzegids)

Wanneer moet je IPv4 gebruiken (ruwe IP-adressen):

• Je beheert je eigen mailserver op een statisch IP-adres waarover je zelf de controle hebt.
• Je beschikt over een eigen verzend-IP van een e-maildienstverlener (geen gedeelde IP).
• U geeft toestemming voor een lokaal SMTP-relay met een vast adres.

De regel: gebruik ip4: alleen als JIJ de IP beheert en deze niet zal veranderen.

Wanneer moet `include:` (gedelegeerde SPF) worden gebruikt:

• U geeft toestemming aan alle SaaS-diensten van derden, zoals Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk of andere cloudgebaseerde e-mailtools.
• De dienst maakt gebruik van gedeelde of wisselende IP-adressen.
• De dienst publiceert een eigen SPF-record dat hij zelf bijhoudt.

Waarom dit opnemen: is bijna altijd beter voor diensten van derden:

Clouddiensten wisselen regelmatig van IP-adres. Als je hun huidige IP-adressen met `ip4:` vastlegt, raakt je SPF-record verouderd wanneer ze hun infrastructuur verplaatsen en werkt je e-mail plotseling niet meer, zonder enige waarschuwing. 

Het 'include:'-mechanisme verwijst naar het eigen, dynamisch bijgewerkte SPF-record van de dienst. Wanneer zij hun IP-adressen bijwerken, worden deze wijzigingen automatisch doorgevoerd in uw SPF, zonder dat u daar iets voor hoeft te doen.

[Afbeelding: Beslissingsboom — „Is dit een server/IP-adres waarvan u eigenaar bent en waarover u de controle hebt?“ → JA → Gebruik ip4 / NEE → „Biedt de dienst een ‘include:’-waarde?“ → JA → Gebruik include (aanbevolen) / NEE → Gebruik ip4 + stel een herinnering in voor een driemaandelijkse controle]

[Alternatieve tekst: Beslissingsschema dat laat zien wanneer je in SPF-records het IPv4-mechanisme moet gebruiken en wanneer het 'include'-mechanisme]

Raadpleeg de volledige SPF -handleiding voor meer informatie over de include-syntaxis en aanbevolen werkwijzen.

Veelgebruikte SPF-waarden van derden (overzichtstabel)

Dankzij deze tabel hoef je niet meer voor elke dienst apart naar de SPF-documentatie te zoeken. Sla deze pagina op als bladwijzer voor als de marketingafdeling de volgende keer een nieuwe tool aanschaft.

Tabel: Overzicht van SPF-include-waarden voor populaire e-maildiensten. Controleer altijd de actuele waarde in de officiële documentatie van elke dienst, aangezien providers deze af en toe bijwerken.

Belangrijk: Elke include telt als minstens één DNS-lookup, en veel SPF-records van derden bevatten geneste includes die er nog meer toevoegen. Als u vijf of meer diensten gebruikt, nadert u waarschijnlijk de limiet van 10 lookups. Zie het volgende gedeelte voor hoe u hiermee om kunt gaan.

De limiet van 10 DNS-zoekopdrachten en wat u moet doen als u deze bereikt

RFC 7208 beperkt de SPF-beoordeling tot 10 mechanismen voor het opvragen van DNS-gegevens. De mechanismen die meetellen zijn: include, a, mx, redirect en exists. De mechanismen die NIET meetellen zijn: ip4, ip6 en all. Deze worden lokaal beoordeeld zonder een DNS-verzoek.

Als je record meer dan 10 lookups bevat, geeft SPF een PermError terug. Veel ontvangende servers beschouwen een PermError als een SPF-fout. De afleverbaarheid van je e-mail neemt af en je krijgt geen melding dat dit is gebeurd.

Er is ook een minder bekende beperking: de limiet van twee ongeldige zoekopdrachten. Als tijdens de SPF-evaluatie meer dan twee DNS-zoekopdrachten de foutmelding NXDOMAIN (domein niet gevonden) opleveren, mislukt de SPF-controle eveneens.

Hier zijn drie manieren om het op te lossen, gerangschikt op bruikbaarheid:

Optie 1: Verwijder ongebruikte mechanismen

Begin met een controle. Verwijder `include:`-verwijzingen voor diensten die u niet meer gebruikt. Verwijder `a`- en `mx`-records als u geen e-mail verstuurt vanaf de IP-adressen van de `a`- of `mx`-records van uw domein. Dit is de snelste oplossing en maakt vaak direct 2 tot 3 lookups vrij.

Optie 2: Handmatig SPF-afvlakken

Zet je `include:`-verwijzingen om naar hun onderliggende IP-adressen en voer deze handmatig in als `ip4:`-vermeldingen. Hierdoor worden de DNS-lookups die deze `include:`-verwijzingen anders zouden hebben veroorzaakt, overbodig.

Dit zorgt voor een voortdurende onderhoudslast. E-mailproviders wijzigen of breiden hun IP-reeksen uit zonder u hiervan op de hoogte te stellen. Wanneer ze dat doen, raakt uw afgevlakte record verouderd en worden legitieme e-mails niet meer afgeleverd. Het handmatig afvlakken van SPF is te vergelijken met het maaien van het gazon. Het werkt, maar u moet het om de paar weken opnieuw doen.

Optie 3: SPF-macro's of geautomatiseerd samenvoegen

De moderne aanpak maakt gebruik van SPF-macro’s (gedefinieerd in RFC 7208 §7), die tijdens de evaluatie dynamisch worden uitgewerkt, zodat uw record binnen de opzoeklimiet blijft zonder dat u handmatig IP-adressen hoeft bij te werken. 

Geautomatiseerde tools voor het opschonen van gegevens zorgen hier continu voor: ze herverificeren de IP-adressen van providers volgens een vast schema en werken uw gepubliceerde gegevens bij.

SPF alleen is niet genoeg: waarom DKIM en DMARC het plaatje compleet maken

SPF controleert of het IP-adres van de afzender (MAIL FROM) overeenkomt met uw lijst van geautoriseerde adressen. Dit werkt wanneer een e-mail rechtstreeks van de afzender naar de ontvanger wordt verzonden, maar wanneer een e-mail wordt doorgestuurd – via mailinglijsten, regels voor automatisch doorsturen, gedeelde mailboxen of een andere tussenliggende server – verandert het IP-adres van de afzender. SPF werkt dan niet meer, omdat het IP-adres van de doorstuurserver niet in uw SPF-record staat, en daar ook niet in hoort te staan.

DKIM (DomainKeys Identified Mail) werkt anders. Het voegt een cryptografische handtekening toe aan de tekst van de e-mail. Die handtekening blijft bij het bericht, ongeacht welke server het doorstuurt. DKIM blijft intact bij het doorsturen, maar SPF niet.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) brengt deze elementen samen. Er is slechts ÉÉN van SPF of DKIM nodig die voldoet en overeenkomt met uw ‘Van’-domein, zodat het bericht de DMARC-controle doorstaat. 

In de praktijk is DKIM het betrouwbaardere verificatiemechanisme, omdat het niet wordt beïnvloed door het doorsturen van e-mails.

Daarom is het belangrijk om beide te hebben:

• Google eist SPF of DKIM voor alle afzenders, en DMARC voor bulkverzenders (5.000+ berichten per dag). Vanaf november 2025 worden berichten die niet aan deze eisen voldoen definitief geweigerd.
• Microsoft is in mei 2025 begonnen met het weigeren van niet-geverifieerde bulk-e-mails.
• Yahoo hanteert dezelfde vereisten en hetzelfde tijdschema als Google.

Als SPF uw enige authenticatiemechanisme is, blijft uw domein kwetsbaar voor identiteitsfraude op elk doorstuurtraject van e-mail en voldoet u niet volledig aan de vereisten van e-mailproviders voor 2026.

Wat nu?

1. Stel DKIM in voor elke dienst die e-mails verstuurt vanuit uw domein.
2. Publiceer een DMARC-record (begin met p=none voor monitoring en ga daarna over op p=reject).
3. Houd de geaggregeerde DMARC-rapporten in de gaten om te zien welke bronnen de SPF- en DKIM-controle doorstaan of niet.

SPF-records voor domeinen die geen e-mail versturen

Als u domeinen bezit die geparkeerd, inactief of alleen voor websites worden gebruikt, hebben deze nog steeds SPF-beveiliging nodig. Aanvallers maken juist actief misbruik van ongebruikte domeinen omdat deze vaak onbeveiligd blijven.

De oplossing is simpel. Publiceer dit SPF-record:

v=spf1 - alle

Hiermee wordt aan ontvangende servers meegedeeld dat niemand bevoegd is om e-mail te versturen vanuit dit domein. Elk bericht dat beweert afkomstig te zijn van dit domein, moet worden geweigerd.

Voor optimale bescherming moet u ook een DMARC-record met een afwijzingsbeleid publiceren:

v=DMARC1; p=afwijzen; rua=mailto:[email protected]

Deze combinatie maakt een einde aan spoofing voor elk domein dat u bezit, of het nu e-mail verstuurt of niet.

Veelgemaakte fouten bij SPF en hoe je ze kunt oplossen

Syntaxfouten in SPF komen veel voor, en het ergste is dat ze geen foutmelding geven. Hieronder staan de acht meest voorkomende fouten, wat er gebeurt als je ze maakt en hoe je ze kunt oplossen:

Tabel: De meest voorkomende fouten in SPF-records, de gevolgen ervan en hoe je ze kunt oplossen.

Voor meer informatie over het oplossen van SPF-validatiefouten kun je onze handleiding raadplegen over SPF-validatiefouten en hoe je deze kunt verhelpen.

Conclusie

Het toevoegen van een IP-adres aan je SPF-record is een eenvoudige DNS-wijziging, maar om het goed te doen, moet je de syntaxis begrijpen, kiezen tussen `ip4:` en `include:`, binnen de limiet van 10 DNS-lookups blijven en het resultaat na elke wijziging controleren.

SPF vormt één onderdeel van een complete stack voor e-mailverificatie. In 2026, met Google, Yahoo en Microsoft allemaal actief de voorschriften voor afzenderverificatie handhaven, is SPF alleen niet meer voldoende. DKIM en DMARC zijn even essentieel voor volledige bescherming en naleving.

Naarmate uw organisatie meer verzenddiensten toevoegt, wordt uw SPF-record steeds omvangrijker. Handmatig beheer is niet schaalbaar en één enkele fout kan er stilletjes voor zorgen dat e-mails in uw hele domein niet meer worden afgeleverd. Geautomatiseerd SPF-beheer is geen luxe meer. Het is een kwestie van operationele hygiëne.

Beheer SPF-records niet langer handmatig. PowerDMARC biedt u geautomatiseerde SPF-flattening (PowerSPF), DMARC-monitoring, DKIM-beheer en overzichtelijke rapportages voor al uw domeinen, allemaal op één platform. Start uw gratis proefperiode van 15 dagen 

Veelgestelde Vragen

1) Kan ik twee SPF-records op hetzelfde domein hebben?

Nee. RFC 7208 schrijft precies één SPF TXT-record per domein voor. Als een domein twee records heeft die beginnen met v=spf1, geven ontvangende servers een PermError terug en beschouwen ze SPF voor elk bericht als mislukt. Als u extra bronnen wilt autoriseren, pas dan uw bestaande record aan om deze toe te voegen; maak geen nieuw record aan.

2) Wat is het verschil tussen -all en ~all?

-all is een harde afwijzing: hiermee wordt ontvangende servers opgedragen e-mail van niet-geautoriseerde IP-adressen te weigeren. ~all is een zachte afwijzing: hiermee wordt niet-geautoriseerde e-mail gemarkeerd, maar wordt weigering niet verplicht gesteld. In de praktijk is het verschil minimaal wanneer DMARC wordt afgedwongen met p=quarantine of p=reject, omdat het DMARC-beleid voorrang heeft op de SPF-kwalificatie. Als u DMARC al afdwingt, werken beide opties. Als u nog geen DMARC gebruikt, biedt -all een betere bescherming.

3) Hoeveel IP-adressen kan ik aan een SPF-record toevoegen?

Er geldt geen strikte limiet voor het aantal ip4: of ip6:-mechanismen. Deze tellen niet mee voor de limiet van 10 DNS-lookups. Het totale SPF-record moet echter wel binnen de maximale lengte van een DNS TXT-record blijven (255 tekens per tekenreeks, waarbij meerdere tekenreeksen kunnen worden samengevoegd tot maximaal ongeveer 4.096 tekens). Gebruik voor grote IP-lijsten CIDR-notatie (bijv. ip4:192.0.2.0/24) om bereiken efficiënt te dekken.

4) Hoe lang duurt het voordat de SPF-aanpassingen effect sorteren?

Dat hangt af van de TTL (Time to Live) van je DNS-record. Als je TTL 3600 (1 uur) is, zullen de meeste resolvers de wijziging binnen 1 uur doorvoeren. Om het proces te versnellen: verlaag je TTL naar 300 (5 minuten) voordat je wijzigingen aanbrengt, wacht tot de oude TTL-periode is verstreken en breng dan je wijziging aan. Dit verkort de propagatietijd aanzienlijk.

5) Hoe kom ik erachter welke IP-adressen momenteel e-mails versturen vanuit mijn domein?

De meest betrouwbare methode is DMARC-rapportage. Wanneer u een DMARC-record met een rua-tag publiceert, sturen ontvangende servers dagelijks geaggregeerde rapporten waarin alle IP-adressen worden vermeld die hebben geprobeerd e-mail te verzenden vanaf uw domein, samen met de resultaten van de SPF- en DKIM-controles (geslaagd/mislukt). Zonder DMARC blijft het giswerk. PowerDMARC verwerkt deze rapporten tot overzichtelijke, begrijpelijke dashboards, zodat u precies kunt zien wie er namens uw domein e-mails verstuurt.

6) Tellen IPv4- en IPv6-mechanismen mee voor de limiet van 10 DNS-opzoekingen?

Nee. Alleen mechanismen waarvoor een DNS-query nodig is, tellen mee voor de limiet: include, a, mx, redirect en exists. De mechanismen ip4, ip6 en all worden lokaal verwerkt en verbruiken geen DNS-lookups.

• Over
• Laatste berichten

Ahona Rudra

Expert domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

• Hoe voeg je een IP-adres toe aan je SPF-record (stapsgewijze handleiding) - 11 mei 2026
• Avanan SPF-record: hoe u uw SPF voor Check Point Harmony Email instelt, repareert en optimaliseert - 7 mei 2026
• DNS SPF-record: hoe het werkt en hoe je het instelt - 6 mei 2026