DNS SPF-record: hoe het werkt en hoe je het instelt

Elke e-mail die uw organisatie verstuurt, draagt de reputatie van uw domein met zich mee. Als uw SPF-record verkeerd is geconfigureerd of helemaal ontbreekt, kunnen ontvangende servers niet op betrouwbare wijze controleren of de e-mail daadwerkelijk van u afkomstig is. Legitieme e-mails belanden in de spamfolder. Marketingcampagnes worden teruggestuurd. Aanvallers versturen berichten die lijken alsof ze van uw domein afkomstig zijn.

SPF (Sender Policy Framework) is een van de drie belangrijkste protocollen voor e-mailverificatie , naast DKIM en DMARC, die ontvangende mailservers aangeeft welke IP-adressen bevoegd zijn om e-mail namens uw domein te verzenden. Het wordt gepubliceerd als een DNS TXT-record. Op het eerste gezicht lijkt het eenvoudig. In de praktijk is SPF echter de bron van de meeste problemen met e-mailverificatie. 

In deze handleiding wordt precies uitgelegd wat een SPF-record is, hoe SPF-verificatie stap voor stap werkt, hoe je er een aanmaakt en hoe je de meest voorkomende SPF-fouten kunt verhelpen, waaronder de limiet van 10 DNS-lookups die bij groeiende organisaties ongemerkt de e-mailbezorging verstoort.

Wat is een DNS SPF-record?

Een DNS SPF-record (Sender Policy Framework) is een soort DNS TXT-record dat aangeeft welke mailservers bevoegd zijn om e-mails namens uw domein te verzenden. Het helpt ontvangende mailservers te controleren of inkomende berichten afkomstig zijn van legitieme bronnen, waardoor het risico op spoofing en phishing wordt verminderd. Wanneer een e-mail wordt ontvangen, controleert de server het SPF-record van het domein van de afzender om te verifiëren of het verzendende IP-adres is toegestaan. 

Als het IP-adres niet in de lijst staat, kan het bericht worden gemarkeerd, geweigerd of naar de spamfolder worden verplaatst. Door een SPF-record correct in te stellen, verbetert u de afleverbaarheid van e-mails en versterkt u de domeinverificatie.

Je kunt het SPF-record van je domein direct controleren met een gratis SPF-opzoektool. Het duurt vijf seconden en laat u precies zien wat er in uw DNS is gepubliceerd.

Hoe werkt SPF-authenticatie?

Bij SPF-authenticatie wordt telkens wanneer een e-mail wordt ontvangen een gestructureerd DNS-opzoek- en validatieproces doorlopen:

• Uw domein publiceert een SPF-record als een DNS TXT-vermelding. Dit record definieert alle geautoriseerde afzenders met behulp van mechanismen zoals ip4, ip6, include, en een, samen met een standaardbeleid (-all, ~all, of ?all).
• Wanneer een e-mail wordt verzonden, voegt de verzendende server een Return-Path-adres (afzender van de envelop) toe dat verwijst naar het domein dat verantwoordelijk is voor de bezorging.
• De ontvangende mailserver haalt het domein uit het Return-Path-adres.
• Het voert een DNS-query uit om het SPF-record op te halen dat aan dat domein is gekoppeld.
• Het IP-adres van de verzendende server wordt vervolgens getoetst aan elk mechanisme in het SPF-record en in volgorde verwerkt totdat er een overeenkomst wordt gevonden of een beleidsbeslissing wordt genomen.
• SPF hanteert tijdens deze evaluatie een limiet van 10 DNS-opzoekingen om overmatige recursie te voorkomen; overschrijding van deze limiet leidt tot een PermError.
• Afhankelijk van de uitkomst retourneert SPF een resultaat zoals Pass, Fail, SoftFail, Neutral, None, PermError of TempError.
• De ontvangende server gebruikt dit resultaat, in combinatie met DKIM-verificatie en naleving van het DMARC-beleid, om te bepalen hoe het bericht moet worden behandeld (bezorgen, in quarantaine plaatsen of weigeren).

Een belangrijk detail: SPF controleert het Return-Path-domein (de afzender van de envelop), niet de zichtbare From-header. Als deze domeinen van elkaar verschillen, wat vaak het geval is bij verzendplatforms van derden, kan SPF weliswaar slagen, maar kan de DMARC-afstemming mislukken, wat direct invloed heeft op de plaatsing in de inbox.

Elke SPF-resultaatcode heeft een specifieke praktische betekenis:

DMARC-overzichtsrapporten laten precies zien welke e-mails de SPF-controle doorstaan en welke niet, voor al uw verzendbronnen. Zonder DMARC-rapportage vinden SPF-fouten in stilte plaats en weet u het pas als er een klacht binnenkomt.

Uitleg over de syntaxis en het formaat van SPF-records

Om de SPF-syntaxis te begrijpen, moet je eerst een volledig record doorlezen en weten hoe elk onderdeel wordt geïnterpreteerd. Hier volgt een typisch voorbeeld:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (waarbij /24 een reeks van 256 IP-adressen vertegenwoordigt volgens de Classless Inter-Domain Routing (CIDR)-notatie)

