Defaults.Exposed › Oplossingen › SPF (Sender Policy Framework)

Hoe je SPF (Sender Policy Framework) oplost

SPF is de regel in de instellingen van uw domein die vermeldt welke mailservices namens uw bedrijf e-mail mogen versturen. Zonder SPF kan iedereen ter wereld e-mail versturen die eruitziet alsof die van u komt — en belandt uw eigen echte e-mail vaker in de spammap van klanten.

De kern voor je bedrijf: Iedereen kan e-mail versturen die zich voordoet als uw bedrijf — naar uw klanten, medewerkers en leveranciers — facturen, verzoeken om rekeningnummers te wijzigen, noem maar op. Tegelijk belanden uw echte offertes en facturen vaker bij de spam, waardoor deals stilletjes stranden.

Wat dit je kan kosten

Een oplichter stuurt uw klant een factuur «van u» met zijn eigen rekeningnummer en wordt betaald. U komt er pas weken later achter, als de klant vraagt waar zijn bestelling blijft — en nu staat uw reputatie op het spel, en mogelijk uw aansprakelijkheid.
Uw offertes, facturen en antwoorden belanden ongemerkt in de spammap van klanten, omdat grote providers niet kunnen bevestigen dat ze echt van u komen. Deals lopen dood en u komt nooit te weten waarom.
Een oplichter doet zich voor als uw eigenaar of financieel medewerker en mailt personeel met een dringend betaalverzoek of vraag om cadeaubonnen — het bericht lijkt echt van uw domein te komen, dus iemand betaalt.
Een grotere prospect laat de IT- of beveiligingsafdeling uw domein controleren, ziet geen afzenderbescherming en haakt af of eist eerst een oplossing voordat ze tekenen — dat kost u de deal of weken vertraging.
U denkt beschermd te zijn omdat er een SPF-record bestaat — maar het staat op «soft fail» zonder dat er iets handhaaft, of het is stilletjes kapot, dus vervalste e-mail komt nog steeds gewoon door.

Waarom het ertoe doet. Het vervalsen van het «van»-adres van een e-mail is kinderlijk eenvoudig en kost een aanvaller niets. SPF is de goedkoopste, snelste manier om uw domein moeilijker na te bootsen te maken en uw legitieme post uit de spam te houden. Google en Yahoo gooien e-mail van niet-geauthenticeerde domeinen nu actief weg of weigeren die, dus dit is niet langer optioneel — het is een basisvoorwaarde om uw e-mail überhaupt afgeleverd te krijgen.

De korte versie

Tenzij u SPF correct hebt ingesteld, kan op dit moment iedereen ter wereld e-mail versturen die lijkt te komen van uw bedrijf. Ze kunnen uw klanten nepfacturen mailen, uw personeel valse betaalverzoeken sturen, en uw leveranciers mailen alsof ze u waren — en de berichten zien er echt uit, omdat niets op uw domein anders aangeeft.

SPF (Sender Policy Framework) is de oplossing. Het is één enkele tekstregel in de instellingen van uw domein die vermeldt welke mailservices daadwerkelijk namens u e-mail mogen versturen. Ontvangende mailproviders — Gmail, Outlook, allemaal — controleren die lijst voordat ze beslissen of een bericht echt is. Geen lijst, of een zwakke, en ze hebben niets om op af te gaan.

Deze pagina behandelt twee dingen die allebei goed moeten zijn: of er überhaupt een SPF-record bestaat, en of het strikt genoeg is ingesteld om zijn werk echt te doen.

Wat dit u kan kosten

Dit zijn de alledaagse, praktische manieren waarop een ontbrekend of zwak SPF-record verandert in geld en vertrouwen dat de deur uit loopt. We noemen nooit een echt bedrijf — dit zijn de patronen die we in de data zien.

