Wat is v=spf1? Waarvoor dient het?

Je ziet hier een DNS-record dat begint met v=spf1, en je weet dat het belangrijk is, maar als je het wijzigt zonder het volledig te begrijpen, kan dit de e-mailbezorging voor je hele domein verstoren.

Eén ontbrekend `include:`, één opzoekactie te veel of één syntaxfout kan ertoe leiden dat e-mails de authenticatie niet doorstaan, in de spamfolder terechtkomen of direct worden geweigerd

SPF (Sender Policy Framework) vormt een essentieel onderdeel van e-mailverificatie. Het geeft ontvangende servers door welke afzenders namens u e-mails mogen versturen. De v=spf1 -tag activeert dat beleid, maar alles wat daarop volgt bepaalt of uw e-mails worden vertrouwd of geblokkeerd.

De uitdaging is dat SPF op het eerste gezicht eenvoudig lijkt, maar complexer wordt naarmate er meer afzenders, marketingtools en infrastructuur worden toegevoegd. Zoeklimieten, geneste includes en afstemmingsproblemen zorgen voor kwetsbare punten die niet altijd zichtbaar zijn, totdat de afleverbaarheid achteruitgaat.

In deze handleiding wordt precies uitgelegd wat v=spf1 betekent, hoe SPF-records zijn opgebouwd, hoe de evaluatie werkt en hoe je een record kunt opzetten en onderhouden dat in de praktijk niet faalt.

Hoe de SPF-beoordeling werkt

SPF-controle is een stapsgewijs validatieproces dat telkens wordt uitgevoerd wanneer er een e-mail wordt ontvangen. Hierbij wordt nagegaan of de verzendende server bevoegd is om namens het domein in het Return-Path te verzenden.

Zo werkt het in de praktijk:

• Er is een e-mail ontvangen die beweert afkomstig te zijn van uw domein: Het bericht komt aan op de mailserver van de ontvanger met zowel zichtbare headers (From) als verborgen routeringsgegevens (Return-Path).
• De ontvangende server haalt het Return-Path-domein eruit: Dit is het domein dat SPF daadwerkelijk controleert. Het vertegenwoordigt de afzender die tijdens de e-mailverzending is gebruikt.
• De server vraagt het DNS-systeem om het SPF-record (v=spf1): Hij zoekt het TXT-record op dat op dat domein is gepubliceerd. Als er geen SPF-record bestaat, is het resultaat Geen (geen authenticatie).
• Het IP-adres van de verzendende server wordt getoetst aan het SPF-record: De server verwerkt het SPF-record van links naar rechts:
  • Controleert elk mechanisme (ip4, inclusief, a, enz.)
  • Voert alle benodigde DNS-opzoekingen uit
  • Stopt bij de eerste regel die aan de voorwaarde voldoet
• Op basis van de overeenkomst wordt een resultaat gegenereerd: Mogelijke uitkomsten zijn onder meer:
  • Doorgeven → Afzender is geautoriseerd
  • Fout / SoftFout → Afzender is niet geautoriseerd (strikte versus soepele afhandeling)
  • Neutraal / Geen → Geen duidelijk beleid of geen SPF-record
  • PermError / TempError → SPF kon niet worden geëvalueerd vanwege fouten
• Het resultaat wordt gecombineerd met DKIM en DMARC: De SPF-waarde alleen is niet bepalend voor de aflevering. De ontvangende server gebruikt deze in combinatie met:
  • DKIM (integriteit van berichten)
  • DMARC (afstemming + beleid)
    om te beslissen of het bericht wordt geaccepteerd, gefilterd of geweigerd

Wat is een SPF-record?

Een SPF-record is een DNS TXT-record waarin alle servers en diensten worden vastgelegd die e-mail mogen verzenden namens uw domein. Wanneer er een e-mail wordt ontvangen, controleert de ontvangende server dit record om te verifiëren of de afzender geautoriseerd is.

Wat betekent v=spf1?

De v=spf1 tag is de identificatie die ontvangende mailservers aangeeft dat dit DNS TXT-record een SPF-beleid is. Het geeft aan dat het record moet worden geparseerd en geëvalueerd met behulp van de SPF-regels die zijn gedefinieerd in RFC 7208.

