Belangrijkste Conclusies
- SPF (Sender Policy Framework) is een DNS-TXT-record dat bepaalt welke servers e-mails mogen versturen namens uw domein, waardoor e-mailfraude wordt voorkomen en de afleverbaarheid wordt verbeterd.
- SPF controleert tijdens een DNS-opzoeking of het IP-adres van de verzendende server overeenkomt met het gepubliceerde SPF-record van het domein. Als er geen overeenstemming is, kan de e-mail worden gemarkeerd, geweigerd of naar de spamfolder worden verplaatst.
- SPF controleert alleen het Return-Path (de afzender van de envelop), niet het zichtbare 'Van'-adres, wat betekent dat het op zichzelf geen misbruik van de weergavenaam kan voorkomen.
- Je kunt slechts één SPF-record per domein hebben, aangezien meerdere records een PermError veroorzaken en de authenticatie volledig onmogelijk maken.
- SPF hanteert een strikte limiet van 10 DNS-lookups; als deze limiet wordt overschreden, leidt dit tot een PermError, waardoor SPF voor alle e-mails mislukt, zelfs voor legitieme berichten.
- Veelvoorkomende fouten in de SPF-record zijn onder meer te veel ‘includes’, ontbrekende afzenders, het gebruik van ‘+all’ en meerdere records; dit alles kan de afleverbaarheid ongemerkt schaden.
- SPF alleen is niet voldoende voor e-mailbeveiliging; het moet worden gecombineerd met DKIM en DMARC voor volledige bescherming, afstemming en rapportage.
- SPF faalt bij het doorsturen van e-mails, waardoor DKIM onmisbaar is als alternatieve authenticatiemethode.
- Een goed geconfigureerd SPF-record moet volledig, efficiënt en strikt zijn, alle geldige afzenders bevatten, binnen de opzoeklimieten blijven en eindigen met -all na
- SPF is geen eenmalige instelling. Het vereist voortdurende controle en updates naarmate uw e-mailinfrastructuur verandert
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:
| Resultaat | Symbool | Wat dit in de praktijk betekent |
|---|---|---|
| Pas | +- | De verzendende server is geautoriseerd. De e-mail wordt normaal verzonden. |
| Storing | - | De verzendende server is NIET geautoriseerd. De e-mail moet worden geweigerd. |
| SoftFail | ~ | De verzendende server is NIET geautoriseerd, maar accepteer het bericht en markeer het als verdacht. |
| Neutraal | ? | Het domein doet geen uitspraken over deze server. |
| Geen | - | Er is geen SPF-record voor dit domein. |
| PermError | - | Het SPF-record is ongeldig (syntaxfout, te veel lookups). SPF kan niet worden geëvalueerd. |
| Tijdelijke fout | - | Tijdelijke DNS-storing. Probeer het later nog eens. |
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.
| Mechanisme | Wat het doet | DNS-opzoeking vereist | Een Voorbeeld | Opmerkingen |
|---|---|---|---|---|
| omvatten: | Geeft toestemming voor het SPF-record van een ander domein | Ja | opnemen:_spf.google.com | Komt het meest voor. Kan geneste opzoekingen veroorzaken |
| ip4: | Geeft toestemming voor een IPv4-adres of -bereik | Geen | ip4:203.0.113.0/24 | Direct en efficiënt |
| ip6: | Geeft toestemming voor een IPv6-adres of -adresbereik | Geen | ip6:2001:db8::/32 | Hetzelfde als IPv4, maar dan voor IPv6 |
| a | Geeft IP-adressen uit het A-record van het domein toegang | Ja (1) | a | Maakt gebruik van een bestaand A-record. Geen apart SPF A-record |
| mx | Geeft IP-adressen uit de MX-records van het domein toestemming | Ja (1) | mx | Handig als mailservers uitgaande e-mail versturen |
| ptr | Omgekeerde DNS-opzoeking (verouderd) | Ja | ptr | Niet aanbevolen (verouderd volgens RFC 7208) |
| bestaat: | Komt overeen als een domein in DNS wordt omgezet | Ja | exists:%{i}._spf.example.com | Alleen voor gevorderden |
| alle | Geldt voor alle afzenders (in combinatie met kwalificaties) | Geen | -all | Altijd aan het einde geplaatst |
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:
| Kwalificatie | Symbool | Betekenis | Aanbevolen gebruik |
|---|---|---|---|
| Pas | + | De afzender is uitdrukkelijk toegestaan | Standaardgedrag. Wordt zelden expliciet vastgelegd |
| Mislukt (Hardfail) | - | Afzender is niet toegestaan | Gebruik na volledige configuratie van SPF en DMARC |
| SoftFail | ~ | Afzender is waarschijnlijk niet toegestaan | Gebruik tijdens installatie/testen |
| Neutraal | ? | Geen beleid / geen bewering | Vermijd dit. In de praktijk niet bruikbaar |
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:
| Verzenddienst | SPF opnemen | Geschatte DNS-zoekopdrachten (recursief) |
|---|---|---|
| Google Werkruimte | opnemen:_spf.google.com | 3–4 |
| Microsoft 365 | bijvoorbeeld: spf.protection.outlook.com | 2 |
| Mailchimp | bijvoorbeeld: servers.mcsv.net | 1 |
| HubSpot | bijvoorbeeld: spf.hubspot.com | 1 |
| Salesforce | onder andere:_spf.salesforce.com | 2 |
| Totaal | 9–10 |
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
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.
| Protocol | Wat het controleert | Wat het voorkomt | Belangrijke beperking |
|---|---|---|---|
| SPF | IP-adres van de verzendende server vergeleken met de lijst van geautoriseerde adressen (domein van het Return-Path) | Ongeautoriseerde servers die berichten versturen met de afzender van uw domein | Stopt bij doorsturen. Controleert de zichtbare ‘From’-header niet |
| DKIM | Cryptografische handtekening op de berichttekst en de headers | Manipulatie van berichten tijdens het verzenden | Kan door sommige tussenpersonen worden afgeroomd. Er wordt geen beleid vermeld |
| DMARC | Overeenstemming tussen SPF-/DKIM-resultaten en het domein in de From-header | Spoofing van weergavenaam. Biedt mogelijkheden voor beleidsafdwinging en rapportage | Dit hangt ervan af of SPF en/of DKIM eerst worden geverifieerd en op elkaar zijn afgestemd |

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.
| Protocol | Wat het controleert | Wat het voorkomt | Belangrijke beperking |
|---|---|---|---|
| SPF | IP-adres van de verzendende server (Return-Path) | Ongeautoriseerde afzenders van enveloppen | Onderbrekingen bij doorsturen |
| DKIM | Cryptografische berichtondertekening | Manipulatie van berichten | Kan worden verwijderd; er wordt geen beleid afgedwongen |
| DMARC | Afstemming van SPF/DKIM met de From-header | Spoofing van weergavenaam; dwingt beleid af | Vereist SPF en/of DKIM om te werken |

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.