Deze enkele regel geeft ontvangende servers precies aan welke afzenders e-mail mogen versturen namens uw domein en wat ze moeten doen als een afzender niet in de lijst staat.

SPF-versietag (v=spf1)

Elk SPF-record moet beginnen met v=spf1. Dit identificeert het TXT-record als een SPF-beleid. Er zijn geen andere geldige versies. Als deze tag ontbreekt of onjuist is, wordt het record volledig genegeerd.

SPF-mechanismen (geautoriseerde afzenders) 

Mechanismen bepalen wie e-mail mag versturen. Ze worden van links naar rechts doorlopen, en de eerste overeenkomst is bepalend voor het resultaat.

De omvatten: mechanisme wordt het meest gebruikt en veroorzaakt de meeste problemen. Elke include: leidt tot een recursieve DNS-lookup. Als het SPF-record van Google drie andere domeinen bevat, tellen die allemaal mee voor je limiet van 10 lookups.

Een veelvoorkomend punt van verwarring: de een mechanisme in SPF verwijst naar het DNS A-record van het domein. Het maakt geen apart “A-record voor SPF” aan. Wanneer u een aan je SPF-record toevoegt, geef je toestemming aan alle IP-adressen waarnaar het A-record van je domein verwijst.

Modificatoren (redirect=)

Modifiers bepalen hoe de SPF-beoordeling verloopt, in plaats van afzenders te definiëren.

• redirect=
  Verplaatst de volledige SPF-evaluatie naar een ander domein. In tegenstelling tot include:, dat een een ander beleid aan uw record toe, vervangt vervangt uw evaluatie volledig.
  Gebruik dit alleen wanneer het ene domein de SPF-configuratie van een ander domein volledig moet overnemen.

Limiet voor DNS-opzoekingen (kritieke beperking)

SPF staat maximaal 10 DNS-opzoekingen per evaluatie toe. Mechanismen zoals zijn onder andere:, een, mx, bestaat:, en redirect= tellen allemaal mee voor deze limiet.

Als de limiet wordt overschreden, retourneert SPF een PermError en mislukt de authenticatie, zelfs als de afzender legitiem is. Daarom moeten grote, complexe records vaak worden geoptimaliseerd (bijvoorbeeld door ongebruikte includes te verwijderen of de structuur te vereenvoudigen).

SPF-kwalificaties (het ‘all’-mechanisme)

De voorwaarde op de het mechanisme aan het einde van uw SPF-record definieert uw SPF-beleid – wat er gebeurt met e-mail van servers die niet expliciet worden vermeld:

SPF werkt als een reeks logische regels. De ontvangende server leest je record van links naar rechts, controleert elk mechanisme en stopt bij de eerste overeenkomst. Als er geen overeenkomst wordt gevonden, wordt de alle regel.

Een goed gestructureerd SPF-record is:

• Volledig (inclusief alle legitieme afzenders)
• Efficiënt (binnen de opzoeklimieten)
• Strikt (met -all na validatie)

Dit zorgt voor een nauwkeurige authenticatie en voorkomt ongeoorloofd gebruik van uw domein voor het versturen van e-mails.

Een SPF-record aanmaken en publiceren

Om een SPF-record in te stellen, moet u alle legitieme afzenders identificeren, deze duidelijk in het DNS definiëren en controleren of de configuratie naar behoren werkt. Volg de onderstaande 5 stappen in de aangegeven volgorde.

Stap 1: Breng al je verzendbronnen in kaart

Maak een lijst van alle diensten die namens uw domein e-mails versturen. Hieronder vallen doorgaans uw primaire e-mailprovider (zoals Google Workspace of Microsoft 365), marketingplatforms (zoals Mailchimp of HubSpot), CRM-systemen (Salesforce), supporttools (Zendesk) en diensten voor transactionele e-mail (SendGrid, Amazon SES). Elk van deze diensten verstuurt e-mail via een andere infrastructuur, dus ze moeten allemaal expliciet worden geautoriseerd. De meeste providers publiceren een SPF-include-waarde in hun documentatie, die ontvangende servers vertelt dat ze hun verzendende IP-adressen kunnen vertrouwen.

Stap 2: Maak je SPF-record aan

Een SPF-record is een TXT-vermelding van één regel die begint met v=spf1. Vervolgens definieer je geautoriseerde afzenders met behulp van de volgende mechanismen:

• bijvoorbeeld: voor diensten van derden (bijv. include:_spf.google.com)
• ip4: of ip6: voor specifieke IP-adressen of reeksen die u beheert
  Mechanismen worden van links naar rechts geëvalueerd. Aan het einde definieert u een beleid:
• ~all (zachte fout) markeert niet-geautoriseerde afzenders als verdacht
• -all (hardfail) wijst ze expliciet af

Een voorbeeld:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Dit bestand geeft ontvangende servers precies aan welke bronnen zijn toegestaan en hoe ze met al het andere moeten omgaan.