Zonder deze tag wordt het record helemaal niet als SPF behandeld, vindt er geen validatie plaats en beschikt het domein in feite niet over SPF-beveiliging.

Wanneer een ontvangende server je domein opzoekt:

• Het zoekt in TXT-records naar een record dat begint met v=spf1
• Alleen dat record wordt meegenomen bij de SPF-beoordeling
• Alles wat hierna volgt, wordt geïnterpreteerd als autorisatieregels (mechanismen, kwalificaties, modificatoren)

Om SPF correct te laten werken, moet v=spf1 aan strikte eisen voldoen:

• Moet helemaal aan het begin van het record staan
• Moet precies zo worden geschreven als v=spf1 (geen typefouten, geen extra spaties)
• Er mag slechts één SPF-record per domein bestaan

Als de versietag op enigerlei wijze onjuist is, wordt het hele record afgewezen:

• Helemaal ontbreekt → SPF-resultaten Geen (geen record gevonden)
• Verkeerd gespeld (v=spf 1, v=spf2, v=SPF1) → Ongeldige syntaxis → PermError
• Na een andere waarde geplaatst → Record wordt genegeerd omdat het onjuist is opgebouwd

De ontvangende servers kunnen uw SPF-beleid niet interpreteren, waardoor de authenticatie voor alle e-mails mislukt.

De opbouw van een SPF-record: een volledig overzicht van de syntaxis

Elk SPF-record heeft een vaste structuur, met een reeks regels die achtereenvolgens worden uitgevoerd. Door te begrijpen hoe elk onderdeel bij die evaluatie bijdraagt, voorkom je configuratiefouten.

Een SPF-record begint altijd met een versietag (v=spf1), gevolgd door een reeks mechanismen die geautoriseerde afzenders definiëren. Deze mechanismen kunnen worden gecombineerd met kwalificaties, die bepalen hoe overeenkomsten worden behandeld, en soms met modificaties, die bepalen hoe het record wordt geëvalueerd. Dit alles staat in één enkele regel tekst, maar elk element heeft direct invloed op hoe ontvangende servers de e-mail van uw domein interpreteren.

Voorbeeldrecord

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all 

ip4:192.0.2.0/24 (waarbij /24 een reeks van 256 IP-adressen vertegenwoordigt volgens de Classless Inter-Domain Routing (CIDR)-notatie)

Wat elk onderdeel doet

• v=spf1 identificeert het record als een SPF-beleid en maakt evaluatie mogelijk
• ip4:192.0.2.0/24 staat expliciet een bekend IP-bereik toe, meestal uw eigen infrastructuur
• voeg toe:_spf.google.com autoriseert Google Workspace door te verwijzen naar het SPF-record
• voeg toe:spf.protection.outlook.com doet hetzelfde voor Microsoft 365
• -all definieert het standaardbeleid: elke afzender die niet eerder is gevonden, wordt geweigerd

Deze combinatie zorgt voor een volledig autorisatiemodel: alleen specifieke bronnen worden toegestaan, al het andere wordt geweigerd.

Hoe evaluatie in de praktijk werkt

SPF wordt op een strikte, voorspelbare manier verwerkt:

• De ontvangende server leest het record van links naar rechts
• Elk mechanisme wordt achtereenvolgens getoetst aan het IP-adres van de verzendende server
• Zodra er een overeenkomst is gevonden, wordt de evaluatie onmiddellijk stopgezet
• De voorwaarde die aan dat mechanisme is verbonden, bepaalt het resultaat

Als er geen mechanisme overeenkomt:

• De het mechanisme fungeert als de terugvalbeslissing

Dit betekent dat SPF geen systeem is waarbij alles wordt gecontroleerd en vervolgens een beslissing wordt genomen. Het is een systeem waarbij de eerste die overeenkomt, wint.

SPF-mechanismen uitgelegd

Mechanismen vormen de kern van een SPF-record. Ze bepalen welke afzenders geautoriseerd zijn en vormen de logica die de ontvangende server toepast op het IP-adres van de afzender. Elk mechanisme voegt een regel toe, en samen vormen ze de toelatingslijst van uw domein.

Wat in de praktijk telt, is niet alleen wat elk mechanisme doet, maar ook hoe het zich tijdens de evaluatie gedraagt en welke invloed het heeft op de grenzen en de betrouwbaarheid.

