E-mailbeveiligingsachterstand: de cyberbeveiligingsindicator die niemand meet

Elk beveiligingsteam rapporteert met overtuiging bepaalde cijfers: geblokkeerde phishingpogingen, gedetecteerde malware, mislukte inlogpogingen, blootgestelde inloggegevens, gemiddelde reactietijd. Wat bijna niemand rapporteert, is het werk dat al maanden geleden af had moeten zijn en steeds weer naar de volgende sprint wordt uitgesteld.

Die achterstand heeft een naam die het waard is om te gebruiken: e-mailbeveiligingsachterstand — de onopgeloste problemen op het gebied van authenticatie, eigendom en configuratie die zich in uw e-mailinfrastructuur opstapelen en die steeds duurder worden om op te lossen naarmate uw organisatie eromheen groeit.

E-mail is buitengewoon goed in het verzamelen van dit soort gegevens. Een nieuw SaaS-platform begint namens jou e-mails te versturen. Een DNS-record wordt tijdens een migratie gewijzigd. Een ‘tijdelijk’ subdomein blijft actief. Een leverancier blijft toegangsgegevens versturen lang nadat het project is afgerond. Op zich lijkt elk van deze zaken een klusje van vijf minuten.

Hoe ‘e-mailbeveiligingsachterstand’ er in de praktijk uitziet

Het concept is ontleend aan het begrip ‘technische schuld’ in de softwareontwikkeling. Je neemt een kortere weg om het probleem van vandaag op te lossen en schuift de onderhoudskosten door naar je toekomstige zelf.

E-mailsystemen verzamelen die snelkoppelingen in een mum van tijd, omdat de verzendinfrastructuur bijna nooit onder één enkel team valt. Marketing beheert het campagneplatform. HR is verantwoordelijk voor de wervingstool. De helpdesk beheert het ticketsysteem. Ontwikkelaars koppelen twee of drie API’s voor transactionele e-mails aan elkaar. IT blijft achter met het onderhouden van de DNS-records die het geheel bij elkaar houden.

Typische symptomen:

• Onbekende verzenddiensten die nog steeds je domein gebruiken;
• Overgebleven SPF-mechanismen van een migratie die twee jaar geleden is afgerond;
• DKIM-sleutels die verwijzen naar diensten die niemand meer gebruikt;
• DMARC-beleidsregels in de monitoringmodus geplaatst zonder duidelijke eigenaar;
• Tijdelijke subdomeinen die nooit meer zijn gecontroleerd;
• Externe leveranciers die ook na afloop van hun contract nog steeds toegang hebben om berichten te verzenden.

Geen van deze gebeurtenissen leidt op de dag zelf tot een incident. Dat is precies de reden waarom ze blijven bestaan.

Verificatie wordt mettertijd steeds ingewikkelder

Het instellen van SPF, DKIM en DMARC op een gloednieuw domein is echt heel eenvoudig. Het lastige is om deze drie door de jaren heen, ondanks veranderingen in de infrastructuur, correct te houden.

Neem SPF als voorbeeld. Je begint met Google Workspace en één marketingprovider. Vervolgens voegt de verkoopafdeling een platform toe, krijgt de wervingsafdeling een eigen systeem en koppelt de technische afdeling een e-mail-API aan. Het aantal records groeit, maar oude records worden zelden in hetzelfde tempo verwijderd — en zo raken domeinen uiteindelijk de opzoeklimieten, waardoor dubbele SPF-records worden gepubliceerdof SPF-fouten ontstaan die niemand kan verklaren. Het onder de knie krijgen van de SPF-syntaxis eenmalig goed in te stellen is eenvoudig; ervoor zorgen dat deze correct blijft, is onderhoud.

DKIM volgt dezelfde levenscyclus. Sleutels zijn gekoppeld aan specifieke afzenders, en afzenders kunnen veranderen. Een gepubliceerde selector kan technisch gezien nog lang geldig blijven nadat de dienst erachter uit de dagelijkse bedrijfsvoering is verdwenen, en begint DKIM te falen om redenen die verborgen liggen in een ticket uit 2023.