Stap 3: Publiceer het record in DNS

Log in bij je DNS-provider (zoals Cloudflare, Route 53 of GoDaddy). Maak een nieuw TXT-record aan voor je hoofddomein:

• Host/Naam: @ (of laat leeg, afhankelijk van de provider)
• Waarde: je volledige SPF-record
  Zodra het record is opgeslagen, wordt het via DNS openbaar toegankelijk. Het kan even duren voordat wijzigingen zijn doorgevoerd.

Stap 4: Controleer het record

Controleer na het publiceren of:

• Het SPF-record is correct opgemaakt (geen syntaxfouten)
• Alles wordt correct afgehandeld
• Het totale aantal DNS-zoekopdrachten mag de limiet van 10 niet overschrijden (bij overschrijding mislukt de SPF-controle met een PermError)

Validatie zorgt ervoor dat ontvangende servers uw record foutloos en betrouwbaar kunnen verwerken.

Stap 5: Controleer de SPF-resultaten

SPF is geen eenmalige instelling. Wanneer u verzendbronnen toevoegt of verwijdert, moet uw SPF-record worden bijgewerkt. Om de prestaties te controleren:

• Inschakelen DMARC om geaggregeerde rapporten te ontvangen met de slagings- en mislukkingspercentages van SPF
• Controleer welke bronnen de authenticatie doorstaan of niet doorstaan
• Verwijder ongebruikte diensten en corrigeer verkeerd gekoppelde of ongeautoriseerde afzenders

Belangrijk: Er is slechts één SPF-record per domein toegestaan. Als er meerdere TXT-records zijn die beginnen met v=spf1 bestaan, mislukt de SPF-evaluatie volledig met een PermError. Voeg altijd alle verzendbronnen samen tot één enkel, volledig record.

De limiet voor SPF 10-DNS-lookups (en waarom dit je e-mail verstort)

De SPF-controle kent een limiet. Volgens RFC 7208 mag een ontvangende server maximaal 10 DNS-lookups uitvoeren tijdens het verwerken van je SPF-record. Als deze limiet wordt overschreden, retourneert SPF een PermError (permanente fout) en mislukt de controle volledig.

Dit is geen gedeeltelijke fout. Een PermError betekent dat SPF helemaal niet kan worden geëvalueerd. Daardoor voldoet geen enkele e-mail die vanaf uw domein wordt verzonden aan de SPF-authenticatie, ongeacht of de afzender legitiem is.

Wat telt mee voor de limiet van 10 zoekopdrachten?

De volgende mechanismen leiden tot DNS-opzoekingen:

• waaronder: (de meest voorkomende en meest ingrijpende)
• a
• mx
• ptr (verouderd, maar telt nog steeds mee als het wordt gebruikt)
• bestaat:
• omleiden=

De mechanismen `ip4:` en `ip6:` tellen niet mee voor de opzoeklimiet, omdat ze rechtstreeks naar IP-adressen verwijzen en er geen DNS-resolutie nodig is

Waarom deze limiet gemakkelijk wordt overschreden

Het grootste probleem komt voort uit geneste (recursieve) zoekopdrachten.

Wanneer je een `include:` toevoegt, voeg je niet alleen één lookup toe, maar neem je ook alles over wat in het SPF-record van die provider staat.

Bijvoorbeeld:

• Als je Google toevoegt, kan het SPF-record van Google ook meerdere andere domeinen bevatten
• Als je Microsoft 365 toevoegt → worden er nog een aantal zoekopdrachten toegevoegd
• Je neemt marketing- en transactietools op → elk voegt zijn eigen keten toe

Deze tellen snel op. Zelfs als je record er kort uitziet, kan het werkelijke aantal opzoekingen tijdens de evaluatie hoger zijn dan 10.

De limiet van 2 "void lookup"-opdrachten (die vaak over het hoofd wordt gezien)

SPF hanteert ook een limiet van 2 ongeldige zoekopdrachten.

Er is sprake van een 'void lookup' wanneer een DNS-verzoek geen resultaat oplevert (Non-Existent Domain (NXDOMAIN) of een leeg antwoord).

Veel voorkomende oorzaken:

• Voorbeelden van onjuiste of verouderde gegevens zijn: domeinnamen
• Typefouten in SPF-mechanismen
• Verwijzingen naar domeinen die niet meer bestaan

Als er meer dan twee ongeldige zoekopdrachten plaatsvinden, retourneert SPF opnieuw een PermError.

A PermError betekent niet "mislukt voor sommige afzenders". Het betekent:

• SPF wordt als ongeldig beschouwd
• Ontvangende servers kunnen uw SPF-beleid niet vertrouwen
• SPF biedt in feite geen bescherming of authenticatie

Aangezien SPF een van de signalen is die door DMARC worden gebruikt, kan dit ook leiden tot:

• DMARC-fouten (als DKIM niet overeenkomt)
• Toename van het aantal spam-advertenties
• Weigering van berichten door strengere ontvangers