De factuuromleiding. Een crimineel stuurt een van uw klanten een e-mail die er precies uitziet alsof die van u komt, met een echt ogende factuur met zijn eigen rekeningnummer. Uw klant betaalt die. Het eerste wat u hoort is een herinnering met de vraag waar de bestelling blijft. Nu is er een boze klant, een betaling die naar een crimineel is gegaan, en een lastig gesprek over wie het verlies draagt.
De CEO-/financiënfraude. Iemand mailt uw boekhouder «van» de eigenaar: «Snel klusje — kun je deze betaling vandaag nog doorzetten?» Omdat het bericht echt van uw domein lijkt te komen, gaan er bij niemand alarmbellen rinkelen. Het geld verlaat het bedrijf.
De stille afleverbaarheidsbelasting. Uw offertes en facturen beginnen in de spammap van klanten te belanden, omdat Gmail en Yahoo niet kunnen bevestigen dat ze echt van u komen. U krijgt geen bounce, u krijgt geen foutmelding — deals worden gewoon stil. U verliest omzet en u kunt het niet eens zien gebeuren.
Het verloren contract. De inkoop- of beveiligingsafdeling van een grotere klant doet een basiscontrole op uw domein als onderdeel van de onboarding. Ze zien geen afzenderauthenticatie en markeren u als risico. In het beste geval moet u het onder tijdsdruk haastig oplossen; in het slechtste geval kiezen ze een concurrent die wel slaagde.
De merkvergiftigingsgolf. Uw domein wordt gebruikt in een phishingcampagne gericht op het publiek. Mensen die zijn opgelicht wantrouwen nu elke e-mail met uw naam erop — dus zelfs uw echte aanbiedingen en verlengingen worden genegeerd of gerapporteerd.

De rode draad door dit alles: de aanvaller geeft niets uit, en uw bedrijf draagt de kosten en de schuld.

Wat het eigenlijk is

Wanneer er een e-mail binnenkomt, wil de ontvangende mailserver één ding weten: komt dit echt van wie het beweert te komen? SPF beantwoordt een deel van die vraag.

U publiceert een korte tekstregel in de DNS-instellingen van uw domein — een «TXT-record» — die de mailservices noemt die namens u mogen versturen. Zoiets als:

v=spf1 include:_spf.google.com include:sendgrid.net -all

In gewone taal leest dat als: «Echte mail van ons komt van de servers van Google en van SendGrid — weiger al het andere dat beweert van ons te zijn.»

De twee delen die meetellen voor uw beoordeling:

Bestaat het record? Dit is de grote (het weegt het zwaarst van alle e-mailcontroles). Geen record betekent dat ontvangers geen lijst hebben om tegen te controleren, dus nabootsing ligt wagenwijd open. Er is hier ook een subtiel faalscenario: als uw domein twee of meer SPF-records heeft, schrijven de regels voor dat alle ervan ongeldig zijn — dus hebt u in feite helemaal geen SPF, ook al lijkt het van wel.
Is het beleid strikt genoeg? Een record kan bestaan maar toch tandeloos zijn. De afsluiting — het «all»-mechanisme — is de instructie aan ontvangers:
- -all (hard fail) — weiger alles wat niet op de lijst staat. Sterkst. Volle punten.
- ~all (soft fail) + DMARC op reject — de moderne aanbevolen opzet. Gelijkwaardige bescherming als hard fail, zonder het risico dat legitieme doorgestuurde mail bounced. Volle punten.
- ~all + DMARC op quarantine — acceptabel, iets zwakker; zet DMARC op reject voor volledige bescherming.
- ~all op zichzelf (geen DMARC-handhaving) — zwak. Dit zegt «waarschijnlijk nep, lever toch af». Vervalste mail komt nog steeds door. Dit is de val waar veel bedrijven in trappen, denkend dat ze beschermd zijn.
- ?all (neutraal) — biedt geen bescherming.
- +all — ronduit gevaarlijk: het vertelt de hele wereld dat iedereen namens u mag versturen. Gebruik dit nooit.