Hier komt de DMARC-rapportage goed van pas. Geaggregeerde rapporten laten zien welke systemen daadwerkelijk e-mail versturen onder de naam van uw domein — en niet welke systemen u denkt dat dat doen. Door die rapporten te lezen maakt van onzichtbare afwijkingen een lijst waarmee u aan de slag kunt, en PowerDMARC biedt u inzicht in DMARC, SPF en DKIM in één overzicht, in plaats van dat uw team elk record als een op zichzelf staande DNS-taak moet behandelen.

Dat geeft een andere invalshoek aan de vraag. „Is DMARC ingeschakeld?” is geen zinvolle vraag. „Weten we welke diensten er momenteel namens ons domein e-mails versturen, en horen die allemaal nog steeds bij ons domein?” is dat wel.

Het probleem van de vergeten afzender

Er is sprake van een zekere mate van e-mailbeveiligingsachterstand, zelfs als alle gegevens technisch gezien correct zijn.

Stel je een webinarplatform voor dat twee jaar geleden is geautoriseerd. De medewerker die het heeft geconfigureerd, is inmiddels vertrokken. Er is al maanden niets meer met het account gedaan. Het kan nog steeds geauthenticeerde e-mails versturen via je bedrijfsdomein.

Vanuit het oogpunt van een aanvaller betekent ‘oud’ niet hetzelfde als ‘onschadelijk’. Een vergeten account is een veilige toegangsweg tot je e-mailomgeving waar niemand op let.

Een degelijke beoordeling van de afzender geeft antwoord op zes praktische vragen:

• Welk systeem verstuurt deze e-mail?
• Welk team is eigenaar van het account?
• Welk domein of subdomein wordt er gebruikt?
• Voldoet het aan de SPF- en DKIM -vereisten?
• Wanneer is het voor het laatst op legitieme wijze gebruikt?
• Wie is bevoegd om het te verwijderen?

Die laatste vraag zorgt vaak voor meer vertraging dan het hele technische onderzoek. Het opsporen van een overbodige afzender kost slechts enkele minuten. Het verkrijgen van toestemming om deze uit te schakelen kan weken duren.

E-mailverificatie biedt geen volledige bescherming tegen de aanval

Een andere vorm van afhankelijkheid doet zich voor wanneer een bedrijf verwacht dat één controlemaatregel een probleem kan oplossen dat buiten zijn werkterrein valt.

DMARC in de handhavingsfase maakt directe domeinspoofing zeer moeilijk. Het houdt niet elk phishingbericht tegen. Aanvallers schakelen dan over op vergelijkbare domeinen, gehackte accounts van derden, kwaadaardige bijlagen en overtuigende pagina's voor het verzamelen van inloggegevens.

Op dat moment gaat het probleem verder dan de authenticatie van de afzender. Zodra een schadelijk bestand of een schadelijke link het apparaat van een gebruiker bereikt, ben je aangewezen op endpointdetectie, browserbeveiliging, URL-filtering of een antivirusoplossing van de volgende generatie oplossing om op te sporen wat er toch is doorgedrongen.

Die verdeling van verantwoordelijkheden is belangrijker dan doorgaans wordt erkend. De ene organisatie kan een strikte DMARC-handhaving hanteren en toch gebruikers blootstellen aan risico’s zodra ze ergens op klikken. Een andere organisatie kan flink investeren in beveiligingstools voor eindpunten, terwijl een tiental vergeten diensten nog steeds bevoegd blijft om vertrouwde e-mail vanaf haar domein te versturen. De ‘e-mailbeveiligingsschuld’ zit vaak in de kloof tussen deze twee.

Waarom dit zelden op een dashboard te zien is

Er bestaat geen standaardmaatstaf voor de ‘beveiligingsschuld’ op het gebied van e-mail, waardoor het veel moeilijker is om hierover verslag uit te brengen dan over het percentage klikken op phishing-links of een MTTR-cijfer.

Uit een kwartaaloverzicht zou kunnen blijken dat 98% van de legitieme e-mail de authenticatie doorstaat. Dat is geruststellend — maar zegt niets over de vier verlaten SaaS-accounts die nog steeds geauthenticeerde berichten kunnen versturen. Hetzelfde geldt voor het bereiken van p=reject op je primaire domein bereikt, betekent nog niet dat de bredere omgeving in orde is. Subdomeinen, externe afzenders en onopgeloste DMARC-fouten vallen allemaal buiten dat hoofdcijfer.