Naarmate je e-mailsysteem groeit, wordt je SPF-record vanzelf complexer. Zonder actief beheer:

• Het aantal zoekopdrachten neemt ongemerkt toe
• Niet-gebruikte diensten blijven in het dossier staan
• Fouten stapelen zich in de loop van de tijd op

SPF is in dat opzicht kwetsbaar. Het werkt alleen betrouwbaar als de gegevens binnen bepaalde grenzen blijven, nauwkeurig zijn en voortdurend worden bijgewerkt.

Hoe snel je de limiet bereikt (praktijkvoorbeeld)

Zo ziet een typische SaaS-stack voor het middensegment eruit wat betreft DNS-lookups:

Je hebt Zendesk, SendGrid, je helpdesk of je salarisadministratie nog niet eens toegevoegd. Als je organisatie Google Workspace gebruikt in combinatie met vier of vijf SaaS-tools die e-mails versturen, zit je op dit moment waarschijnlijk al aan de limiet of heb je die zelfs al overschreden.

Problemen met de limiet voor SPF-opzoekingen oplossen

Als uw SPF-record de limiet van 10 DNS-lookups overschrijdt, moet u de complexiteit verminderen zonder legitieme afzenders te blokkeren. Dit zijn de drie praktische benaderingen, gerangschikt naar impact:

Verwijder overbodige mechanismen

Begin met een grondige controle van uw SPF-record.

• Geef alle inclusief: en mechanisme dat momenteel wordt vermeld
• Controleer of elke dienst nog steeds actief e-mails verstuurt voor uw domein
• Verwijder alles wat niet meer wordt gebruikt

Veel voorkomende problemen:

• Oude marketinginstrumenten die in het archief zijn achtergebleven
• Dubbele vermeldingen in subdomeinen
• Test- of tijdelijke diensten zijn nooit opgeruimd

Elke ongebruikte include: die je verwijdert, maakt onmiddellijk een of meer DNS-lookups vrij. Dit is de eenvoudigste en minst risicovolle manier om weer onder de limiet te komen.

Vervang inclusief: door ip4:/ip6: waar mogelijk

Als een afzender een vaste en beperkte reeks IP-adressen gebruikt, kun je de opnemen: door directe IP-vermeldingen.

• Voorbeeld: vervang include:vendor.com door ip4:x.x.x.x
• Hierdoor worden DNS-opzoekingen voor die afzender volledig uitgeschakeld

Wanneer dit goed werkt:

• Interne infrastructuur
• Vaste IP-adressen van een provider
• Leveranciers met duidelijk gedocumenteerde, stabiele IP-reeksen

Afweging die moet worden gemaakt:

• Je neemt de verantwoordelijkheid voor het onderhoud op je
• Als de provider IP-adressen bijwerkt of wisselt, raakt je SPF-record verouderd
• Dit kan leiden tot onopgemerkte SPF-fouten totdat het probleem is verholpen

Gebruik dit alleen wanneer de IP-stabiliteit voorspelbaar is.

Gebruik SPF-afvlakking of SPF-macro's

Als je gebruikmaakt van meerdere diensten van derden, is handmatig opschonen alleen meestal niet voldoende. Je hebt een manier nodig om het aantal zoekopdrachten te verminderen zonder dat dit ten koste gaat van de dekking.

SPF-afvlakking

• Omvat onder meer inclusief: mechanismen in hun onderliggende IP-adressen
• Vervangt ze door een platte lijst met ip4: / ip6: vermeldingen
• Elimineert de meeste DNS-zoekopdrachten

Beperking:

• Geprepareerde records zijn statisch
• Als een provider (zoals Google of Microsoft) zijn verzend-IP-adressen bijwerkt, wordt je record niet automatisch bijgewerkt
• Hierdoor ontstaat een lacune waardoor legitieme e-mails zonder waarschuwing de SPF-controle kunnen mislukken

SPF-macro's (dynamisch alternatief)

• Zorg ervoor dat de SPF-evaluatie dynamisch blijft en houd tegelijkertijd de opzoekdiepte onder controle
• Verminder de afhankelijkheid van lange include-ketens
• Beter geschikt voor omgevingen met een afzenderinfrastructuur die regelmatig verandert

Weet je niet precies hoeveel lookups je SPF-record gebruikt? Controleer het aantal lookups met onze gratis SPF-checker

Voor organisaties die binnen de limiet van 10 zoekopdrachten moeten blijven zonder handmatig DNS-beheer, biedt PowerDMARC’s PowerSPF biedt zowel traditionele afvlakkende en moderne SPF-macro's, zodat u de techniek kunt kiezen die bij uw omgeving past. Het record wordt automatisch bijgewerkt wanneer externe providers hun geautoriseerde IP-bereiken wijzigen.

Waarom SPF alleen niet voldoende is

SPF is een fundamentele authenticatiemethode, maar is niet ontworpen om volledige bescherming te bieden tegen moderne vormen van spoofing en misbruik. Het kent drie belangrijke beperkingen waardoor het op zichzelf onvoldoende is.