Er is nog een onzichtbaar faalscenario: SPF mag bij evaluatie maximaal 10 DNS-lookups uitvoeren. Stapel te veel include:-vermeldingen op en het record overschrijdt die limiet, waarop ontvangers het hele ding als kapot behandelen — en u bent terug bij geen bescherming. Dit is een veelvoorkomend, stil probleem voor bedrijven die veel marketing- en SaaS-tools gebruiken.

Hoe «goed» eruitziet: precies één SPF-record, met daarin elke service die legitiem namens u mailt, eindigend op -all (of ~all gekoppeld aan DMARC op p=reject), en ruim onder de 10-lookuplimiet.

Hoe los je het op (gratis, ~10 minuten)

Geef dit onderdeel aan wie uw domein of website beheert — en merk op dat de oplossing gratis is. Het is een wijziging in een DNS-instelling, geen product dat u koopt. Wij rekenen alleen kosten om te bewaken dat het in de loop van de tijd correct blijft, niet om de wijziging te maken.

Stap 1 — Som elke service op die namens u e-mail verstuurt. Dit is het deel dat mensen verkeerd doen. Schrijf ze allemaal op: uw mailboxprovider (Google Workspace, Microsoft 365, enz.), plus elke nieuwsbrieftool, CRM, helpdesk, e-commerceplatform, facturatie-/boekhoudapp en boekingssysteem. Als een service mail met uw naam verstuurt en u die vergeet, zal uw SPF die mail blokkeren wanneer u het beleid aanscherpt.

Stap 2 — Publiceer één TXT-record op uw hoofddomein. Combineer de «include»-regels voor al uw afzenders in één enkel record. Per veelgebruikt platform:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (of het domein dat bij uw regio past)

Een gecombineerd record ziet er zo uit:

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

Waar u het toevoegt, per provider:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = de waarde hierboven.
Microsoft 365 / Google admin: zij publiceren de exacte include-string in hun installatiewizard; kopieer die naar het TXT-record van uw DNS-host.
GoDaddy / de meeste hosts: DNS-beheer → Add → TXT, Host/Name @, Value = het record.

Stap 3 — Begin veilig, handhaaf daarna. Terwijl u bevestigt dat uw afzenderlijst compleet is, publiceer met ~all (soft fail) zodat er niets legitiems per ongeluk wordt geblokkeerd. Zodra u hebt bevestigd dat al uw echte mail nog doorkomt, scherp aan naar -all (hard fail) — of, beter nog, houd ~all en voeg een DMARC-beleid van p=reject toe, wat de aanbevolen moderne combinatie is.

Stap 4 — Zorg dat u precies ÉÉN record hebt. Als er al een oud SPF-record bestaat, bewerk dat ene in plaats van een tweede toe te voegen. Twee v=spf1-records heffen elkaar op en laten u onbeschermd.

Stap 5 — Houd het aantal lookups in de gaten. Als u veel afzenders hebt, kunt u de 10-lookuplimiet overschrijden. Gebeurt dat, consolideer dan — sommige providers bieden «SPF flattening», of schrap afzenders die u niet meer gebruikt.

Stap 6 — Controleer uw domein opnieuw om te bevestigen dat het nu slaagt, met het record aanwezig en het beleid strikt.

Veelgemaakte fouten

Twee SPF-records. Het meest voorkomende stille faalscenario. Een nieuw record toevoegen in plaats van het bestaande te bewerken maakt beide ongeldig. Er moet precies één zijn.
Stoppen bij ~all en aannemen dat u klaar bent. Soft fail zonder DMARC erachter is het zwakke middenveld — het lijkt geconfigureerd maar beschermt u nauwelijks. Ga ofwel naar -all, of koppel ~all aan DMARC p=reject.
Een afzender vergeten. Aanscherpen naar -all voordat u uw facturatie-app, CRM of nieuwsbrieftool hebt opgesomd, begint uw eigen legitieme mail te blokkeren. Som eerst alles op.
De 10-lookuplimiet overschrijden. Elke include: kan doorschakelen naar meer lookups. Te veel en het record wordt als kapot behandeld. Houd het slank.
+all gebruiken. Dit geeft expliciet het hele internet toestemming om namens u te versturen. Het is erger dan geen record hebben. Publiceer het nooit.