Een eerlijker dashboard houdt niet alleen de succesvolle zaken bij, maar ook de nog onopgeloste:

• Onbekende afzenders;
• Erkende diensten zonder actieve eigenaar;
• Fouten bij de authenticatie zijn nog steeds niet onderzocht;
• Inactieve platforms mogen nog steeds berichten versturen;
• Domeinen die langer dan de afgesproken periode in de bewakingsmodus blijven langer dan een overeengekomen periode.

Ook de leeftijd hoort op dat dashboard thuis. Een afzender die gisteren is ontdekt, is een onderzoek. Dezelfde afzender die negen maanden later nog steeds niet is opgelost, is een vordering.

Geef elke uitzondering een levenscyclus

Programma’s voor e-mailbeveiliging lopen zelden vast door ingrijpende problemen. Ze lopen vast door tijdelijke uitzonderingen, verouderde spreadsheets, verlaten tickets en gegevens waar niemand iets mee te maken wil hebben omdat onduidelijk is wie er verantwoordelijk voor is.

De oplossing is niet bepaald spectaculair: elke onopgeloste uitzondering met betrekking tot de afzender of authenticatie krijgt een verantwoordelijke, een gedocumenteerde reden voor het bestaan ervan en een evaluatiedatum. Die ene wijziging zorgt ervoor dat verwaarloosde infrastructuur weer zichtbaar wordt.

Je kunt beginnen met wat er al is gepubliceerd. Controleer je huidige configuratie en voer je domein in bij een domeinanalysetoolen gebruik vervolgens DMARC-rapporten om te vergelijken wat geautoriseerd is met wat er daadwerkelijk wordt verzonden.

Deze maatstaf zal nooit volkomen objectief zijn, en dat hoeft ook niet. De waarde ervan ligt in de praktijk. Oude afzenders, verouderde records, half afgeronde DMARC-implementaties en de hiaten tussen e-mail- en eindpuntbeveiliging worden niet langer gezien als achtergrondruis, maar als taken waaraan je prioriteit kunt geven. Dat is precies het nut van het benoemen van e-mailbeveiligingsachterstanden: wat gemeten wordt, wordt ingepland.

FAQ

Wat is e-mailbeveiligingsachterstand? E-mailbeveiligingsachterstand is de opgebouwde achterstand aan onopgeloste problemen op het gebied van authenticatie, eigendom en configuratie in de e-mailinfrastructuur van een organisatie — verouderde SPF-mechanismen, DKIM-sleutels voor niet-meer-bestaande diensten, DMARC-beleidsregels die vastzitten in de monitoringmodus, en externe afzenders waarvan niemand de verantwoordelijkheid draagt of die door niemand worden gecontroleerd.

Hoe meet je de e-mailbeveiligingsachterstand? Houd onopgeloste zaken bij in plaats van succesvolle: niet-geïdentificeerde afzenders, geautoriseerde diensten zonder eigenaar, niet-onderzochte authenticatiefouten, inactieve platforms die nog steeds mogen verzenden, en domeinen die na een afgesproken deadline nog steeds in de monitoringmodus staan. Tel daar de leeftijd van elk item bij op, want hoe lang iets al onopgelost is, maakt het verschil tussen een lopend onderzoek en echte beveiligingsachterstand.

Betekent het behalen van DMARC p=reject dat je geen e-mailbeveiligingsachterstand hebt? Nee. Handhaving op je primaire domein voorkomt directe spoofing van dat domein, maar subdomeinen, verzendservices van derden en onopgeloste authenticatiefouten kunnen allemaal onbeheerd blijven achter een schijnbaar goede hoofdstatistiek.

• Over
• Laatste berichten

Ahona Rudra

Expert op het gebied van 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)

• DMARC MSP-casestudy: hoe Presis de afleverbaarheid van e-mails voor klanten heeft verbeterd met PowerDMARC - 17 september 2026
• Hoe weet je of een e-mail nep is: waarschuwingssignalen waar je op moet letten - 14 september 2026
• Controle op oplichtingsmails: hoe weet je of een e-mail legitiem is? - 13 september 2026