Beperking 1: SPF controleert de afzender van de envelop, niet de From-header

SPF controleert het Return-Path (de afzender van de envelop), het domein dat bij het verzenden van de e-mail wordt gebruikt. Gebruikers zien echter de From-header, die afwijkend kan zijn.

Hierdoor ontstaat een kwetsbaarheid die aanvallers kunnen misbruiken:

• Een aanvaller verstuurt een e-mail vanaf zijn eigen domein (dat de SPF-controle doorstaat)
• Ze stellen het zichtbare afzenderadres zo in dat het wordt weergegeven als uw domein of als een vertrouwde persoon
• SPF wordt goedgekeurd omdat het verzendende domein legitiem is
• De ontvanger ziet nog steeds een vervalste identiteit

SPF biedt geen ingebouwde manier om te controleren of het verzendende domein overeenkomt met de zichtbare afzender. DMARC lost dit op door de afstemming tussen SPF (of DKIM) en het domein in de From-header af te dwingen.

Beperking 2: SPF-verificatie mislukt bij het doorsturen van e-mails

SPF is afhankelijk van het IP-adres van de verzendende server. Wanneer een e-mail wordt doorgestuurd:

• De doorstuurserver wordt de nieuwe afzender
• Het IP-adres wordt vergeleken met het SPF-record van het oorspronkelijke domein. Aangezien de doorstuurserver niet als geautoriseerde afzender is vermeld, mislukt de SPF-controle.
• Omdat het niet in de lijst staat, mislukt de SPF-controle

Dit gebeurt zelfs als de e-mail volkomen legitiem is. Het is geen configuratiefout, maar een beperking van de werking van SPF.

Gevolgen:

• Legitieme doorgestuurde e-mails slagen vaak niet voor de SPF-controle
• Ontvangstsystemen moeten zich baseren op andere signalen (zoals DKIM) om het bericht te valideren

Beperking 3: SPF beschikt op zichzelf niet over een rapportagemechanisme

SPF biedt geen ingebouwde rapportagefuncties.

Zonder extra laag:

• Je weet niet welke bronnen de SPF-controle doorstaan of niet
• Je kunt geen onbevoegde afzenders detecteren die jouw domein gebruiken
• U hebt geen inzicht in authenticatieproblemen die de afleverbaarheid beïnvloeden

DMARC biedt rapportagemogelijkheden, waardoor u geaggregeerde gegevens krijgt over de SPF- en DKIM-resultaten bij alle ontvangers.

De moderne e-mailinfrastructuur, met doorsturen, mailinglijsten, externe afzenders en geavanceerde spoofing, is de mogelijkheden van SPF alleen ontgroeid. DKIM voegt een cryptografische handtekening toe die doorsturen overleeft, waardoor de grootste zwakte van SPF wordt opgelost. DMARC is de beleidslaag die SPF en DKIM koppelt aan de From-header.

Voor een volledig overzicht van hoe deze protocollen samenwerken, zie onze gids over SPF versus DKIM versus DMARC.

Veelvoorkomende fouten bij SPF-records (en hoe je ze kunt oplossen)

De meeste SPF-fouten komen neer op een paar terugkerende problemen. Het ligt meestal aan een gebrek aan onderhoud en validatie. Hieronder lees je hoe je deze problemen kunt opsporen en oplossen met duidelijke stappen.

Fout 1: Meerdere SPF-records op hetzelfde domein.

SPF vereist één enkel, gezaghebbend beleid. Als meerdere TXT-records beginnen met v=spf1, kunnen ontvangende servers niet bepalen welke ze moeten evalueren. Het resultaat is een PermError, wat betekent dat SPF volledig faalt voor elk bericht.

Waarom dit gebeurt:

• Verschillende teams voegen zelfstandig records toe (marketing, IT, ondersteunende tools)
• Nieuwe leveranciers geven instructies om ‘dit record toe te voegen’ zonder de bestaande configuratie te controleren

Hoe het te repareren:

• Controleer alle TXT-records voor uw domein
• Zoek alle vermeldingen met betrekking tot SPF
• Breng alle mechanismen samen in één volledig overzicht

Waar je op moet letten:

• Gedeeltelijke gegevens die na migraties zijn achtergebleven
• Subdomeinen die ten onrechte in plaats van het hoofddomein worden gebruikt 

Fout 2: De limiet van 10 DNS-zoekopdrachten overschrijden

Zodra de SPF-controle meer dan 10 DNS-opzoekingen heeft uitgevoerd, wordt deze onmiddellijk gestopt en wordt er een PermError geretourneerd. Hierdoor wordt de SPF-verificatie voor alle afzenders ongeldig, zelfs voor legitieme afzenders.

Waarom dit gebeurt:

• Voorbeelden van overmatig gebruik omvat: voor meerdere SaaS-tools
• Geneste includes van providers (jij neemt ze op, zij nemen weer andere op)
• Geen inzicht in het totale aantal zoekopdrachten

Hoe het te repareren:

