SPF Record Syntax: Onderdelen, regels en voorbeelden

Als u zich ooit hebt afgevraagd waarom sommige van uw legitieme e-mails in spammappen terechtkomen of helemaal worden geblokkeerd, kan het probleem liggen in de manier waarop de e-mailverificatie van uw domein is ingesteld. Een belangrijke factor hierbij is de syntaxis van het SPF-record, dat een cruciale rol speelt bij het verifiëren dat uw e-mails worden verzonden vanaf geautoriseerde servers. Hoewel SPF helpt voorkomen dat uw berichten als verdacht worden gemarkeerd, kan de syntax lastig te begrijpen zijn en nog moeilijker om correct te configureren. In dit bericht 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 een SPF Record Syntax

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 SPF-records bevat meestal mechanismen (zoals ip4, ip6, of bevatten), kwalificaties (zoals +, -, ~, of?), en modifiers die werken samenwerken om bepalen of een inkomende e-mail de SPF-controle doorstaat of niet.

Het is van cruciaal belang om deze syntaxis te begrijpen, omdat zelfs een kleine fout, zoals een extra spatie, een onjuiste kwalificatie of een ontbrekend mechanisme, ervoor kan zorgen dat uw e-mails niet worden geauthenticeerd en in de spamfolder terechtkomen of worden geweigerd.

Vereenvoudig SPF Record Syntax met PowerDMARC!

Onderdelen SPF Record Syntax

Een SPF-record bestaat uit vier hoofdonderdelen: de version tag, mechanismen, qualifiers en modifiers. Elk deel speelt een unieke rol en samen bepalen ze hoe ontvangende mailservers e-mails behandelen die claimen van uw domein te komen. De version tag identificeert het record als SPF. Mechanismen bepalen wie e-mails mag versturen. Qualifiers bepalen welke actie ondernomen moet worden als er een overeenkomst is. Modifiers geven optionele instructies die het beleid uitbreiden of verfijnen.

Versie tag

De version tag is het beginpunt van een SPF record. Het geeft aan dat het record de SPF syntax gebruikt en zorgt ervoor dat mailservers de volgende tekst correct interpreteren. Zonder zal het record niet werken. Er is maar één version tag toegestaan en deze moet helemaal aan het begin van het record staan.

Belangrijkste bijzonderheden:

• • Moet altijd aan het begin van het record staan.
  • Er is slechts één versietag toegestaan.
  • Huidige geldige indeling: v=spf1.
  • Het gebruik van de verkeerde versie of het weglaten ervan maakt het record ongeldig.

SPF-kwalificaties

Qualifiers zijn symbolen die voor mechanismen worden geplaatst. Ze instrueren de ontvangende mailserver wat te doen als het mechanisme overeenkomt. Hun rol is om het resultaat van de SPF-evaluatie te bepalen, of de e-mail wordt geaccepteerd, afgewezen of gemarkeerd als verdacht. Als er geen qualifier is opgegeven, is de standaardactie om toe te staan.

Belangrijkste bijzonderheden:

• • Dienen als voorvoegsels voor mechanismen.
  • Controleer het resultaat van de SPF-controle.
  • Vier typen:
    • + Pas (toestaan)
    • - Storing (blok)
    • ~ Softfail (accepteren maar markeren)
    • ? Neutraal (geen beslissing)
      • Het standaardgedrag is Pass als er geen kwalificatie wordt gebruikt.

SPF-mechanismen

Mechanismen zijn de belangrijkste regels in een SPF-record. Ze definiëren welke servers, IP-adressen of domeinen geautoriseerd zijn om mail te versturen namens het domein. Elk mechanisme wordt in volgorde gecontroleerd en als er een overeenkomst wordt gevonden, wordt de bijbehorende kwalificatie toegepast. Als geen enkel mechanisme overeenkomt, gaat het record verder tot het einde is bereikt.

Belangrijkste bijzonderheden:

• • Definieer wie e-mails mag verzenden voor het domein.
    Aangevinkt in volgorde van links naar rechts.
  • Werk samen met gekwalificeerden om het resultaat te bepalen.
  • Acht standaardmechanismen:
    • alle - komt overeen met alle afzenders.
    • ip4 - machtigt IPv4-adressen.
    • ip6 - machtigt IPv6-adressen.
    • a - autoriseert op basis van de A/AAAA records.
    • mx - autoriseert op basis van de mailservers van het domein.
    • ptr - omgekeerde DNS-controle (verouderd).
    • bestaat - controleert of een domein is opgelost.
    • opnemen - verwijst naar het SPF-record van een ander domein.

SPF-wijzigers

Modifiers zijn optionele elementen die extra instructies toevoegen aan een SPF record. Ze staan niet direct mail toe of af, maar bieden flexibiliteit en meer controle over hoe het record verwerkt wordt. Modifiers worden vaak gebruikt in meer geavanceerde configuraties, maar zijn niet altijd vereist.

Belangrijkste bijzonderheden:

• Geef optionele, extra instructies.
• Bepalen niet direct het slagen/zakken.
• Veelvoorkomende modifiers:
  • redirect - verwijst naar het SPF-record van een ander domein.
  • exp - geeft een aangepaste verklaring voor SPF-fouten.

• Verschijnen meestal aan het einde van de plaat.

Vereenvoudig SPF met PowerDMARC!