De mechanismen worden achtereenvolgens beoordeeld, en het eerste mechanisme dat overeenkomt met het verzendende IP-adres bepaalt het resultaat. Dit betekent dat elk mechanisme dat u toevoegt invloed heeft op zowel de reikwijdte van de autorisatie als de complexiteit van de beoordeling.

Sommige mechanismen koppelen IP-adressen direct aan elkaar, terwijl andere een DNS-opzoeking nodig hebben om aanvullende gegevens op te halen. 

Hoe verschillende mechanismen werken

De zijn onder meer: mechanisme wordt het meest gebruikt en veroorzaakt het vaakst problemen met de opzoeklimiet als gevolg van geneste DNS-query's.

SPF staat maximaal 10 DNS-opzoekingen per evaluatie toe. Mechanismen die meetellen voor deze limiet:

• omvatten:
• a
• mx
• bestaat:
• omleiden=
• ptr

Mechanismen die dat niet doen:

• ip4:
• ip6:

Dit leidt tot een praktische afweging:

• Gemak (bijvoorbeeld:) → hogere opzoekkosten
• Controle (IPv4/IPv6) → lagere opzoekkosten, maar meer onderhoud

Uitleg over de SPF-kwalificaties

Kwalificaties bepalen welke actie er moet worden ondernomen wanneer een mechanisme overeenkomt. Terwijl mechanismen aangeven „wie er toegang heeft“, bepalen kwalificaties „wat er vervolgens moet gebeuren“. Samen bepalen ze hoe strikt uw SPF-beleid wordt gehandhaafd.

Elk mechanisme kan worden voorafgegaan door een kwalificatie. Als er geen kwalificatie is opgegeven, is de standaardwaarde ‘pass’ (+). De kwalificatie heeft direct invloed op hoe de ontvangende server de overeenkomst interpreteert en in hoeverre deze het bericht vertrouwt of afwijst.

Hoe kwalificaties zich gedragen tijdens de evaluatie

Wanneer een mechanisme overeenkomt:

• De voorwaarde die eraan is gekoppeld, bepaalt onmiddellijk het resultaat
• De SPF-beoordeling houdt daar op
• Dat resultaat wordt vervolgens (samen met DKIM en DMARC) gebruikt om te bepalen hoe het bericht wordt verwerkt

Dit betekent dat de kwalificatiewedstrijden definitieve beslissingssignalen in het SPF-proces.

Wat elke kwalificatie precies doet (in de context)

In de meeste SPF-records worden kwalificaties toegepast op de alle mechanisme aan het einde om het standaardbeleid te definiëren.

Hoe kwalificaties doorgaans worden gebruikt in SPF-records

De meeste SPF-records zijn op één plek afhankelijk van kwalificaties: de all mechanisme aan het einde.

• ~alle → Standaard zachte handhaving (monitoringfase)
• -alles → Standaard strikte handhaving (beleid klaar voor productie)

Deze laatste voorwaarde bepaalt hoe afzenders moeten worden behandeld die niet eerder expliciet zijn gevonden.

Praktische tips

• Begin met ~alles tijdens de installatie: Hierdoor kunt u de SPF-resultaten bekijken zonder legitieme afzenders te blokkeren die u mogelijk over het hoofd hebt gezien.
• Ga naar -alles zodra je record compleet is: Nadat je hebt gecontroleerd of alle geldige bronnen zijn opgenomen, schakel je over naar hardfail voor volledige handhaving.
• Vermijd ?all :Het biedt geen zinvolle bescherming of begeleiding aan ontvangende servers.
• Gebruik nooit +all:  Hierdoor kan elke afzender de SPF-controle doorstaan, waardoor authenticatie voor uw domein in feite wordt uitgeschakeld.

SPF-modificatoren uitgelegd (verduidelijkt)

Modificatoren vormen een klein maar belangrijk onderdeel van de SPF-syntaxis. In tegenstelling tot mechanismen bepalen ze niet wie er mag verzenden. In plaats daarvan beïnvloeden ze de manier waarop de SPF-evaluatie verloopt zodra het record wordt verwerkt.

Ze zijn optioneel en worden gebruikt in specifieke situaties waarin standaardregels op basis van mechanismen niet volstaan.

Hoe modifiers zich gedragen tijdens de evaluatie