• Breng elk mechanisme en de gevolgen daarvan voor het opzoeken in kaart
• Verwijder eerst ongebruikte of overbodige includes
• Ga nog eens na of elk programma echt vanaf uw domein moet verzenden

Waar je op moet letten:

• "Verborgen" opzoekingen in inclusies van derden
• Een geleidelijke uitbreiding in de loop van de tijd naarmate er nieuwe tools worden toegevoegd

Fout 3: Het gebruik van +all (alles doorgeven)

Hiermee wordt aan ontvangende servers expliciet aangegeven dat ze elke afzender mogen vertrouwen, waardoor SPF in feite als beveiligingsmaatregel wordt uitgeschakeld.

Waarom dit gebeurt:

• Verkeerde interpretatie van de SPF-syntaxis
• Tijdelijke testconfiguraties zijn nooit teruggedraaid

Hoe het te repareren:

• Vervang door ~alles terwijl je je configuratie valideert
• Ga naar -alle zodra alle legitieme afzenders zijn bevestigd

Waar je op moet letten:

• Oude documenten die zijn overgenomen uit onbetrouwbare bronnen
• Domeinen die als "geverifieerd" worden weergegeven, maar geen daadwerkelijke bescherming bieden

Fout 4: Het gebruik van de verouderde ptr mechanisme

Mechanismen zoals ptr zorgen voor trage, onbetrouwbare lookups en kunnen door moderne ontvangers worden genegeerd, wat leidt tot inconsistente SPF-resultaten.

Waarom dit gebeurt:

• Oude configuraties die in de loop der tijd zijn overgenomen
• Verouderde documentatie of sjablonen

Hoe het te repareren:

• Verwijder verouderde mechanismen zoals ptr
• Vervang door expliciet include: of ip4: / ip6: vermeldingen

Waar je op moet letten:

• Overdreven gedetailleerde records die rekening proberen te houden met uitzonderingsgevallen
• Mechanismen die de complexiteit vergroten zonder duidelijk voordeel

Fout 5: Ontbrekende legitieme afzenders

E-mails van legitieme platforms slagen niet voor de SPF-controle, wat kan leiden tot:

• Berichten die in de spamfolder terechtkomen
• Vertragingen bij de levering of weigeringen
• DMARC-fouten als er geen afgestemde fallback bestaat

Waarom dit gebeurt:

• Er zijn nieuwe tools toegevoegd zonder SPF bij te werken
• Gebrek aan afstemming tussen de teams die de e-mailsystemen beheren

Hoe het te repareren:

• Houd een centrale lijst bij van alle goedgekeurde verzendbronnen
• Neem SPF-vermeldingen op als onderdeel van het onboardingproces – niet pas als er problemen optreden
• Controleer regelmatig of alle actieve afzenders zijn opgenomen

Waar je op moet letten:

• Transactiesystemen (facturering, meldingen) worden vaak over het hoofd gezien
• Regionale of teamspecifieke tools die zelfstandig worden verzonden

Fout 6: SPF-record met meer dan 255 tekens in één DNS-string

SPF-records die de DNS-limieten overschrijden of een onjuiste indeling hebben, kunnen worden afgekapt of verkeerd geïnterpreteerd, wat tot onopgemerkte fouten kan leiden.

Waarom dit gebeurt:

• Te veel `INCLUDE`-opdrachten en mechanismen in één record
• DNS-providers gaan verschillend om met lange TXT-waarden

Hoe het te repareren:

• Houd het verslag zo beknopt mogelijk
• Gebruik indien nodig meerdere tekenreeksen tussen aanhalingstekens binnen één TXT-record
• Controleer het gepubliceerde record nogmaals na het opslaan (niet alleen de invoer)

Waar je op moet letten:

• Records die er in je DNS-paneel correct uitzien, maar niet goed worden omgezet
• Opmaakfouten die zijn ontstaan tijdens handmatige bewerkingen

Voer een gratis SPF-controle uit om te zien of je record een van deze fouten bevat

SPF-aanbevelingen voor 2026

Een correct SPF-record draait niet alleen om de syntaxis. Het gaat erom een beleid te hanteren dat actueel blijft naarmate uw e-mailinfrastructuur zich ontwikkelt. Deze best practices helpen ervoor te zorgen dat uw SPF-configuratie betrouwbaar en efficiënt blijft en voldoet aan de huidige eisen voor afzenders.

1. Zorg ervoor dat er per domein slechts één SPF-record is

SPF staat slechts één TXT-record toe dat begint met v=spf1. Meerdere records veroorzaken een PermError, waardoor de authenticatie volledig wordt onderbroken. Voeg nieuwe vermeldingen altijd samen met uw bestaande record.

2. Vermeld alle legitieme afzenders

Uw SPF-record moet alle systemen bevatten die namens u e-mails versturen. Als er een afzender ontbreekt, leidt dit tot SPF-fouten, wat directe gevolgen heeft voor de afleverbaarheid en de DMARC-conformiteit.

3. Houd je aan de limiet van 10 DNS-zoekopdrachten

