Een e-mail lijkt afkomstig van directeur@uwbedrijf.nl. Betekent dat automatisch dat de mail echt door uw bedrijf is verstuurd? Nee. Het zichtbare afzenderadres alleen is geen bewijs.
Daarom bestaan technieken zoals SPF, DKIM en DMARC. Ze helpen ontvangende mailservers controleren of berichten die namens een domein worden verstuurd technisch kloppen. Goed ingesteld kunnen ze misbruik van uw eigen domeinnaam lastiger maken en de betrouwbaarheid van zakelijke e-mail verbeteren.
Toch worden deze begrippen vaak onnodig ingewikkeld uitgelegd. In dit artikel leggen we uit wat SPF, DKIM en DMARC doen, hoe ze samenwerken en wat u als ondernemer of klein bedrijf praktisch moet controleren.
Kort antwoord: wat zijn SPF, DKIM en DMARC?
U kunt de drie technieken grofweg zo onthouden:
- SPF helpt aangeven welke mailservers namens uw domein mogen verzenden.
- DKIM voegt een digitale handtekening toe waarmee de ontvangende server de herkomst en integriteit van een bericht kan controleren.
- DMARC controleert of SPF en/of DKIM aansluiten op het domein dat de ontvanger als afzender ziet en geeft aan wat er met niet-goedgekeurde berichten moet gebeuren.
Samen vormen ze een belangrijke basis voor e-mailauthenticatie. Ze maken phishing niet onmogelijk, maar ze kunnen wel helpen voorkomen dat criminelen eenvoudig uw eigen domein gebruiken alsof een nepbericht echt van uw organisatie komt.
Waarom is e-mailspoofing een probleem voor bedrijven?
Zakelijke e-mail draait op vertrouwen. Klanten herkennen uw domeinnaam, medewerkers vertrouwen berichten van collega’s en leveranciers sturen facturen via e-mail. Dat vertrouwen maakt een bedrijfsdomein aantrekkelijk voor misbruik.
Een aanvaller kan bijvoorbeeld proberen een bericht te laten lijken alsof het afkomstig is van:
- directie@uwbedrijf.nl;
- administratie@uwbedrijf.nl;
- facturen@uwbedrijf.nl;
- hr@uwbedrijf.nl.
Het doel kan een nepbetaling, wachtwoorddiefstal, een valse IBAN-wijziging of het verkrijgen van gevoelige informatie zijn.
SPF, DKIM en DMARC helpen ontvangende maildiensten beoordelen of zo’n bericht technisch geauthenticeerd is. Dat is vooral belangrijk omdat een e-mailadres dat er betrouwbaar uitziet niet noodzakelijk betrouwbaar is.
Wat doet SPF?
SPF staat voor Sender Policy Framework. Via een DNS-record publiceert een organisatie welke systemen of diensten mail mogen versturen voor een domein.
Gebruikt uw bedrijf bijvoorbeeld Microsoft 365 voor gewone e-mail, Shopify voor winkelmails en een aparte dienst voor automatische berichten, dan moeten de relevante verzenddiensten correct in uw e-mailauthenticatie worden meegenomen.
Wanneer een ontvangende mailserver een bericht krijgt, kan die controleren of de verzendende server past bij het SPF-beleid van het relevante verzenddomein.
Een belangrijke nuance over SPF
SPF controleert technisch niet simpelweg het zichtbare adres achter “Van:”. SPF werkt primair met het domein dat in het SMTP-proces wordt gebruikt, bijvoorbeeld het Return-Path-domein. Dat is een van de redenen waarom DMARC nodig is: DMARC controleert de relatie, oftewel alignment, met het domein dat de ontvanger daadwerkelijk als afzender ziet.
Voor een ondernemer hoeft u die protocoldetails niet uit het hoofd te leren. De praktische les is: SPF alleen is niet genoeg om misbruik van het zichtbare afzenderdomein goed te beheersen.
Wat doet DKIM?
DKIM staat voor DomainKeys Identified Mail. De verzendende maildienst voegt een cryptografische handtekening toe aan de e-mail. De publieke sleutel waarmee de ontvangende server die handtekening controleert, staat in DNS.
In normale taal:
de verzender ondertekent de mail en de ontvanger kan controleren of die handtekening geldig is.
Een geldige DKIM-handtekening helpt bevestigen dat het bericht door een geautoriseerde verzendomgeving is ondertekend en dat relevante delen van de mail na ondertekening niet ongezien zijn gewijzigd.
DKIM versleutelt uw e-mail niet
Dit is een veelgemaakte verwarring. DKIM is geen techniek waarmee de inhoud van de e-mail geheim wordt gemaakt. Het gaat om authenticatie en integriteit, niet om end-to-end-versleuteling van de inhoud.
Ook is DKIM niet automatisch goed geregeld omdat er ergens één DKIM-record in DNS staat. Iedere verzenddienst die namens uw organisatie mailt moet correct worden ingericht volgens de instructies van die dienst.
Wat doet DMARC?
DMARC staat voor Domain-based Message Authentication, Reporting and Conformance. DMARC bouwt voort op SPF en DKIM en kijkt of de authenticatie aansluit op het domein in het zichtbare afzenderadres.
Daarnaast kan de eigenaar van een domein via DMARC aangeven hoe ontvangende partijen moeten omgaan met berichten die niet aan de controles voldoen.
Bekende beleidsniveaus zijn:
- p=none – monitoren zonder een afwijzingsbeleid af te dwingen;
- p=quarantine – mislukte berichten kunnen bijvoorbeeld als verdacht of spam worden behandeld;
- p=reject – ontvangende systemen wordt gevraagd berichten die niet voldoen af te wijzen.
DMARC kan daarnaast rapportages opleveren waarmee u ziet welke diensten namens uw domein mail proberen te versturen en of die authenticatie slaagt.
Waarom moeten SPF, DKIM en DMARC samenwerken?
Zie e-mailauthenticatie niet als drie losse vinkjes. De waarde ontstaat vooral doordat de technieken samenwerken.
Een vereenvoudigd voorbeeld:
- Een bericht zegt zichtbaar afkomstig te zijn van uwbedrijf.nl.
- SPF beoordeelt of de verzendende infrastructuur voor het gebruikte verzenddomein is toegestaan.
- DKIM controleert de digitale handtekening van het bericht.
- DMARC controleert of ten minste een geldige authenticatiemethode correct is afgestemd op het zichtbare afzenderdomein.
- Op basis van het DMARC-beleid kan de ontvangende partij het bericht accepteren, strenger behandelen of afwijzen.
Daarom is alleen “we hebben SPF” geen volledige e-mailbeveiligingsstrategie.
Wat lossen deze technieken niet op?
SPF, DKIM en DMARC zijn belangrijk, maar geen wondermiddel. Zelfs bij een sterk DMARC-beleid kunnen aanvallers nog andere vormen van misleiding gebruiken.
Een lookalike-domein
Een crimineel kan een domein registreren dat sterk lijkt op het uwe. Bijvoorbeeld een kleine spelfout of een andere extensie. SPF, DKIM en DMARC op uw eigen domein blokkeren zo’n ander domein niet automatisch.
Een misleidende weergavenaam
Een bericht kan bijvoorbeeld de zichtbare naam “Directeur IdenScan” tonen terwijl het echte e-mailadres van een volledig ander domein komt. E-mailauthenticatie helpt bij domeincontrole, maar medewerkers moeten nog steeds leren het volledige adres en de context te controleren.
Een echt gehackt account
Als een aanvaller daadwerkelijk toegang krijgt tot een legitiem account of geautoriseerde verzenddienst, kan een bericht technisch correct geauthenticeerd zijn. Daarom blijven MFA, accountbeveiliging, monitoring en bewustwording nodig.
Veelgemaakte SPF-fouten
Een SPF-record lijkt eenvoudig, maar fouten komen regelmatig voor.
- Een bedrijf vergeet een verzenddienst die wel namens het domein mailt.
- Een oude leverancier blijft in het SPF-record staan nadat de samenwerking is gestopt.
- Er worden meerdere losse SPF-records voor hetzelfde domein aangemaakt in plaats van één correct samengesteld beleid.
- Automatische mails uit formulieren, CRM-systemen of webshops worden vergeten.
- Wijzigingen in de mailinfrastructuur worden niet meegenomen in DNS.
Google adviseert organisaties expliciet om alle verzenders te inventariseren, waaronder webservers, contactformulieren en externe diensten die namens het domein mail sturen.
Veelgemaakte DKIM-fouten
- Een DKIM-record is aangemaakt, maar ondertekening staat bij de mailprovider nog niet aan.
- Een organisatie controleert slechts één maildienst terwijl meerdere platformen berichten versturen.
- Een uitgaande gateway wijzigt een bericht na ondertekening, waardoor DKIM kan mislukken.
- Oude selectors en sleutels blijven onbeheerd staan.
Een goede controle kijkt daarom niet alleen of een DNS-record bestaat, maar ook of echte uitgaande berichten daadwerkelijk een geldige DKIM-status krijgen.
Veelgemaakte DMARC-fouten
De meest voorkomende fout is DMARC zien als een record dat u één keer plaatst en daarna vergeet.
Een andere fout is direct een streng p=reject-beleid instellen zonder eerst alle legitieme verzendstromen in beeld te brengen. Daardoor kunnen echte bedrijfsberichten onbedoeld problemen krijgen.
Google adviseert daarom een gefaseerde uitrol: eerst SPF en DKIM goed instellen, vervolgens DMARC beginnen met monitoring en rapportages beoordelen, en daarna gecontroleerd naar een strenger beleid gaan wanneer de legitieme mailstromen correct zijn ingericht.
Hoe controleert u of uw bedrijf dit goed heeft ingesteld?
Een praktische controle bestaat uit meer dan zoeken naar drie DNS-records. Kijk minimaal naar:
- welke diensten namens uw domein e-mail verzenden;
- of SPF al die legitieme verzenders correct dekt;
- of uitgaande berichten daadwerkelijk met DKIM worden ondertekend;
- of DMARC aanwezig is en welk beleid actief is;
- of SPF- of DKIM-authenticatie aligned is met het zichtbare From-domein;
- of DMARC-rapportages worden ontvangen en beoordeeld;
- of oude of ongebruikte verzenddiensten nog onnodig zijn toegestaan.
Voer DNS-wijzigingen niet blind uit op basis van een online generator. Een verkeerd SPF- of DMARC-record kan legitieme mailstromen verstoren. Breng daarom eerst alle verzenddiensten in kaart.
Wat moet een klein bedrijf als eerste doen?
Begin niet met technisch jargon. Begin met de simpele vraag: wie verstuurt er allemaal e-mail namens ons domein?
Denk aan:
- Microsoft 365 of Google Workspace;
- Shopify;
- nieuwsbriefsoftware;
- CRM- en facturatiesystemen;
- contactformulieren;
- supportsoftware;
- automatische CyberCheck-, afspraak- of ordermails;
- externe marketing- of transactional-emailproviders.
Pas als die lijst compleet is, kunt u SPF, DKIM en DMARC verantwoord beoordelen en verbeteren.
Waarom dit ook een medewerkersrisico blijft
Techniek kan veel nepberichten tegenhouden, maar medewerkers blijven belangrijke beslissingen nemen. Een frauduleus bericht vanaf een lookalike-domein kan nog steeds overtuigend zijn. Hetzelfde geldt voor een echt gehackt leveranciersaccount.
Daarom moet e-mailbeveiliging worden gecombineerd met simpele werkafspraken. Denk aan:
- bel terug via een bekend nummer bij een onverwachte IBAN-wijziging;
- keur een spoedbetaling niet via één kanaal goed;
- open loginpagina’s bij twijfel zelf via de bekende website;
- maak duidelijk waar medewerkers verdachte e-mail melden.
Laat uw e-mailbasis eerst controleren
Weet u niet hoe uw zakelijke e-mail er vanaf de buitenkant voor staat? Met de gratis IdenScan Team Risico Check kijken we onder andere naar openbare signalen rond SPF, DKIM, DMARC en uw domein.
We vragen geen wachtwoorden, geen inbox-toegang en geen systeemtoegang. U krijgt een praktische eerste terugkoppeling over zichtbare aandachtspunten en wat logisch is om als eerste te verbeteren.
Veelgestelde vragen over SPF, DKIM en DMARC
Heb ik DMARC nodig als SPF al goed staat?
SPF alleen beschermt het zichtbare afzenderdomein niet volledig. DMARC voegt alignment en beleid toe en werkt samen met SPF en DKIM.
Is DKIM hetzelfde als versleutelde e-mail?
Nee. DKIM is een digitale ondertekening voor authenticatie en integriteitscontrole. Het versleutelt de inhoud van de e-mail niet voor de ontvanger.
Kan DMARC alle phishing namens mijn bedrijf stoppen?
Nee. DMARC kan misbruik van uw eigen domein aanzienlijk moeilijker maken wanneer het goed is ingericht, maar beschermt niet automatisch tegen lookalike-domeinen, misleidende weergavenamen of berichten vanuit echt gecompromitteerde accounts.
Kan ik meteen p=reject instellen?
Dat kan technisch, maar zonder inzicht in alle legitieme verzendstromen kan dit echte mail blokkeren. Een gecontroleerde uitrol en monitoring is meestal verstandiger.
Moet iedere externe verzenddienst DKIM hebben?
Iedere dienst die namens uw domein verstuurt moet passend worden geauthenticeerd. Welke SPF-, DKIM- en DMARC-inrichting nodig is, hangt af van de betreffende provider en uw mailarchitectuur.
Bronnen
- Google Workspace Admin Help – SPF instellen
- Google Workspace Admin Help – DKIM instellen
- Google Workspace Admin Help – aanbevolen DMARC-uitrol
- IETF RFC 7489 – DMARC-specificatie
Laatst inhoudelijk gecontroleerd op 9 september 2026. De juiste DNS-instellingen verschillen per e-mailprovider en verzendomgeving. Pas records niet aan zonder eerst uw legitieme mailstromen te inventariseren.