Handleiding voor de syntaxis van SPF-records: onderdelen, regels, voorbeelden en validatie

Als je je ooit hebt afgevraagd waarom sommige van je legitieme e-mails in de spamfolder terechtkomen of helemaal worden geblokkeerd, kan het probleem te maken hebben met de manier waarop de e-mailverificatie van je domein is ingesteld. Een belangrijke factor hierbij is de syntaxis van het SPF-record, dat een cruciale rol speelt bij het controleren of je e-mails vanaf geautoriseerde servers worden verzonden. Hoewel SPF helpt voorkomen dat je berichten als verdacht worden gemarkeerd, kan de syntaxis ervan lastig te begrijpen zijn en is het nog moeilijker om deze correct te configureren. 

In dit artikel leggen we uit hoe de syntaxis van SPF-records werkt en waar je op moet letten bij het instellen ervan voor je domein.

Wat is de syntaxis van een SPF-record?

Een SPF-recordsyntaxis is de verzameling regels die bepalen hoe een SPF-record (Sender Policy Framework) in het DNS van een domein wordt geschreven. Eenvoudig gezegd is het de "taal" die uw domein gebruikt om ontvangende mailservers te vertellen welke bronnen gemachtigd zijn om e-mails namens uw domein te verzenden.

De syntaxis van een SPF-record bevat doorgaans mechanismen (zoals ip4, ip6 of include), kwalificatoren (zoals +, -, ~ of ?) en modificatoren die samen bepalen of een inkomende e-mail de SPF-controle doorstaat of niet.

Het begrijpen van deze syntax is cruciaal omdat zelfs een kleine fout, zoals een extra spatie, een onjuiste kwalificatie of een ontbrekend mechanisme, ervoor kan zorgen dat je e-mails niet geverifieerd worden en in spam terechtkomen of worden geweigerd.

Opmerking overDMARC-afstemming: SPF valideert het domein van de afzender van de envelop, niet altijd het zichtbare 'Van'-adres dat gebruikers in hun inbox zien. Om via SPF door DMARC te worden goedgekeurd, moet het domein in het Return-Path overeenkomen met het zichtbare 'Van'-domein. Daarom moet SPF worden gecombineerd met DKIM en DMARC.

Structuur en onderdelen van de SPF-record-syntaxis

Een SPF-record bestaat uit vier hoofdonderdelen: de versietag, mechanismen, kwalificaties en modificatoren. Elk onderdeel vervult een specifieke rol, en samen bepalen ze hoe ontvangende mailservers omgaan met e-mails die beweren afkomstig te zijn van uw domein.

Versietag

De versietag vormt het begin van een SPF-record. Deze geeft aan dat het record de SPF-syntaxis gebruikt en zorgt ervoor dat e-mailservers de daaropvolgende tekst correct interpreteren. Zonder deze tag werkt het record niet. Er is slechts één versietag toegestaan, en deze moet helemaal aan het begin van het record staan. Huidige geldige indeling: v=spf1.

SPF-kwalificaties: +, -, ~ en ?

Kwalificatoren zijn symbolen die voor mechanismen worden geplaatst. Ze geven de ontvangende mailserver aan wat er moet gebeuren als het mechanisme overeenkomt. Als er geen kwalificator is opgegeven, is de standaardactie ‘Doorsturen’.

SPF-mechanismen: all, ip4, ip6, a, mx, exists en include

Mechanismen vormen de belangrijkste regels in een SPF-record. Ze bepalen welke servers, IP-adressen of domeinen bevoegd zijn om e-mail namens het domein te verzenden. Elk mechanisme wordt in volgorde van links naar rechts gecontroleerd, en als er een overeenkomst wordt gevonden, wordt de bijbehorende kwalificatie toegepast.

Het 'all'-mechanisme: -all vs. ~all vs. ?all

-all (Hard Fail): Elke afzender die niet in de lijst staat, wordt expliciet geweigerd. Gebruik deze instelling zodra uw SPF-record volledig is getest en alle legitieme afzenders zijn opgenomen. Dit is de aanbevolen instelling voor strikte handhaving.