Elk bevat:, een, mx, bestaat:, en redirect= telt mee voor de limiet. Bij meer dan 10 wordt een PermError gegenereerd, waardoor SPF voor alle e-mails ongeldig wordt. Controleer en optimaliseer uw record regelmatig.

4. Verwijder ongebruikte of verouderde includes

Oude tools, testomgevingen en verouderde diensten blijven vaak nog lang in SPF-records staan nadat ze al niet meer verzenden. Dit zorgt voor onnodige complexiteit en verbruikt een deel van het opzoekbudget.

5. Geef de voorkeur aan ip4: en ip6: voor gecontroleerde infrastructuur

Als u vaste IP-adressen of stabiele verzendbereiken beheert, gebruik dan mechanismen voor directe IP-adressen in plaats van inclusief:. Dit vermindert het aantal DNS-lookups en verbetert de prestaties.

6. Vermijd het gebruik van +all in geen geval

De +all kwalificatie staat elke server toe om namens uw domein te verzenden, waardoor SPF in feite als beveiligingsmaatregel wordt uitgeschakeld. Deze mag nooit in productieomgevingen worden gebruikt.

7. Gebruik ~alle tijdens de installatie, ga vervolgens naar -all

Begin met ~all (softfail) tijdens het valideren van je configuratie. Zodra alle legitieme afzenders zijn bevestigd en in overeenstemming zijn met DMARC, schakel je over naar -all (hardfail) voor strikte handhaving.

8. Vermijd verouderde of risicovolle mechanismen zoals ptr

De ptr mechanisme is verouderd en onbetrouwbaar. Het veroorzaakt onnodige DNS-lookups en kan door moderne ontvangers worden genegeerd. Gebruik in plaats daarvan expliciete mechanismen.

9. Houd de SPF-prestaties bij met DMARC-rapporten

SPF biedt op zichzelf geen inzicht. Schakel DMARC-rapportage in om bij te houden welke bronnen bij alle ontvangers de SPF-controle doorstaan of niet, en om ongeoorloofde activiteiten op te sporen.

10. Beschouw SPF als een systeem dat voortdurend wordt beheerd

SPF is geen eenmalige instelling. Elk nieuw programma, platform of elke nieuwe leverancier die e-mails verstuurt, moet in uw SPF-record worden opgenomen. Controleer en werk het regelmatig bij om onopgemerkte fouten te voorkomen.

Hoe SPF samenwerkt met DKIM en DMARC

SPF, DKIM en DMARC zijn ontworpen om als een gecoördineerd systeem te functioneren. Elk van deze protocollen pakt een ander aspect van het vertrouwensprobleem bij e-mail aan, zoals de legitimiteit van de afzender, de integriteit van het bericht en de afstemming van identiteiten, en alleen samen bieden ze betrouwbare bescherming en handhaving.

Wanneer er een e-mail binnenkomt, vindt de authenticatie in verschillende fasen plaats:

• SPF controleert of het IP-adres van de verzendende server is geautoriseerd voor het domein in het Return-Path (afzender van de envelop)
• DKIM controleert een cryptografische handtekening die aan het bericht is toegevoegd, om te bevestigen dat het bericht niet is gewijzigd en dat het ondertekenende domein geldig is
• DMARC beoordeelt de resultaten van SPF en DKIM en controleert of een van beide overeenkomt met het zichtbare ‘Van’-adres

SPF en DKIM leveren ruwe authenticatieresultaten op, maar DMARC bepaalt of die resultaten relevant zijn in de context van wat de ontvanger daadwerkelijk te zien krijgt.

Je hebt zowel SPF als DKIM nodig, omdat ze elkaars zwakke punten aanvullen. SPF faalt bij het doorsturen van e-mails. DKIM blijft daarbij wel werken. DKIM kan door sommige tussenstappen worden verwijderd, terwijl SPF niet afhankelijk is van de inhoud van het bericht. Samen zorgen ze voor redundantie.

DMARC voegt een beleidslaag toe: wat moeten ontvangers doen als zowel SPF als DKIM niet kloppen? De drie opties zijn geen (alleen controleren), quarantaine (naar spam verzenden) en afwijzen (volledig blokkeren). DMARC voegt ook rapportage toe – zonder dit weet je nooit wanneer authenticatie mislukt.

Conclusie

SPF vormt de basis van e-mailverificatie, maar is slechts zo sterk als de configuratie ervan en slechts zo nuttig als het DMARC-raamwerk waarin het wordt geïntegreerd. Een verkeerd geconfigureerd SPF-record verstoort de e-mailbezorging, stelt uw domein bloot aan spoofing en zorgt ervoor dat uw organisatie niet meer voldoet aan de huidige vereisten voor afzenders.

De volgende stap is altijd hetzelfde, of je nu voor het eerst SPF instelt of een defecte record probeert te verhelpen: controleer je huidige configuratie.

Controleer de e-mailverificatie-instellingen van uw domein met onze gratis Domain Analyzer . Deze analyseert SPF, DKIM, DMARC en meer binnen enkele seconden. Heeft u behoefte aan continue monitoring, geautomatiseerd SPF-beheer en DMARC-rapportage? 