Modificatoren worden verwerkt nadat de mechanismen zijn afgehandeld, en ze beïnvloeden de manier waarop het eindresultaat wordt bepaald of weergegeven.

• Ze komen niet overeen met de verzendende IP-adressen
• Ze geven afzenders niet rechtstreeks toestemming en weigeren hen ook niet
• Ze passen de stroom of resultaat van de SPF-evaluatie

Daarom worden modifiers doorgaans alleen gebruikt in geavanceerde of gestructureerde opstellingen, en niet in standaard SPF-records.

redirect= – volledige delegatie van SPF-evaluatie

De redirect= verplaatst de SPF-evaluatie naar een ander domein.

• Hiermee wordt aan de ontvangende server meegedeeld: „Negeer de rest van dit record en beoordeel de SPF aan de hand van het beleid dat voor een ander domein is gedefinieerd.”
• In tegenstelling tot omvatten::
  • voeg het volgende toe: voegt een ander beleid toe aan uw evaluatie
  • redirect= vervangt uw evaluatie volledig

Een voorbeeld:

v=spf1 redirect=_spf.voorbeeld.com

In dit geval:

• Uw domein heeft geen eigen SPF-regels gedefinieerd
• Alle evaluaties worden afgehandeld door _spf.example.com

Wanneer te gebruiken:

• Meerdere domeinen beheren met een gecentraliseerd SPF-beleid
• Zorgen voor consistentie tussen domeinen zonder dat records worden gedupliceerd

exp= – aangepaste uitleg voor fouten

De exp= modificator geeft een voor mensen leesbare uitleg wanneer SPF faalt.

• Het verwijst naar een DNS-record dat een tekstbericht bevat
• Dat bericht kan bij een storing naar de verzendende server worden teruggestuurd

Een voorbeeld:

v=spf1 -all exp=explain._spf.example.com

Hiermee kun je een eigen toelichting opgeven, bijvoorbeeld:

• Waarom het bericht niet is gelukt
• Wat de afzender nu moet doen

Hoe maak je een SPF-record aan

Een SPF-record is een gestructureerd, stapsgewijs proces. Het doel is om elke legitieme afzender nauwkeurig te vermelden, terwijl het record geldig, efficiënt en afdwingbaar blijft.

Elke stap is belangrijk, omdat de SPF-code precies zo wordt geïnterpreteerd als hij is geschreven. Als er een afzender ontbreekt of als er onjuiste logica is toegevoegd, kan dit direct gevolgen hebben voor de bezorging.

• Begin met v=spf1: Dit activeert SPF voor uw domein. Zonder dit wordt het record genegeerd en vindt er geen authenticatie plaats.
• Voeg je eigen verzendinfrastructuur toe (ip4: / ip6:): Neem alle servers op die u rechtstreeks beheert, zoals transactionele mailservers of interne systemen. Dit zijn de meest betrouwbare vermeldingen omdat ze niet afhankelijk zijn van externe DNS-lookups.
• Voeg je belangrijkste e-mailprovider toe (inclusief:): Als u een platform zoals Google Workspace of Microsoft 365 gebruikt, moet u hun SPF-record opnemen. Dit zorgt ervoor dat hun volledige verzendinfrastructuur namens u is geautoriseerd.

Elk omvat: voegt ten minste één DNS-lookup toe en kan extra geneste lookups introduceren, afhankelijk van de SPF-structuur van de provider.

• Voeg alle externe afzenders toe: Dit omvat marketingtools, CRM-systemen, ondersteuningsplatforms en alle diensten die e-mail versturen via uw domein. Elk daarvan moet expliciet worden geautoriseerd, omdat SPF externe diensten niet automatisch vertrouwt.
• Sluit af met uw beleid (~alles of -all): Hierin wordt bepaald hoe afzenders die hierboven niet worden genoemd, moeten worden behandeld:
  • ~alle → accepteren maar als verdacht behandelen (gebruikt tijdens de installatie)
  • -alle → ongeautoriseerde afzenders weigeren (wordt gebruikt zodra volledig gevalideerd)
• Publiceren als één DNS TXT-record: SPF staat slechts één record per domein toe. Alle mechanismen moeten in die ene vermelding worden gecombineerd.
• Controleer voor en na het publiceren: Controleer op syntaxfouten, opzoeklimieten en ontbrekende bronnen. Controleer ook het live DNS-record, niet alleen wat er is ingevoerd.