Waar dit past

SPF is het fundament, maar het is een van drie lagen. DKIM voegt een cryptografische handtekening toe die bewijst dat een bericht niet is geknoeid, en DMARC is de instructie die SPF en DKIM aan elkaar koppelt en ontvangers vertelt wat ze daadwerkelijk moeten doen met mail die faalt — inclusief het blokkeren van nabootsing van de zichtbare «van»-naam die uw klanten zien. Krijg SPF eerst goed (het is de snelste winst en weegt het zwaarst), voeg daarna DKIM en DMARC toe om de deur volledig dicht te doen. Alle drie de oplossingen zijn gratis.

Stel het in bij je host

Stap voor stap voor populaire providers:

Veelgestelde vragen

Ik ben niet technisch — kan ik dit zelf regelen?

U hoeft de details niet te begrijpen. De wijziging bestaat uit een of twee regels die worden toegevoegd aan de instellingen van uw domein, door wie uw website beheert of door uw IT-leverancier. Geef hun het onderdeel «Hoe los je het op» hieronder — het duurt meestal een paar minuten en is gratis. Wij rekenen alleen kosten voor het bewaken dat het in de loop van de tijd correct blijft.

We hebben al een SPF-record — betekent dat niet dat we gedekt zijn?

Niet per se. Een record hebben is de eerste helft; het strikt instellen is de tweede. Een record dat eindigt op «~all» (soft fail) zonder DMARC erachter zegt tegen ontvangende servers «dit is misschien nep, maar lever het toch maar af» — wat minimale bescherming biedt. Twee SPF-records, of één dat te veel lookups doet, wordt als kapot beschouwd en biedt helemaal geen bescherming ondanks dat het lijkt te bestaan. Beide helften moeten goed zijn.

Kan het oplossen hiervan per ongeluk mijn eigen e-mail breken?

Dat kan als het record een legitieme afzender mist — bijvoorbeeld uw facturatie-app of nieuwsbrieftool die mail met uw naam verstuurt. Precies daarom is de veilige aanpak om eerst elke service op te sommen die namens u mailt, te publiceren met een zachte «~all» terwijl u bevestigt dat niets ontbreekt, en dan aan te scherpen naar hard fail. In die volgorde gedaan breekt het niets.

Wat is het verschil tussen «~all» en «-all», en welke moeten we gebruiken?

«-all» (hard fail) zegt tegen ontvangers om alles te weigeren wat niet op uw lijst staat — de strengste instelling. «~all» (soft fail) zegt «waarschijnlijk niet legitiem, maar accepteer het toch». De moderne best-practice-aanbeveling is «~all» gecombineerd met een DMARC-beleid van «reject» — dat paar geeft u dezelfde bescherming als «-all» zonder het risico dat doorgestuurde mail bounced. «~all» op zichzelf, zonder DMARC die het handhaaft, is de zwakke configuratie die u moet vermijden.

Stopt SPF in zijn eentje alle e-mailspoofing?

Nee — het is de essentiële eerste laag, niet het hele antwoord. SPF bepaalt welke servers namens u mogen versturen, maar zegt ontvangers niet wat ze moeten doen als een bericht faalt, en het dekt niet de zichtbare «van»-naam die een gebruiker ziet. Om nabootsing volledig dicht te zetten wilt u ook DKIM en DMARC. SPF is de snelste, meest impactvolle eerste stap, dus begin hier en voeg daarna de andere twee toe.

Hoe lang voordat het werkt, en kan het iets kosten?

DNS-wijzigingen werken meestal binnen enkele minuten tot een paar uur. De oplossing zelf is altijd gratis — het is gewoon een instelling aanpassen bij uw DNS-provider. Wie u vertelt dat u een betaald product nodig hebt om een SPF-record toe te voegen, heeft het mis.