Een ondernemer belde ons vorig jaar in paniek: een leverancier had een factuur betaald op een ‘nieuw’ rekeningnummer, aangevraagd per mail vanuit zijn eigen bedrijfsnaam. Zijn website was niet gehackt. Zijn server was niet gekraakt. Er was helemaal niets ingebroken. Iemand had gewoon een e-mail verstuurd die eruitzag alsof die van hem kwam. Dat kon, omdat er nooit iemand had gecontroleerd of zijn domein wel beschermd was tegen spoofing. Dit gebeurt vaker dan bedrijven denken, en het is precies het type risico dat onder de radar blijft terwijl iedereen het over ‘hackers’ heeft.
SPF, DKIM en DMARC: de check die bijna niemand doet
Elk domein kan, zonder enige beveiliging, door wie dan ook worden ‘nagedaan’ in e-mailverkeer. Er bestaat geen ingebouwde controle die zegt: alleen deze partij mag mail versturen namens dit domein. Die controle moet je zelf instellen, met drie technische records in je DNS:
- SPF bepaalt welke mailservers namens jouw domein mogen versturen.
- DKIM voegt een digitale handtekening toe waarmee de ontvanger kan checken of de mail onderweg is aangepast.
- DMARC vertelt ontvangende mailservers wat ze moeten doen met berichten die niet aan SPF of DKIM voldoen: weigeren, in de spam gooien, of doorlaten.
Zonder DMARC-record op strict (policy=reject of quarantine) kan iemand met een paar minuten werk een mail sturen die er in Outlook of Gmail identiek uitziet als een bericht van jouw bedrijf. Wij checken dit standaard bij nieuwe klanten en zien bij zo’n zeven van de tien MKB-domeinen geen enkel DMARC-record, of eentje op ‘none’ die alleen monitort maar niets tegenhoudt. Dat is dweilen met de kraan open.
Wat je concreet moet doen
- Vraag je hostingpartij of IT-beheerder een DMARC-rapport op via een gratis tool zoals dmarcian of MXToolbox.
- Begin met policy=none om te zien wat er misgaat, zet dit binnen vier tot zes weken op quarantine of reject.
- Controleer ook subdomeinen: een vergeten testomgeving zonder SPF is net zo’n makkelijk startpunt voor spoofing.
Toegang is vaker het lek dan techniek
De meeste beveiligingsproblemen die wij tegenkomen zitten niet in kwetsbare software, maar in wie er allemaal ergens kan inloggen. Een veelgemaakte fout: het WordPress-beheeraccount is drie jaar geleden aangemaakt door een oud-medewerker of freelancer, en niemand heeft dat account ooit weer verwijderd. Diezelfde persoon heeft misschien ook nog toegang tot de domeinregistratie, de DNS-instellingen of Google Analytics.
Doe eens deze oefening: maak een lijst van alle plekken waar je bedrijf online ’toegang’ verleent — CMS, hosting, domeinregistrar, e-mail, social media, Google Search Console. Zet daarachter wie er precies bij kan. Bij de meeste bedrijven die wij overnemen staan er twee tot vier accounts op die niemand meer kan thuisbrengen. Elk van die accounts is een onbewaakte achterdeur.
Een account dat je vergeten bent, is een account dat een aanvaller nooit hoeft te kraken — hij hoeft het alleen maar te vinden.
Praktische aanpak
- Voer eens per kwartaal een ’toegangsaudit’ uit: wie kan waar bij, en klopt dat nog?
- Zet twee-factor-authenticatie aan op minimaal je CMS-login, domeinregistrar en hostingpaneel. Dit stopt het overgrote deel van geautomatiseerde inlogpogingen.
- Gebruik nooit één gedeeld wachtwoord voor meerdere systemen — als dat lekt via één zwakke plek, staat alles open.
De saaie administratie die je website kan platleggen
Domeinnamen en SSL-certificaten verlopen. Dat klinkt triviaal, maar we hebben gezien dat een bedrijf zijn domein kwijtraakte omdat de automatische incasso voor de jaarlijkse verlenging was gestopt na een bankwissel, en de herinneringsmail in het spamfilter van een oud e-mailadres belandde. Binnen 48 uur na het verlopen van een domein kan een derde partij het al claimen. Terugkrijgen kost dan weken juridisch heen-en-weer, als het al lukt.
- Zet domeinverlenging op automatische incasso én controleer jaarlijks handmatig of het gelukt is.
- Laat SSL-certificaten automatisch vernieuwen via je hostingpartij in plaats van los in te kopen — een verlopen certificaat geeft bezoekers een waarschuwingsscherm en kost je direct conversie.
- Zorg dat het contactadres bij je registrar een adres is dat je bedrijf blijft controleren, niet het privé-mailadres van iemand die drie jaar geleden vertrokken is.
Een back-up die je nooit test, is geen back-up
Bijna elke hostingpartij belooft dagelijkse back-ups. Wat bijna niemand doet: testen of die back-up ook daadwerkelijk terug te zetten is binnen een acceptabele tijd. Wij hebben klanten meegemaakt met een back-up van 40 gigabyte die technisch prima werkte, maar waarvan het terugzetten op de bestaande server drie uur duurde — tijdens piekuren op een dag met een grote actie. Drie uur offline tijdens een campagne kan zomaar duizenden euro’s aan gemiste omzet betekenen.
Vraag daarom niet alleen: heb ik back-ups? Vraag: hoe lang duurt het om terug online te zijn, en wanneer heb ik dat voor het laatst getest? Een back-up die niemand ooit heeft teruggezet, is in de praktijk een aanname, geen zekerheid.
- Plan minimaal één keer per jaar een testherstel, los van de productieomgeving.
- Leg vast wat je maximale acceptabele downtime is (RTO) en toets of je back-upoplossing daar daadwerkelijk aan voldoet.
- Bewaar back-ups ook buiten je eigen hostingomgeving — als de hele server platgaat, wil je niet afhankelijk zijn van een kopie op diezelfde machine.
De meeste online veiligheid draait niet om exotische aanvallen, maar om vergeten accounts, verlopen registraties en e-mailinstellingen die er nooit zijn geweest. Loop deze vier punten na en je hebt de risico’s afgedekt die in de praktijk het vaakst misgaan — vaak zonder dat een ondernemer het ooit merkt totdat het te laat is.