Praktische handleiding voor AI-aanvragen voor phishing-maildetectie: 2026 Bedrijven selecteren en implementeren een volledige analyse
Van SPF/DKIM/DMARC tot grote modellen ter beschrijving van betekenis, een diepe uiteenzetting over hoe AI-aangedreven anti-phishing-motoren tot uiting mogen komen in de werkelijke dreigingsomgeving
Daniel Nikulshyn
Editor
Bedreigingsuitzicht
Waarom phishing nog steeds de grootste aanvalstraject is in 2026
Hoewel de mailveiligheidssector al jaren ontwikkeld is, is phishing nog steeds de hoofdbestandsmunitie waar bedrijven mee te maken hebben. De afgelopen jarenpubliceerde Verizon in zijn Data Breach Investigation Report, waaruit bleek dat sociale ingenieurskunst in combinatie met wachtwoordkraking constant een hoge plek in de jaarlijkse lijst van datalekken inneemt en email de meest voorkomende manier is waarop deze aanvallen worden toegevoegd. Volgens Wikipedia is de basis van phishing het imiteren van een vertrouwde entiteit en het manipuleren van de slachtoffers in ruil voor wachtwoorden, geldovermakingen of het installeren van malware. Sinds 2022 is er sprake van een duidelijke daling in de kosten waarmee generatieve AI's worden geproduceerd, waardoor het maken van phishingcontent een stuk minder duur is geworden. Het door de jaren heen gebruiken van regels gebaseerd op typfouten en slecht geschreven taal om phishingmails te detecteren wordt steeds minder effectief. Door gebruik te maken van een groottaalmodel kunnen tekst en taal worden geproduceerd met perfecte grammatica zodat ze aansluiten bij de cultuur van het bedrijf, met zelfs de optie om een geavanceerde phishingaanval uit te voeren door gebruik te maken van de publieke sofinformatie van de doelgroep, ook wel bekend als spear phishing, en zakelijke emailtrucs (Business Email Compromise). BEC is een gevaarlijke vorm van phishing, vooral omdat de FBI's Internet Crime Complaint Center (IC3) al jaren BEC als het meest schadelijke type cybercrimetipe in hun jaarlijkse rapporten heeft genoemd vanwege de economische schade. Deze aanvallen houden in dat ze geen enkele malware of bovenvermeldde koppelingen bevatten en dat het afhankelijk is van de psychologische manipulatie van medewerkers om geld over te maken, waardoor traditionele detectie van basistaal en linken niet meer effectief is. Door de opkomst van dit type aanvallen zijn de AI-gedachte geavanceerde detectie-agents naar voren gebracht en maken de focus niet langer alleen op links en bijlagen, maar op het analyseren van intenties, relaties en taalstructuren die niet normaal zijn. Dit is de technische kern die in dit gids zal worden besproken.
- Phishing - Wikipedia — Wikipedia over de basis, verschillende type en geschiedenis van phishingaanvallen
- FBI IC3 jaarverslagen — Jaarlijkse rapporten van de FBI's Internet Crime Complaint Center over het aantal schadelijke BEC en ander types cybercrimetipes met behulp van vertrouwelijke informatie
Technische basis
De authenticatieovereenkomst is de grondlaag, maar het eindstation niet
Elke serieuze beveiligingsoplossing tegen phishing start op drie grote e-mailauthenticatieovereenkomsten: SPF, DKIM en DMARC. SPF (Sender Policy Framework) bepaalt middels een DNS-record welke servers de bevoegdheid hebben om naamloze bestanden namens een domein te verzenden; DKIM (DomainKeys Identified Mail) verifieert met behulp van een cryptografische handtekening of een e-mail tijdens de overgang niet is gewijzigd; DMARC (Domain-based Message Authentication, Reporting and Conformance) geeft voor de andere twee een verdeling van de strategie voor behandeling bij falen (geen, isoleren, weigeren) en biedt bovendien een rapporteringssysteem. De Wikipedia-aflevering over DMARC legt vermelding van de sleutel bijdrage van DMARC: 'align' - het is erop gericht dat de domeinen met SPF/DKIM worden gevalideerd aan de hand van het adres waarin de gebruiker ziet in de From-kop, waardoor domeinvervalsingen kunnen worden voorkomen. Google en Yahoo stelden al sinds 2024 een verplichte DMARC-vereiste voor op een groot aantal uitstaande verzenders. Dit bedrijfskundige stap zorgde voor een aanzienlijke verkleining van de ruimte waarin directe domeinvervalsingen zijn mogelijk. Maar deze overeenkomsten kunnen alleen de vraag oplossen over wie het recht heeft om gebruik te maken van een domeinnaam. Zij bieden geen oplossing voor twee categorieën aanvallers die extreem schadelijk zijn: 1. de aanvallers die geregistreerd zijn voor een domein met een domein dat op het doelde domein een aanzienlijke overeenkomst heeft (zoals bijvoorbeeld 'rn' voor 'm') en dat mogelijk wel via DMARC kan worden gevalideerd; 2. aanvallers die een willekeurige partij overreden met een legaal postbuspost, waardoor de overige validerende stappen kunnen doorlopen. Dit is het moment waarop AI-detectiemodellen een rol spelen. Deze verwerken resultaten uit authenticatieprotocollen als enkele kenmerken van een meer complete set aan kenmerken, en niet zozeer als de enige criteria om te beoordelen. Ze voegen er aan toe een portret van de afzender, een semantische analyse van de betrokken intentie en een netwerk van relaties om het gebrek aan authenticatie te overlappen. Begrijpen van deze onderverdeling, is nodig om te voorkomen dat je wordt misleid door zinnen als 'wij ondersteunen DMARC'.
- DMARC - Wikipedia — Werking, overeenstemmingsmechanismen en strategieën van DMARC
- DKIM - Wikipedia — Technische details over de cryptografische handtekening van DKIM
Enginering
De kerntechnologie van AI-slechte-email detectie agents
Moderne AI-slechte-email detectie agents bestaan typisch uit vier capaciteitenlagen. De eerste laag is de klassieke bevestigende detectie: URL-schapenbibliotheek, attachment sandbox explosie, attachment hash match - deze technologie is volwassen, voornamelijk de geïntimeerde bedreigingen. De tweede laag is statistische en machine learning-functie engineering, met het afhalen van honderden signalen, zoals de registratiedatum van het verzendings domein, het eerste contact vlag, het niet-machtige antwoordadres en verzendingsadres, verborgen Unicode-omdat-kenmerken. De derde laag is een recent belangrijke doorbraak: natuurlijke taal verwerking en de grote taalmodelbesturing van semantisch intentie analyse. Het systeem vraagt niet langer alleen 'is dit link veilig?', maar 'wat doet deze e-mail proberen?' Het herkent dus oproepings druk ('complete de overmaking in 30 minuten') autoriteit imitatie (als voor CEO), en ongebruikelijke conversatie structuur. OpenAI, Anthropic e.d. de grote fabrikanten van modellen API's zorgen ervoor dat deze semantische analyse precisie sterk ophoud en ook de kosten, vertraging en geheimheid van de nieuwe afwegen. De vierde laag is gerelateerde grafiekkaarten en gedrags baseline. De agent analyseert door middel van historische communicatiebrieven die een gebruiker binnenshuis en buitenshuis ziet, om elke verzender een 'normale gedragenskaart' te creëren: meestal in welk tijdsbestek hij e-mail stuurt, wat voor apparaten gebruik maakt, met wie hij correspondeert en wat zijn gebruikelijke woordenschatten zijn als hij er afwijkt (bijv een CFO plotseling van een onbekende IP in de nacht vraagt om een overmaking) de systeme geeft de e-mail een hoog risicum score. Deze afwijkingsdetectiemethode is zodat het is vooral effectief tegen nul-daag BEC aanvallen, omdat het niet afhankelijk is van enige al gekende signatuur. Ondernemingen en experts dienen de volgende vragen te stellen aan leveranciers: 'Heeft semantische analyse een set regels of een echte modelredenering?' Hoe lang duurt de leren periode van de gedragsbaseline? Hoe geef je een foutmelding terug in een model? De antwoorden op deze vragen, zeggen veel meer over product's werkelijke niveau dan 'We hebben AI gebruikt'.
- Platformdocumentatie van OpenAI — Officiële documentatie van de grote model API's voor semantische intentieverwerkingsdoeleinden
- Wikipedia artikel over anti-phishing software — Geautomatiseerde techniekcategorieën en detectiemethodes voor anti-phishing software
Systeembeleidskeuzes
Hoge beschermingsniveau tegen email-fisheing vs API-level: twee implementatiearchitecturen vergelijken
Bij de selectie van een beveiligingsoplossing speelt het fundamentale architectuurverschil een cruciale rol. De vraag is waar het detectiepunt zich bevindt. Traditionele beveiligde email-gateways (SEG, Secure Email Gateway) worden geïmplementeerd op het entree-punt van de email-stream. Hierbij wordt de MX-records geüpdatet om alle binnenkomende emails eerst naar de detectieservice te leiden voordat zij worden gedistribueerd naar het email-abonnement. Deze manier verhindert totale opvang, is niet afhankelijk van de API van het email-platform en kan echter niet de veranderingen observeren van al gedistributeerde emails (zoals uitgestelde link-activatie), en het is ook lastig om internale laterale email-fisheing te analyseren. Recentelijk zijn API-level-integraties opgedoken (vaak aangeduid als ICES, Integrated Cloud Email Security). Dit type beveiliging leest de email rechtstreeks door via de Microsoft Graph of Google Workspace API en voert in- en post-scanning uit na de email-verstuurprocedure. Deze methode heeft het voordeel dat zij snel implementeerbaar zijn, geen aanpassing van MX-records vereisen en inzicht geven in de email-vluchten van het interne netwerk. Tevens ondersteunen de automatische terugtrekking van verdachte emails (claw-back) ook. Microsoft's Defender for Office 365 en de integrale veiligheid van Google Workspace behoren tot deze categorie. Deze twee implementatiearchitecturen zijn niet wederzijds uitsluitend. Veel ontwikkelde organisaties implementeren een 'gateway voor grove selectie plus API niveaubesmetting' voor een meerwaarde in dieper verdediging. Professionals dienen in het geval van de beslissingsbevoegdheid te wegen: gateways hebben meer onder controle in verband met vertraagde situaties, maar vereisen meer onderhoud, terwijl API niveau implementaties lichter van toepassing zijn, maar sterk inzicht geven en beperkt zijn door de snelheid en verificaties van de platform APIs, en in bepaalde gevallen betekent het automatisch terugtrekken van verdachte emails dat ze tijdelijk aanwezig waren in de postvakken van de gebruikers. Een vaak over het hoofd geziene evaluatie-aspect is betreffende data-rust en persoonlijke gegevens. API-level implementaties dienen toestemming te verlenen voor de autorisatie van derden om volledige e-mail-inhoud te lezen, wat voor organisaties onder het beheersgebied van de GDPR of sectorgebonden regelgeving een beslissingspunt is van groot belang. Het is noodzakelijk om het data proces van de leverancier te bevestigen, de bewaartermijn en of de e-mail-inhoud zal worden ingezet voor de opleiding van de alledaagse model.
- Microsoft Defender for Office 365 — Officiële documentatie om veiligheid tegen bedreigingen voor email te beheren door Microsoft
- Email filtering - Wikipedia — Technische achtergrond van filteren email en de context van veiligheid van netwerk-gateways
Optiemethode
Evaluatieframework: wat en hoe moet je meten als bedrijf
Op de markt wordt bijna elk leverancier van zeggen dat ze een detectiescore hebben van 99% of hoger. Maar dit cijfer is volledig vrijblijvend wanneer men dit alleen op de testset meet. Ik zou adviseren aan de beveiligingsteams om een evaluatieraamwerk op te zetten dat bestaat uit vier kwadranten: Detectie-effectiviteit, Foutmelding-blootstelling, Beheerbare ervaring en totale aankoopkosten. Op het vlak van effectiviteit van detectie is het niet belangrijk om slechts in algemene zin over de accurateitscijfers te spreken. Het gaat erom dat men per type afzonderlijk de opgeroepen herinneringen meet: voor mailen met schadelijke links, voor attachments met schadelijke software, voor tekstuele Bedrijfs-eigenaren-cheatin (BEC), voor binnendringende phishing-aanvallen en de terugroepcijfers. Een van de meest gemakkelijk onderschatte kosten is de foutmeldingen. Een slecht ontwerp van een filter dat maar 0,1% foutmeldingen produceert, kan resulteren in het isoleren van 1.000 schadeloze e-mails per dag bij een bedrijf dat miljoenen e-mails verwerkt. Hieruit vloeit direct SOC-dysfunctie in het verschiet en een erosie van het vertrouwen van de gebruikers in de systeem. Onderzoek de configuratie van het systeem in detail: de strategische configuraties, de integratiegraad met SIEM/SOAR en eventuele event-investigaties. De kostenmodellen (per gebruiker, post of licentie) verbergen vaak de echte TCO op de lange termijn. Geef de beslissingstafel in de hand door de TCO in kaart te brengen zodat de onverwachte kosten later niet onaangename verrassingen opleveren.
- Precisie en terugroepen — Inzicht in de precisie en terugroepen van de analyse
Spelletjes-theorie
Tegenstrijdige realiteit: wanneer de attacker ook de AI heeft
Phishingdetectie is een spelletje dat voortdurend wordt gespeeld. Attackers proberen inmiddels om door middel van een tegen-middel te ontwijken: het insturen van een verborgen 'aanleerstimulatie' (prompt-injectie) in een mail, om de LLM-techniek van de analyse motor te dwingen; gebruik van afbeeldingen die in zich de tekst bevatten die niet wordt gesnuffeld; of het gebruik van legitieme cloud diensten om de schadelijke inhoud te verslepen totdat alleen in verschillende stappen de schadelijke inhoud aan de oppervlakte komt. Volgens de Wikipedia-artikelen over tegen-middelen bij AI (adversarial machine learning) is elke AI die een analysemotor heeft gevoelig voor tegen-middelen. Daarom is het de moeite waard om een integratie van meerdere motoren te hebben die samen de uitkomst bereiken, met als eis dat elke motor niet zelf de einduitspraak mag doen. Bovendien moet het zo zijn dat elke motor geen enkel signaal als een feit accepteert zonder dat eerst een andere motor de resultaten overeenkomt. Er bestaat ook een verwaarloosde realiteit die wordt verwaarloosd in de product ontwikkeling: detectie-vermoeidheid. Omdat de eindgebruiker telkens een risico-overzicht krijgt, neemt hij uiteindelijk gewoon de afstand: hij neemt de veiligheid van de producten voor een klap uit het vizier. Daarom zou men, als het product is opgeleverd, eerder en sneller de hooggeachte e-mails met een ernstige dreiging in beeld brengen om zo met een krachtige ingreep in te grijpen, en voor de lichtere gevallen, een kleinere indicatie te zetten in het vizier. Dit laat de beperkte capaciteit van de aankomende gebruiker bestendig en gericht gebruiken en helpt zo het systeem ook efficiënter te maken. De AI-tech heeft nooit de mens af moeten nemen. Het is van vitaal belang te combineren met een regelmatige simulatie van phishing en met de beveiliging van de medewerker. Het AI-product mag dus niet worden beschouwd als 'een systeem dat alle phishing detecteert', maar eerder als 'een systeem dat het aantal gevaarlijke e-mail- en postberichten vermindert en dat in staat is om een contextueel oordeel te geven', want deze realistische kijk houdt een veiligheid met verantwoordelijkheid bij de mens die de verantwoordelijkheid ook daadwerkelijk draagt.
- Tegen-middelen bij AI — Waarom AI tegen-middelen voor detectie systemen een gevaar vormen
- Anthropic - veiligheidsresearch — Over stimuleren en de veiligheid van de model-techniek
Implementatiegids
Implementatieroadmap:90-daags implementatieplan
Op basis van meerdere implementaties raad ik aan om het inzetten van een AI-fishdetectieproxy te splitsen in drie 30-daagse fasen. De eerste 30 dagen is het basissetter en het gelijktijdig testen: zorg ervoor dat de bestaande e-mailstroom ongewijzigd blijft, schakel het nieuwe systeem aan in shadow mode, en verzamel scores voor werkelijke e-mailberichten. Vervolgens vergelijk de resultaten met de huidige situatie, en meten de opgedane vooruitgang en de foutmeldingen. Tegelijkertijd voltooien de checks voor SPF/DKIM/DMARC om te garanderen dat de basis veilig en stevig is. Veel organisaties ontdekken aan het einde van deze fase dat ze geen DMARC hebben geïmplementeerd. De tweede 30 dagen is de zachte landingsmanoeuvre en het aanpassen van strategieën. Kies een deel van de organisatie waarbij de risico's zijn beperkt (vaak de financiële afdeling of de assistenten bij de topmanagers, die vaak het risico op BEC-aanvallen hebben) en draai de automatische beveiliging aan. Volg nauwgezet de foutmeldingen en bouw een snelle release-route aan. De centrale aflevering van de tweede fase is een stapel van organisatie-matched strategie-basis en upgrade-routine, waarbij je duidelijk maakt wat voor soort alarmen automatisch verwerkt zullen worden en wat voor soort door mens ingestelde alarmeringen nodig hebben. De derde 30 dagen is de volledige verspreiding en de vorming van operationele routine. Zorg ervoor dat de detectie-agent met je SIEM/SOAR-systeem is aangesloten. Implementeer een automatisch intrekken, automatisch isoleren en automatisch koppeling van het registratieproces. Richt nu tevens de reguliere klachtendwang in rond de foute beveiligingen. Zorg ervoor dat de door de model fouten gemaakte e-mails snel in het model terug kunnen worden gezet. Tegelijkertijd start je een eerste simuleringsronde voor het opsporen van phishing-aanvallen. Hierdoor kun je de echte schutshulp effectief toetsen. Zorg ervoor dat je een terugrollen-strategie voorhanden hebt. Als je van de API of het model afhankelijk bent, kan het altijd onverwachts afwijken, zoals bij een probleem met de leverancier, een model-update of limieten. Het is altijd een gooiworp hoe lang. Het kiezen van een fallback-strategie (bijvoorbeeld automatisch terugdraaien naar de zekerheidsregels) voorkomt het ene incident om een volledige storing in de organisatie te worden. Zet die strategie vast in een contract. Dat is voor de leverancier de laatste linie in de verdediging van jouw rechten.
- Security information and event management - Wikipedia — SIEM/SOAR met e-maildetectiesysteem aanband
Bronnen
- Phishing - Wikipedia
Definitie, soorten en evolutie van phishing-attacks
- DMARC - Wikipedia
Het protocol voor het e-mailauthenticatie en beveiliging
- Microsoft Defender voor Office 365 documentatie
Dit is de officiële documentatie voor de e-mail-beschermingsproducten van Microsoft
- OpenAI-platform documentatie
De officiele documentatie voor de OpenAI-API’s die worden gebruikt voor de betekenis en de intentie
- Anthropic onderzoekswebsite
Onderzoekswebsite van Anthropic die het model-infiltratie en modelverzekering in vraag stelt
Veelgestelde vragen
Kan een AI-fishing-detectieagent de gebruikelijke veiligheid emailgateway compleet vervangen?
Dit kan niet altijd vervangen, maar het is een aanvulling. API-gebaseerd AI-detector werkt beter bij BEC en lateraalmailing, maar er zijn nog steeds waarde in de gateway, zoals het filteren en de vertraging controleren met inkomende email
Zijn er bij de implementatie van de API-gebaseerde oplossing risico's die samenhangen met de verplichting om alle post te lezen voor de gegevensbeschermingswet?
De hoofdpunten zijn de bewaring en bewaring van de gegevens, de periode waarin hij wordt gebruikt en of deze wordt gebruikt voor modeltraining. Organisaties die onderworpen zijn aan de GDPR of geografische verdelingen moeten bevestigen dat de locatie van de bewaring is, een DAA-contract ondertekenen en de e-mailinhoud onderschrijven dat deze wordt gebruikt voor training op een gemeenschappelijke model.
Waarom kunnen er nog steeds phishing-mails bestaan als er DMARC is ingesteld?
DMARC kan niet voorkomen dat domein naam-vervalsingen worden uitgevoerd, noch kan het voorkomen dat ze ongevalen zijn door het omvallen van echte partner adressen, die beiden erkend wordt. Daarom is het nodig om AI-ter beschrijving van betekenis en gedrag te analyseren.
Is een 99% phishing detectie cijfer van de leverancier te vertrouwen?
Het cijfer is niet van waarde op basis van het testset alleen, de type recall cijfer is nuttiger, voeg hiertoe historische test samples toe voor regressie test en ten slotte voer minstens 30 dagen parallel test uit.
Zullen er dan operatieve lasten opgewekt worden?
Dit is gemakkelijk te overschatten. De misleide rate van 0,1% betekent 1000 misleide post per miljoen post, wat 1000 misleide post per dag betekent die zijn uitgelegerd, wat zal de SOC verlammen en de gebruikers vertrouwen inbrengt. Gebruikers worden geattendeerd, test misleide post van de leverancier en de snelheid van de reactie.
Kan een bestaande email op basis van de gedrags- en grafiek-analyse nog gestopt worden voor het genereren van de phishing-email?
De syntaxis en spellingscontrole is onbetrouwbaar, maar baseren van abnormale detectie aan de hand van gedragsnormen en relatiegrafiek werkt wel. Dit heeft tot doel te vermijden dat de oplossing wordt geïnfiltreerd door schendende tegen-metingen.
Zijn er speciale ICES schermen nodig voor het kiezen van een AI-gebaseerd scherm?
Heb je al een Microsoft 365 of Google Workspace account, dan kan je eerst het native beveiligingsonderdeel gebruiken en zet dan DMARC in de actieve status. Wanneer een hoog frequent BEC-geval of wanneer er een wettelijke verplichting is, beoordeel dan het gebruik van ICES-scherm, lichtere ICES-producten zijn op basis van het aantal postbokjes gefinsierd.
Hoe lang duurt het om dit type systeem te implementeren?
De implementatie van het scherm is technisch in enkele minuten of dagen om te implementeren, maar de volledige implementatie is geadviseerd in drie fasen van 30 dagen per fase: 30 dagen parallelle implementatie, 30 dagen afstemming met de verkeerde meldingen, 30 dagen volledige implementatie met operationele integratie om de misleide meldingen te verlagen en de omzetting risico’s.