Het handmatig beheren van SPF wordt lastig naarmate er meer verzendbronnen bijkomen. Elke bron maakt het opzoeken complexer, en providers kunnen IP-adressen zonder voorafgaande kennisgeving wijzigen.

Hulpmiddelen zoals PowerSPF (Hosted SPF) van PowerDMARC automatiseren dit proces door:

• Zorg ervoor dat je binnen de limiet van 10 zoekopdrachten blijft
• IP-wijzigingen van providers automatisch bijwerken
• Het terugdringen van handmatige fouten en onderhoud

Zo zorgt u ervoor dat uw SPF-record geldig blijft en dat de afleverbaarheid op termijn niet wordt aangetast.

Voorbeeldrecord

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net -all

Wat deze opname eigenlijk doet

• Geeft toestemming voor een dedicated server (ip4:203.0.113.5)
• Geeft Google Workspace (inclusief:_spf.google.com)
• Geeft Mailchimp (include:servers.mcsv.net)
• Weigert elke afzender die niet expliciet is vermeld (-all)

Hierdoor ontstaat een gesloten en afdwingbaar beleid: alleen bekende bronnen kunnen berichten versturen, al het andere wordt geblokkeerd.

De limiet van 10 zoekopdrachten

De volgende mechanismen leiden tot DNS-opzoekingen:

• omvatten:
• a
• mx
• bestaat:
• omleiden=
• ptr (verouderd, maar telt nog steeds mee als het wordt gebruikt)

Bij deze mechanismen moet de ontvangende server een DNS-verzoek indienen om aanvullende gegevens op te vragen alvorens de evaluatie voort te zetten.

Wat telt NIET mee

Deze worden direct verwerkt en leiden niet tot DNS-verzoeken:

• ip4:
• ip6:
• alle
• v=spf1

Het probleem is dat SPF-problemen niet altijd direct zichtbaar zijn. Geneste includes, inactieve afzenders en verborgen IP-reeksen kunnen ervoor zorgen dat je record de limiet overschrijdt zonder dat dit direct opvalt.

Hoe het aantal zoekopdrachten toeneemt

Zelfs een klein SPF-record kan door geneste includes de limieten overschrijden. Zo neemt het aantal opzoekingen in de praktijk toe:

Hoewel er slechts vier zijn er: mechanismen zichtbaar zijn, kan het totale aantal opzoekingen de limiet van 10 opzoekingen overschrijden zodra geneste records worden geëvalueerd.

Limiet voor het opzoeken van ongeldige waarden (wordt vaak over het hoofd gezien)

SPF hanteert niet alleen een limiet van 10 DNS-zoekopdrachten, maar ook een limiet van twee ongeldige zoekopdrachten.

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

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

Veel voorkomende oorzaken:

• Onjuiste of verouderde zijn onder andere: domeinen
• Typografische fouten in SPF-mechanismen
• Verwijzingen naar domeinen die niet meer bestaan

Als er tijdens de SPF-evaluatie meer dan twee ongeldige zoekopdrachten plaatsvinden:

• SPF retourneert een PermError
• De volledige SPF-controle mislukt
• Legitieme e-mails kunnen hun authenticatie verliezen

In tegenstelling tot problemen met het aantal zoekopdrachten zijn ongeldige zoekopdrachten vaak moeilijker op te sporen, omdat ze het gevolg zijn van ongeldige of verouderde DNS-verwijzingen in plaats van zichtbare complexiteit.

Weet je niet precies hoeveel DNS-lookups je SPF-record gebruikt? 

Oplossingen zoals PowerDMARC’s SPF Analytics en Rapportage bieden:

• Inzicht in alle verzendbronnen en IP-adressen (zelfs de geneste)
• Opsporen van problemen met opzoeklimieten en verkeerde configuraties
• Duidelijke diagnose met concrete oplossingen

Zo wordt het makkelijker om te begrijpen wat je SPF-record precies doet en op welke punten het verbeterd kan worden.

Conclusie

SPF is een controlemechanisme dat bepaalt wie er e-mail mag versturen via uw domein. De v=spf1 tag zet dat proces in gang, maar de betrouwbaarheid van uw configuratie hangt af van hoe goed het record is opgebouwd, onderhouden en binnen de grenzen wordt gehouden.