~alle (SoftFail): Niet-geregistreerde afzenders worden geaccepteerd, maar gemarkeerd. Gebruik deze optie tijdens het testen of bij een geleidelijke implementatie, wanneer u er nog niet zeker van bent dat alle legitieme afzenders in de lijst staan.

?all (Neutraal): Er wordt geen beleid toegepast op niet-geregistreerde afzenders. Dit biedt geen echte bescherming en wordt niet aanbevolen voor gebruik in een productieomgeving.

+all (Alles doorgeven): Hiermee kan elke server namens u berichten versturen. Dit is gevaarlijk en mag nooit worden gebruikt.

SPF-modificatoren: redirect en exp

redirect= (Modificator): Delegeert de volledige evaluatie van het SPF-beleid aan een ander domein. In tegenstelling tot `include` vervangt `redirect` het huidige record volledig en kan het niet worden gecombineerd met een `all`-mechanisme. Het SPF-`include`-mechanisme werkt anders. Het voegt geautoriseerde afzenders toe uit het SPF-record van een domein waarnaar wordt verwezen, zonder uw eigen record te vervangen.

exp= (Modifier): Geeft een aangepaste uitlegtekst voor SPF-fouten. Wanneer een bericht de SPF-controle niet doorstaat, kan de ontvangende server dit TXT-record opzoeken om een voor mensen leesbare reden op te halen.

'include' versus 'redirect': het belangrijkste verschil

Resultaten van de SPF-beoordeling en wat deze betekenen

Wanneer een ontvangende mailserver een SPF-record controleert, levert dit een van de zeven mogelijke resultaten op. Inzicht in elk resultaat helpt domeineigenaren om bezorgingsfouten op te sporen en hun SPF-configuratie te verbeteren. Voor tips over het verhelpen van veelvoorkomende SPF-fouten kun je onze gids raadplegen over het optimaliseren van uw SPF-record.

SPF Record Syntax Voorbeelden

Eenvoudig SPF-bestand

v=spf1 ip4:203.0.113.5 -all

v=spf1 → versietag. ip4:203.0.113.5 → geeft toestemming voor één IPv4-adres. -all → alle andere servers worden geweigerd. Dit is een veelvoorkomende configuratie voor een klein domein dat e-mail verstuurt vanaf één enkele server.

Geavanceerd SPF-bestand

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com

Dit record machtigt een volledig /24 IP-bereik, twee externe afzenders, accepteert niet-vermelde afzenders met een SoftFail-vlag en geeft een aangepaste foutmelding. Elk ‘include’, ‘a’, ‘mx’, ‘exists’ en ‘redirect’-mechanisme leidt tot DNS-lookups. Als het totaal hoger is dan 10, retourneert SPF een PermError.

Voorbeeld van een SPF-record voor bedrijven

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all

Dit probleem komt vaak voor bij organisaties die gebruikmaken van Google Workspace, Microsoft 365 en een leveringsplatform van een derde partij. Elke toevoeging brengt DNS-lookups met zich mee, dus teams moeten dit zorgvuldig controleren om PermError-resultaten te voorkomen.

Voorbeeld van MSP SPF-beheer

Voor MSP’s die veel domeinen van klanten beheren, is het niet alleen de bedoeling om één geldig SPF-record op te stellen, maar ook om wijzigingen bij alle klanten in de gaten te houden. Gecentraliseerde SPF-validatie helpt bij het opsporen van dubbele records, risico’s op opzoeklimieten en defecte includes, voordat klanten problemen met de bezorging ondervinden. Het MSP/MSSP-partnerprogramma stelt serviceproviders in staat om de authenticatie voor alle klantdomeinen vanuit één enkel dashboard te beheren, zonder van tool te hoeven wisselen of DNS-records handmatig te moeten parseren.

Voorbeelden van de syntaxis van SPF TXT-records per gebruiksscenario

Hoe je meerdere `include`-mechanismen kunt gebruiken in de syntaxis van SPF-records

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all