SPF Record Syntax Voorbeelden

Door naar echte SPF-records te kijken, wordt het gemakkelijker te begrijpen hoe de verschillende componenten samenwerken. Hieronder staan twee voorbeelden: een eenvoudig en een meer geavanceerd. Elk voorbeeld volgt de juiste syntaxisregels en laat zien hoe mechanismen, kwalificaties en modificatoren in de praktijk werken.

Eenvoudig SPF-bestand

v=spf1 ip4:203.0.113.5 -all

Indeling:

• v=spf1 → Versietag die de record identificeert als SPF versie 1.
• ip4:203.0.113.5 → mechanisme dat het IPv4-adres autoriseert 203.0.113.5 om mail te versturen.
• -all → kwalificatie en mechanisme gecombineerd, wat betekent dat alle andere servers die niet in de lijst staan de SPF-controle moeten weigeren.

Waarom het geldig is:

• Het record begint met de juiste versie-tag.
• Het mechanisme (ip4) is correct geschreven.
• De kwalificator (-) wordt correct gebruikt voor alle.
• De syntaxis is volledig en volgt de SPF-regels.

 Dit is een veel voorkomende opstelling voor een klein domein dat alleen e-mail verstuurt vanaf een 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

Indeling:

• v=spf1 → versiemarkering aan het begin, vereist door syntaxis.
• ip4:203.0.113.0/24 → Mechanisme dat alle IP-adressen autoriseert in het bereik 203.0.113.0 - 203.0.113.255.
• include:_spf.google.com → mechanisme waarmee de mailservers van Google namens het domein kunnen verzenden.
• include:_spf.mailhost.com → mechanisme dat servers van een andere derde partij toestaat.
• ~all → qualifier en mechanisme gecombineerd, wat betekent dat berichten van servers die niet op de lijst staan worden geaccepteerd, maar als verdacht worden gemarkeerd.
• exp=explain._spf.example.com → modifier die een aangepaste uitlegstring geeft wanneer een bericht niet door SPF komt.

Waarom het geldig is:

• Het record begint met de version tag.
• Meerdere mechanismen zijn opgenomen en goed geformatteerd.
• De kwalificatie ~ wordt toegepast op alledie is toegestaan.
• De modificator exp wordt correct gebruikt aan het einde, waardoor de functionaliteit wordt uitgebreid zonder de syntaxis te verbreken.

Deze opstelling is typisch voor organisaties die meerdere e-mailproviders gebruiken en toch ongeautoriseerde bronnen controleren.

Regels en validatie voor correcte SPF-syntaxis

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 records zo beknopt mogelijk - te complexe configuraties zijn moeilijker te onderhouden en de kans op fouten is groter.
  • Controleer SPF-records regelmatig, vooral als uw e-mailinfrastructuur verandert of als u providers toevoegt of verwijdert.

Veelvoorkomende syntaxfouten vermijden

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

• Versie-tag ontbreekt: elke record moet beginnen met v=spf1.
• Dubbele kwalificeerders: het gebruik van meer dan één kwalificeerder voor hetzelfde mechanisme is ongeldig.
• Overdreven mechanismen: Lange, opgeblazen records verhogen de kans op fouten en overschrijden DNS-limieten.
• Problemen met syntaxisopmaak: Verkeerd geplaatste spaties, typefouten of niet-ondersteunde tekens kunnen de record doen mislukken.
• Meerdere SPF-records : Een domein mag maar één SPF record hebben-als er meer dan één bestaat, zal de validatie mislukken.
• Afgeschreven mechanismen: vermijden ptrwordt 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 SPF record check tools, zoals de SPF-checker van PowerDMARC, om snel problemen 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 juiste SPF-recordsyntaxis is essentieel voor een veilige e-mailaflevering en bescherming tegen spoofing. Elk onderdeel, inclusief versie-tag, mechanismen, kwalificeerders en modificeerders, werkt samen om aan te geven hoe mailservers uw berichten behandelen.

Door best practices te volgen, fouten te vermijden en regelmatig te valideren, vermindert u het risico op fouten en houdt u uw domein veilig. Als uw e-mailconfiguratie evolueert, zijn voortdurende updates essentieel. Overweeg het gebruik van PowerDMARC voor eenvoudiger beheer en betere beveiliging.

Veelgestelde Vragen

Hoe schrijf je een SPF-record?

Begin met v=spf1, toevoegen mechanismen aan lijst geautoriseerde afzenders, en beëindigen met a kwalificatie zoals '-all' om al het andere te blokkeren.

Wat gebeurt er als de syntax van mijn SPF-record verkeerd is?

Mailservers kunnen uw e-mails weigeren of markeren als spam en uw domein wordt kwetsbaarder voor spoofing.

Wat is een voorbeeld van een SPF-record MX?

Een SPF-record met MX (MX record) ziet er als volgt uit: v=spf1 mx -allwaardoor alleen de mailservers van het domein e-mail kunnen versturen.

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

• Verzekeringsfraude begint in de inbox: hoe vervalste e-mails routinematige verzekeringsprocessen veranderen in diefstal van uitkeringen - 25 maart 2026
• FTC Safeguards Rule: Heeft uw financiële instelling DMARC nodig? - 23 maart 2026
• Wat is e-mailbeveiliging voor bedrijven: best practices en hoe het werkt - 23 maart 2026