Start een gratis proefperiode van 15 dagen

Veelgestelde Vragen

Kan een domein meer dan één SPF-record hebben?

Nee. RFC 7208 schrijft precies één SPF-record per domein voor. Als er twee TXT-records zijn die beginnen met v=spf1 bestaan, geven beide een PermError terug en faalt de SPF-controle volledig. Voeg alle geautoriseerde bronnen samen tot één enkel record.

Wat betekent het als mijn domein te veel DNS-opzoekingen heeft?

Uw SPF-record overschrijdt de limiet van 10 DNS-lookups die is vastgelegd in RFC 7208. Dit leidt tot een SPF PermError, waardoor de SPF-verificatie voor alle e-mails mislukt – niet alleen voor de e-mails die buiten de limiet vallen. Verminder het aantal includes en vervang deze door ip4:/ip6:, of gebruik SPF-flattening of macro's om onder de limiet te blijven.

Wat is het verschil tussen SPF softfail (~all) en hardfail (-all)?

Softfail (~all) geeft ontvangers de instructie om de e-mail te accepteren, maar deze als verdacht te markeren. Hardfail (-all) geeft ontvangers de instructie om de e-mail direct te weigeren. Gebruik softfail tijdens de eerste configuratie en het testen; schakel over naar hardfail zodra alle legitieme afzenders zijn bevestigd en DMARC is geïmplementeerd.

Voorkomt SPF e-mailspoofing?

Op zichzelf niet. SPF controleert de afzender van de envelop (Return-Path), niet de From-header die ontvangers te zien krijgen. Een aanvaller kan de SPF-controle doorstaan terwijl hij het zichtbare From-adres vervalst. Je hebt DMARC nodig – dat de overeenstemming tussen de SPF-/DKIM-resultaten en de From-header controleert – om het vervalsen van de weergavenaam te voorkomen.

Wat gebeurt er als SPF niet werkt?

Dat hangt af van de SPF-kwalificatie en of DMARC is geconfigureerd. Met -all en een DMARC-weigeringsbeleid wordt de e-mail geblokkeerd. Met ~all en geen DMARC wordt de e-mail mogelijk nog steeds afgeleverd, maar gemarkeerd als verdacht. Zonder SPF hebben ontvangers geen SPF-signaal om te beoordelen.

Hoe kan ik mijn SPF-record controleren?

Gebruik een gratis SPF-opzoektool. Voer uw domein in en de tool haalt uw SPF-record op uit DNS, valideert de syntaxis, telt het aantal DNS-lookups en markeert eventuele fouten – inclusief PermError- en void-lookup-overtredingen.

Heb ik SPF nodig als ik al DKIM en DMARC heb?

Ja. DMARC vereist dat ten minste één van de twee, SPF of DKIM, de controle doorstaat en in overeenstemming is. Hoewel DKIM op zichzelf al aan de DMARC-vereisten voldoet, biedt het gebruik van zowel SPF als DKIM extra zekerheid. Als één van beide faalt (bijvoorbeeld wanneer SPF niet werkt bij het doorsturen), kan de andere nog steeds voldoen aan de DMARC-vereisten.

Wat is SPF-uitlijning?

SPF-overeenstemming houdt in dat het domein in het Return-Path (afzender van de envelop) overeenkomt met het domein in de From-header. DMARC controleert deze overeenstemming. Zonder deze overeenstemming kan SPF wel slagen, maar zal DMARC toch mislukken – wat bij veel externe afzenders het geval is, tenzij ze zo zijn geconfigureerd dat ze uw domein in het Return-Path gebruiken.

Hoe vaak moet ik mijn SPF-record bijwerken?

Controleer uw SPF-record telkens wanneer u een verzendservice toevoegt of verwijdert, en voer ten minste elk kwartaal een controle uit. SPF-records raken verouderd wanneer leveranciers hun IP-reeksen wijzigen en de verzendinfrastructuur van uw organisatie verandert. Een SPF-record dat zes maanden geleden nog geldig was, kan vandaag de dag onjuist of onvolledig zijn.

Wat is SPF-afvlakking?

Het afvlakken van SPF lost alle inclusief: mechanismen om in ruwe IP-adressen, waardoor het aantal DNS-lookups wordt verminderd. Hierdoor blijft u onder de limiet van 10 lookups, maar wordt er een statisch record aangemaakt dat moet worden bijgewerkt telkens wanneer een leverancier zijn IP-adressen wijzigt. Moderne alternatieven zoals SPF-macro's houden het record dynamisch terwijl ze onder de limiet blijven.

• 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)

• DNS SPF-record: hoe het werkt en hoe je het instelt - 6 mei 2026
• Wat is v=spf1? Waarvoor dient het? - 5 mei 2026
• DMARC MSP-casestudy: hoe Digital Infinity IT Group het DMARC- en DKIM-beheer voor klanten heeft gestroomlijnd met PowerDMARC - 21 april 2026