Elk ‘include’-mechanisme activeert ten minste één DNS-opzoeking, en geneste ‘includes’ zorgen voor nog meer opzoekingen. Het totaal over de gehele keten mag niet hoger zijn dan 10. De SPF-verwerking stopt bij de eerste overeenkomst, dus de volgorde is van belang: plaats de meest gebruikte afzenders bovenaan. Als het aantal opzoekingen de 10 nadert, gebruik dan de SPF-afvlakkingstool om je record automatisch te optimaliseren. Voor complexe bedrijfsopstellingen kun je gebruikmaken van bieden SPF-macro’s een schaalbaarder alternatief voor traditionele flattening, doordat ze tijdens de evaluatie dynamisch worden uitgebreid.

Te veel DNS-opzoekingen in SPF-records

RFC 7208 beperkt het totale aantal DNS-lookups tijdens de SPF-evaluatie tot 10. Deze limiet geldt voor de volledige lookup-keten — inclusief geneste lookups die worden geactiveerd door include-, a-, mx-, exists- en redirect-mechanismen. Als de limiet wordt overschreden, retourneert de ontvangende server een PermError, waardoor de SPF-controle volledig mislukt. Er is ook een minder bekende beperking: de limiet van 2 ongeldige opzoekingen. Als meer dan twee DNS-query’s NXDOMAIN retourneren, mislukt SPF eveneens. Voor een gedetailleerde uitleg over hoe je dit kunt oplossen, zie hoe je te veel DNS-lookups kunt verhelpen.

Mechanismen die meetellen: omvatten (1 + genest), a (1), mx (1 per MX + A-lookups), exists (1), redirect (1 + genest), ptr (meerdere — verouderd).

Mechanismen die NIET meetellen: ip4 en ip6 leiden niet tot DNS-lookups.

Hoe het aantal DNS-lookups te verminderen: Verwijder include-mechanismen voor afzenders die u niet langer gebruikt. Vervang a- en mx-mechanismen waar mogelijk door expliciete IPv4-waarden. Vermijd ptr. Gebruik PowerSPF (Hosted SPF) om 'includes' te consolideren en binnen de limiet te blijven zonder handmatig DNS-onderhoud. Voor meer informatie over het 'flattening'-proces zelf, zie SPF-afvlakking: van DNS-overbelasting naar gestroomlijnde SPF.

Hoe publiceer je een SPF TXT-record in DNS?

SPF wordt als een TXT-record gepubliceerd in de DNS van uw domein op het niveau van het hoofddomein (bijv. example.com) of op het betreffende subdomein. Gebruik onze gratis SPF-recordgenerator om direct een geldig record aan te maken voordat u het publiceert.

Belangrijk: Een domein mag slechts één SPF TXT-record hebben. Het publiceren van meerdere TXT-records die beginnen met v=spf1 leidt tot een PermError.

Workflow voor SPF-syntaxisvalidatie

Stap 1: Maak een inventarisatie van alle verzendbronnen — Microsoft 365, Google Workspace, CRM-systemen, marketingtools, helpdesksystemen, salarisadministratie en regionale afzenders.

Stap 2: Schrijf het SPF-record of werk het bij — Voeg alleen geautoriseerde mechanismen en includes toe.

Stap 3: Controleer het aantal opzoekingen — Zorg ervoor dat het record de limiet van 10 DNS-opzoekingen niet overschrijdt.

Stap 4: Controleer de syntaxis — Gebruik een SPF-checker om problemen met opmaak, duplicaten en verouderde mechanismen op te sporen.

Stap 5: Controleer de authenticatieresultaten — Bekijk de DMARC-rapporten om te controleren of legitieme afzenders voldoen aan de SPF- en DKIM-vereisten.

Regels voor de syntaxis van SPF-records, validatie en veelvoorkomende fouten

Bij het schrijven van een SPF-record gaat het erom mechanismen en kwalificeerders in de juiste volgorde te zetten en ervoor te zorgen dat het record werkt zoals bedoeld. Zelfs kleine syntaxfouten, zoals een ontbrekende tag of een extra spatie, kunnen ervoor zorgen dat het record mislukt, waardoor e-mails worden geweigerd, als spam worden gemarkeerd of uw domein kwetsbaar wordt voor spoofing.

Deze sectie behandelt drie belangrijke gebieden: best practices voor het schrijven van SPF syntax, veelgemaakte fouten die je moet vermijden en hoe je je record moet valideren voordat je het live publiceert.

Volg de best practices voor SPF-syntaxis