De meeste problemen met SPF zijn niet te wijten aan een gebrekkige configuratie, maar aan verschuivingen, nieuwe tools die zijn toegevoegd zonder dat de configuratie is bijgewerkt, achtergebleven ongebruikte includes of opzoeklimieten die in de loop van de tijd zijn overschreden. Deze fouten blijven vaak onopgemerkt totdat ze de bezorging beïnvloeden.

Om ervoor te zorgen dat SPF naar behoren blijft werken:

• Zorg ervoor dat je administratie nauwkeurig en beknopt is
• Controleer regelmatig de verzendbronnen
• Houd u aan de zoeklimieten
• Wijzigingen controleren voor en na het publiceren

SPF werkt het beste wanneer het wordt beschouwd als een actief beheerproces in plaats van een eenmalige instelling. Als het goed wordt onderhouden, geeft het ontvangende servers een duidelijk en consistent signaal waarop ze kunnen vertrouwen, wat de afleverbaarheid en authenticatie binnen uw gehele e-mailprogramma direct ten goede komt.

Wacht niet tot SPF-fouten je e-mailverzending verstoren.

Krijg volledig inzicht in uw SPF-record, los opzoekingsproblemen op en zorg ervoor dat uw configuratie up-to-date blijft naarmate uw verzendinfrastructuur zich verder ontwikkelt. 

Ontdek hoe u SPF eenvoudig kunt controleren en beheren met PowerDMARC.

FAQs

1. Wat gebeurt er als mijn SPF-record ontbreekt of niet is geconfigureerd?

Als er geen SPF-record bestaat, sturen ontvangende servers een None resultaat. Dit betekent dat uw domein geen op SPF gebaseerde authenticatie heeft en dat ontvangers vertrouwen op andere signalen zoals DKIM of spamfilters. In de praktijk verhoogt dit het risico op spoofing en kan dit de afleverbaarheid negatief beïnvloeden.

2. Kan ik meer dan één SPF-record op mijn domein hebben?

Nee. Een domein mag precies één SPF-record hebben. Als meerdere TXT-records beginnen met v=spf1, retourneert de SPF-evaluatie een PermErroren mislukt de authenticatie voor alle e-mails. Voeg altijd alle verzendbronnen samen in één record.

3. Hoe weet ik of mijn SPF-record correct is?

Je moet drie zaken controleren:

• De syntaxis is correct (geen typefouten of opmaakfouten)
• Alle legitieme afzenders zijn opgenomen
• Het aantal DNS-zoekopdrachten blijft binnen de limiet van 10 zoekopdrachten

Gebruik een SPF-controleprogramma en bekijk de daadwerkelijke resultaten in de DMARC-rapporten om te controleren of alles naar behoren werkt.

4. Wat is het verschil tussen SPF Pass, Fail en PermError?

• Pass → De verzendende server is geautoriseerd
• Fout / SoftFout → De afzender is niet geautoriseerd (strikte versus soepele afhandeling)
• PermError → SPF werkt niet vanwege een verkeerde configuratie (bijv. te veel lookups, ongeldige syntaxis)

Een PermError is het ernstigst, omdat dit betekent dat de SPF helemaal niet kan worden beoordeeld.

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

Ja. SPF is een van de belangrijkste authenticatiesignalen die door DMARC worden gebruikt. Hoewel DKIM op zichzelf al voldoende kan zijn, zorgt het gebruik van zowel SPF als DKIM voor een grotere betrouwbaarheid en een bredere dekking. Veel ontvangers verwachten dat alle drie correct zijn geconfigureerd.

6. Biedt SPF bescherming tegen e-mailspoofing?

Op zichzelf niet. SPF controleert alleen het Return-Path-domein, niet het zichtbare ‘Van’-adres. Een aanvaller kan nog steeds de ‘Van’-header vervalsen en met zijn eigen domein door de SPF-controle komen. DMARC is nodig om afstemming af te dwingen en dit te voorkomen.

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

• Beleid tegen phishing in Office 365: hoe u dit instelt - 3 juni 2026
• Beveiliging van AI-agenten: risico’s, best practices en e-mailverificatie - 2 juni 2026
• PowerDMARC kan nu worden geïntegreerd met HaloPSA - 1 juni 2026