Vorige maand kreeg een klant van ons een telefoontje van een boze debiteur: die had een factuur ontvangen met een gewijzigd rekeningnummer, keurig verstuurd vanaf het echte e-mailadres van de ondernemer. Alleen had die ondernemer nooit zo’n mail verstuurd. Iemand anders deed dat namens hem, via zijn eigen domeinnaam. Dit heet domeinspoofing en het is een van de meest onderschatte veiligheidsrisico’s in het MKB, simpelweg omdat het onzichtbaar is totdat het misgaat.
Waar de meeste beveiligingsadviezen gaan over wachtwoorden, plugins of back-ups, blijft e-mailbeveiliging vaak liggen. Terwijl juist dit kanaal bepaalt of criminelen uw goede naam kunnen misbruiken om klanten, leveranciers of medewerkers op te lichten.
Waarom dit zo makkelijk is
E-mail werkt van oudsher op vertrouwen, niet op verificatie. Het protocol achter e-mail (SMTP) controleert standaard niet of de afzender is wie hij zegt te zijn. Wie weet hoe het werkt, kan met een paar regels code een mail versturen die in de inbox van uw klant precies zo verschijnt als een echte mail van u: zelfde naam, zelfde adres, zelfde logo in de handtekening als die is meegekopieerd.
Zonder aanvullende maatregelen accepteert de mailserver van de ontvanger die mail gewoon. Er is niets vals aan te zien, behalve dan de inhoud: een gewijzigd rekeningnummer, een malafide bijlage, of een dringend verzoek om in te loggen op een nagemaakte pagina.
De drie regels die het verschil maken
Er bestaan drie technische standaarden die samen bepalen of een mailserver een bericht namens uw domein als legitiem herkent. Ze worden ingesteld via DNS-records, dus zonder dat u iets aan uw mailprogramma hoeft te veranderen.
SPF: wie mag namens u mailen
Een SPF-record (Sender Policy Framework) is een lijst van servers die officieel e-mail mogen versturen namens uw domein. Stuurt u mail via bijvoorbeeld Microsoft 365, uw hostingpakket en een nieuwsbriefsysteem, dan moeten al die afzenders in dat record staan. Ontbreekt een dienst, dan belanden uw eigen mails soms zelf in de spamfilter van de ontvanger – een veelvoorkomende, maar onterecht als ‘mailprobleem’ bestempelde klacht.
DKIM: een digitale handtekening
DKIM (DomainKeys Identified Mail) plaatst een cryptografische handtekening in elke uitgaande mail. De ontvangende server kan die handtekening controleren aan de hand van een publieke sleutel in uw DNS. Is de mail onderweg aangepast, dan klopt de handtekening niet meer en wordt het bericht gewantrouwd.
DMARC: de regel die de andere twee afdwingt
Dit is de standaard die vaak vergeten wordt, terwijl hij het belangrijkst is. DMARC vertelt ontvangende mailservers wat ze moeten doen als een bericht faalt op SPF of DKIM: negeren (none), naar de spammap sturen (quarantine) of volledig weigeren (reject). Zonder DMARC-record, of met een DMARC-record op none, heeft al uw SPF- en DKIM-werk in feite geen effect: de vervalste mail wordt gewoon afgeleverd.
De meest gemaakte fout: DMARC instellen en op ‘none’ laten staan
Veel bedrijven die wel eens van DMARC hebben gehoord, zetten het record neer met beleid p=none en gaan verder met hun dag. Dat is begrijpelijk: none is de veilige eerste stap, want u wilt niet per ongeluk uw eigen nieuwsbrief blokkeren. Het probleem is dat negen van de tien bedrijven daar blijven hangen, jarenlang, zonder ooit door te schakelen naar quarantine of reject. Daarmee monitort u wel wie uw domein misbruikt, maar stopt u het niet.
Stappenplan om het goed te doen
- Week 1: zet SPF en DKIM correct in voor alle systemen die namens u mailen (mailprogramma, factuursoftware, nieuwsbriefdienst, CRM).
- Week 1: voeg een DMARC-record toe met beleid p=none en een rapportage-adres (het rua-veld), zodat u dagelijks een overzicht krijgt van alle mail die namens uw domein wordt verstuurd.
- Week 2 t/m 6: lees de rapporten. Ziet u onbekende IP-adressen die falen op SPF of DKIM, dan weet u dat er misbruik plaatsvindt of dat u een dienst vergeten bent.
- Na 6 weken: als alle legitieme afzenders slagen, zet het beleid naar p=quarantine.
- Na 3 maanden: zet het beleid naar p=reject. Vanaf dit moment wordt vervalste mail namens uw domein simpelweg niet meer afgeleverd, ongeacht wie hem verstuurt.
Dit proces kost geen budget, alleen tijd en discipline om de tussenstappen niet over te slaan. Wij zien regelmatig ondernemers die na de eerste stap denken klaar te zijn, terwijl het beschermende effect pas ontstaat bij reject.
Wat dit oplevert, in cijfers
Onderzoek van grote mailboxproviders laat zien dat domeinen met een DMARC-beleid op reject tot meer dan 99% van de vervalste berichten geblokkeerd krijgen voordat ze de inbox van de ontvanger bereiken. Zonder DMARC-beleid, dus met alleen SPF en DKIM, ligt dat percentage vaak niet hoger dan 60 tot 70%, omdat ontvangende servers zelf mogen bepalen hoe streng ze reageren op een mislukte controle.
Een klant van ons ontdekte via de DMARC-rapporten dat er structureel vanuit een datacenter in Oost-Europa mail werd verstuurd namens zijn domein, gericht aan zijn eigen leveranciers. Na het instellen van reject stopte dat volledig, binnen 48 uur.
Waar dit thuishoort in uw beveiligingsbeleid
SPF, DKIM en DMARC zijn geen eenmalige actie maar onderdeel van beheer, net als het updaten van software of het controleren van back-ups. Nieuwe diensten die namens u mailen – denk aan een boekhoudpakket, een sollicitatietool of een marketingautomation-systeem – moeten steeds worden toegevoegd aan het SPF-record. Vergeet u dat, dan zakt uw beleid effectief terug naar een lager beschermingsniveau, ook al staat DMARC nog op reject.
Voor MKB-bedrijven die hun mail via managed hosting laten lopen, nemen wij deze controle standaard mee in het periodieke onderhoud, juist omdat het zo weinig zichtbaar is totdat een klant belt over een factuur die u nooit heeft verstuurd.