SPF op de juiste manier gebruiken begint met het volgen van een paar gouden regels die je record zowel effectief als betrouwbaar maken:

• Begin altijd met de juiste versietag: v=spf1.
• Beperk DNS zoekopdrachten om te voorkomen dat de limiet van 10 opzoekingenwaardoor het record zal breken.
• Gebruik de opnemen zorgvuldig om lussen of cirkelverwijzingen te voorkomen.
• Houd de documentatie zo beknopt mogelijk — te ingewikkelde configuraties zijn moeilijker te onderhouden en vertonen vaker storingen.
• Controleer SPF-records regelmatig, vooral als uw e-mailinfrastructuur verandert of als u providers toevoegt of verwijdert.

Beheer van SPF-syntaxis voor MSP’s en MSSP’s

Voor MSP’s en MSSP’s die SPF voor talrijke klantdomeinen beheren, gaan de best practices verder dan het opstellen van één enkele correcte record. Belangrijke operationele overwegingen zijn onder meer:

• Standaardiseer SPF-sjablonen voor veelvoorkomende klantconfiguraties (bijvoorbeeld Google Workspace + Microsoft 365) om de onboarding te versnellen en syntaxisfouten te verminderen.
• Het monitoren van het aantal opzoekingen automatiseren om waarschuwingen te ontvangen voordat het SPF-record van een klant de limiet van 10 DNS-lookups overschrijdt — vooral wanneer klanten nieuwe SaaS-tools toevoegen.
• Gebruik gecentraliseerde dashboards om tegelijkertijd in alle klantdomeinen dubbele SPF-records, defecte includes of ontbrekende mechanismen op te sporen.
• Wijzigingen in documenten telkens wanneer een nieuwe afzender aan de omgeving van een klant wordt toegevoegd, om een nauwkeurig controlespoor bij te houden met het oog op naleving en probleemoplossing.

Veelvoorkomende syntaxfouten vermijden

Veel SPF-problemen zijn het gevolg van eenvoudige maar schadelijke fouten. Kijk uit voor deze valkuilen:

• Ontbrekende versietag: elk record moet beginnen met v=spf1.
• Dubbele kwalificaties: het gebruik van meer dan één kwalificatie voor hetzelfde mechanisme is ongeldig.
• Overbodige mechanismen: lange, opgeblazen records verhogen het risico op fouten en overschrijden de DNS-limieten.
• Problemen met de syntaxisopmaak: verkeerd geplaatste spaties, typefouten of niet-ondersteunde tekens kunnen ervoor zorgen dat het record wordt afgewezen.
• Meerdere SPF-records: een domein mag slechts één SPF-record hebben — als er meer dan één bestaat, mislukt de validatie.
• Verouderde mechanismen: vermijd ptr, dit wordt niet langer aanbevolen en wordt mogelijk niet door alle servers ondersteund.

Onthoud: zelfs als de intentie van het record correct is, zullen syntaxfouten ervoor zorgen dat SPF volledig faalt.

Valideer de syntaxis van uw SPF-record

Voordat je je SPF record publiceert, is validatie cruciaal. Validators controleren of de syntax correct is en of het record de DNS-opzoeklimieten niet overschrijdt of niet-ondersteunde mechanismen bevat.

• Gebruik tools voor het controleren van SPF-records, zoals die van PowerDMARC SPF-checker, om problemen snel op te sporen.
• Validatie helpt ervoor te zorgen dat het record consistent werkt op verschillende ontvangende mailservers.
• Het testen van nieuwe of bijgewerkte records in een staging-omgeving wordt aanbevolen voordat ze live worden toegepast.
• Regelmatige validatie na wijzigingen houdt je SPF-beleid up-to-date en functioneel.

Door te valideren verkleint u het risico dat e-mails worden geweigerd, naar spam gaan of dat uw domein kwetsbaar is voor spoofing.

SPF Record Syntax in actie

Een correcte syntaxis van het SPF-record is van cruciaal belang voor een veilige e-mailbezorging en bescherming tegen spoofing. Elk onderdeel – de versietag, mechanismen, kwalificaties en modificatoren – werkt samen om te bepalen hoe e-mailservers uw berichten verwerken. 

Naarmate het gebruik van SPF blijft toenemen – het wereldwijde slagingspercentage bedraagt momenteel 80,24% – behalen organisaties die investeren in schone, gevalideerde SPF-syntaxis een meetbaar voordeel op het gebied van afleverbaarheid, naleving en beveiligingsniveau. 

Voor een volledige stapsgewijze handleiding voor de eerste installatie, zie hoe u SPF-records instelt. En om ervoor te zorgen dat u voldoet aan de nieuwste nalevingsvereisten, raadpleegt u de e-mailverificatievereisten van Google en Yahoo voor 2026.

Veelgestelde Vragen

1. Hoe schrijf ik een SPF-record?

Begin met v=spf1, voeg mechanismen toe om geautoriseerde afzenders op te sommen (zoals ip4: voor specifieke IP-adressen of include: voor diensten van derden), en sluit af met een kwalificatie zoals -all om al het overige te blokkeren. Publiceer het record als één enkel DNS TXT-record in de root van je domein.

2. Wat gebeurt er als de syntaxis van mijn SPF-record niet klopt?

E-mailservers kunnen uw e-mails weigeren of als spam markeren, en uw domein wordt kwetsbaarder voor spoofing. Een syntaxfout, zoals een ontbrekende versietag, dubbele SPF-records of het overschrijden van de limiet van 10 DNS-lookups, kan ervoor zorgen dat SPF volledig faalt.

3. Wat is een voorbeeld van een SPF-record waarbij gebruik wordt gemaakt van MX?

Een SPF-record dat gebruikmaakt van MX ziet er als volgt uit: v=spf1 mx -all. Hierdoor mogen alleen de mail-exchange-servers van het domein namens het domein e-mail versturen.

4. Hoeveel DNS-opzoekingen zijn toegestaan in een SPF-record?

SPF staat maximaal 10 DNS-lookups per evaluatie toe, zoals vastgelegd in RFC 7208. Mechanismen die hierbij worden meegeteld zijn: include, a, mx, exists, redirect en ptr. Als dit maximum wordt overschreden, retourneert SPF een PermError.

5. Kun je meerdere SPF-records voor één domein hebben?

Nee. Een domein mag slechts één SPF TXT-record bevatten. Meerdere records die beginnen met v=spf1 leiden tot een PermError. Voeg alle geautoriseerde afzenders samen in één record.

6. Wat is het verschil tussen SPF -all en ~all?

-all (hard fail) geeft ontvangers de instructie om e-mail van niet-geregistreerde afzenders te weigeren. ~all (soft fail) geeft ontvangers de instructie om de e-mail te accepteren, maar deze wel te markeren. Gebruik ~all tijdens het testen en schakel over naar -all zodra alle legitieme afzenders zijn bevestigd.

7. Voorkomt SPF op zichzelf e-mailspoofing?

Nee. SPF controleert alleen de afzender van de envelop (Return-Path), niet het zichtbare „Van”-adres. Voor volledige bescherming tegen spoofing en phishing moet het worden gecombineerd met DKIM en DMARC.

8. Wat is SPF -afvlakking en wanneer heb ik dat nodig?

SPF-flattening vervangt de `include`-mechanismen door de opgeloste IP-adressen, waardoor het aantal DNS-lookups wordt verminderd. Dit is nodig wanneer je SPF-record de limiet van 10 DNS-lookups overschrijdt of daar dichtbij komt. Geautomatiseerde tools zoals PowerSPF regelen dit dynamisch.

9. Hoe lang duurt het voordat een SPF-record is doorgevoerd?

DNS-propagatie duurt doorgaans 1 tot 4 uur, afhankelijk van je DNS-provider en de TTL-instellingen. In sommige gevallen kan dit tot 48 uur duren. Controleer je record altijd na het publiceren.

• Over
• Laatste berichten

Ahona Rudra

Expert op het gebied van 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)

• Faxbeveiliging: een complete gids voor het beveiligen van vertrouwelijke documenten in 2026 - 30 juli 2026
• Wat is een e-mailfilterservice? - 29 juli 2026
• E-mail-spoofing: wat het is en hoe je het kunt voorkomen - 29 juli 2026