Wat is DKIM kwetsbaarheid? DKIM l= tag beperking uitgelegd

De DKIM l= tag (kleine letter "L") in DKIM is een optionele tag die de lengte van de berichttekst specificeert die moet worden ondertekend. Dit kan worden beschouwd als een DKIM kwetsbaarheid omdat de l= tag gedeeltelijke ondertekening van de berichttekst mogelijk maakt. Dit kan het voor bedreigingsactoren gemakkelijker maken om DKIM-ondertekende berichten te misbruiken. 

Laten we eens kijken hoe DKIM werkt en waarom we het gebruik van de DKIM l= tag in uw DKIM handtekening niet aanmoedigen.

Het doel van DKIM Body Length Limitations (l= tag)

DKIM (DomainKeys Identified Mail) is een e-mailverificatieprotocol dat ervoor zorgt dat de inhoud van uw e-mails tijdens het verzenden niet is gewijzigd. Het stelt de ontvanger in staat om te controleren of een e-mail inderdaad is verzonden en geautoriseerd door de eigenaar van dat domein.

Wanneer tussenliggende servers uw berichten doorsturen, kunnen ze de body van het bericht wijzigen. Ze kunnen extra informatie toevoegen in de voettekst of aan de inhoud van uw bericht. De DKIM l tag is geïntroduceerd om te voorkomen dat uw legitieme berichten niet voldoen aan DKIM, in het geval dat de inhoud is gewijzigd tijdens het doorsturen of door mailinglijsten. 

Hoe de DKIM l= tag werkt

1. Lengte opgeven: De l= wordt gevolgd door een geheel getal dat het aantal bytes in de berichttekst aangeeft dat wordt gedekt door de DKIM handtekening.
2. Gedeeltelijke ondertekening van het lichaam: Door een lengte op te geven worden alleen de eerste 'n' bytes van de body opgenomen in de hash die gebruikt wordt om de DKIM handtekening te genereren. Aanpassingen aan de body voorbij deze lengte hebben geen invloed op de verificatie van de DKIM handtekening.

Voorbeeld: DKIM-handtekening met de l-Tag DKIM kwetsbaarheid

Neem een e-mail waar de body 1000 bytes lang is, maar alleen de eerste 500 bytes zijn ondertekend:

DKIM-handtekening: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notify.domain.com; s=selector1; t=1718098168; [email protected]; l=500; bh=SF9K/AZh8dO2XDYZlOtjrmHj5txv4H4qjhFr+q3ASuM=; h=Subject:Message-ID:To:Date:Content-Type:From:To:Cc:Subject; b=h0Jp5xjZSjUo06er2Gm5k0Fvt0cuC0xOnfobu1oYAFT2ugVxY0h/xly6x/E/pPT2S

In dit voorbeeld is de l=500 aan dat alleen de eerste 500 bytes van de e-mailtekst worden opgenomen in de DKIM-handtekening.

De in Europa gevestigde toonaangevende domeinregistrar, Zone.eu's team van analisten een ernstige kwetsbaarheid ontdekt die is gekoppeld aan de l-tag in de DKIM-handtekening. De l-tag heeft niet alleen voordelen bij het doorsturen van e-mails, maar kan ook eenvoudig worden misbruikt door cybercriminelen om phishing-e-mails te versturen die toch door de DKIM-controles komen.

DKIM-kwetsbaarheid vereenvoudigen met PowerDMARC!

DKIM l= Tag Kwetsbaarheid

We raden het gebruik van de DKIM l= tag af, omdat dit uw beveiligingspositie kan verzwakken, waardoor uw domein kwetsbaar wordt voor aanvallen, zelfs als de e-mailverificatie is geconfigureerd. 

Een aanvaller kan de inhoud van uw berichttekst wijzigen en kwaadaardige bestanden of links toevoegen in het niet-ondertekende gedeelte van de e-mail dat buiten het bytebereik valt dat is gedefinieerd in uw "l"-tag. Wanneer deze e-mail uw ontvanger bereikt, zal deze de DKIM-verificatie doorstaan. Als u DMARC hebt ingeschakeld voor uw domein, zal deze vervolgens ook worden goedgekeurd. 

Je ontvanger opent deze e-mail mogelijk, vertrouwt op je domeinnaam en wordt het slachtoffer van nog een phishingaanval! Dit kan leiden tot een ernstige schending van de privacy, diefstal van gegevens en verlies van vertrouwen in uw geloofwaardigheid. Als uw klant hierdoor geld verliest, kunt u zelfs aansprakelijk worden gesteld voor financiële compensatie. 

De rol van BIMI in het verergeren van deze DKIM-kwetsbaarheid 

BIMI is een opkomend protocol dat aan populariteit wint in zowel de beveiligings- als de marketingindustrie vanwege de mogelijkheid om merklogo's toe te voegen aan e-mails. Nog niet zo lang geleden hebben grote e-mailproviders zoals Gmail en Apple Mail hun ondersteuning voor BIMI uitgebreid om je e-mails er professioneel uit te laten zien en de beveiliging te verbeteren door visuele verificaties. 

Aangezien vervalste berichten die zijn verzonden vanaf domeinen die de DKIM l-tag in hun handtekening gebruiken, door de DKIM- en DMARC-controles komen, wordt het BIMI-logo van het merk ook aan deze schadelijke e-mails gekoppeld! Nu passeert dit valse bericht dat vanaf uw domeinnaam is verzonden niet alleen alle verificatiefilters, maar is er ook uw merklogo aan gekoppeld! Dit vergroot de kans dat ontvangers de geloofwaardigheid ervan vertrouwen. 

Vanwege dit potentieel uitbuitende karakter van de DKIM l= tag heeft Gmail in hun Google Admin Workspace Helpcentrum het gebruik ervan sterk afgeraden. Dit is wat Google erover te zeggen heeft:

"Als je DKIM instelt met een ander e-mailsysteem dan Google Workspace, gebruik dan niet de DKIM-lengtetag (l=) in uitgaande berichten. Berichten die deze tag gebruiken zijn kwetsbaar voor misbruik."

De risico's van de DKIM l-tag worden verder toegelicht in RFC 6376 paragraaf 8.2 getiteld "Misbruik van Body Length Limieten ("l=" Tag)". De RFC waarschuwt gebruikers dat het specificeren van de l tag in uw DKIM handtekening ertoe kan leiden dat gebruikers zonder waarschuwing toegang krijgen tot schadelijke e-mailinhoud. De RFC dringt er bij DKIM ondertekenaars op aan om extra voorzichtig te zijn met de aanwezigheid van deze tag en adviseert servers om DKIM handtekeningen met een l= tag volledig te negeren.

Controleer uw DKIM-handtekening op l-Tag DKIM kwetsbaarheden 

Het is essentieel om eerst te bepalen of je domein kwetsbaar is. Hiervoor hebben we hieronder een aantal methoden opgesomd die je kunt gebruiken: 

Handmatige methode: Originele DKIM Handtekening Headers controleren 

1. Stuur een lege e-mail naar jezelf (in dit geval nemen we het voorbeeld van een Gmail-gebruiker)

2. Open deze e-mail.

3. Ga naar "meer opties", aangeduid met drie stippen in de rechterbovenhoek.

4. Klik op "Origineel weergeven".

5. Scroll op de pagina Oorspronkelijk bericht naar beneden om de onbewerkte headers te zien. 

6. Navigeer naar het gedeelte "DKIM-handtekening:" en analyseer de syntaxis. Als je ziet dat de DKIM l= tag aanwezig is in de DKIM signature header, is je domein kwetsbaar. Als deze ontbreekt, zit u goed en hoeft u geen actie te ondernemen. 

Geautomatiseerde methode: Een hulpprogramma voor het analyseren van e-mailheaders gebruiken

1. Meld je aan op PowerDMARC voor een gratis proefversie. 2. Ga naar Analysehulpmiddelen > MailAuth Analyzer. 

2. Kopieer het automatisch gegenereerde e-mailadres en plak het als ontvanger van een nieuwe testmail in je Gmail. Verzend de testmail. 

3. Ga nu terug naar de portal en vernieuw de pagina. Klik op het pictogram "bekijken" in het gedeelte Acties om je resultaten te bekijken. 

4. We analyseren onmiddellijk de e-mailheader om een samengevoegd rapport te produceren met informatie over je DKIM-, SPF- en DMARC-configuraties en nog veel meer! 

5. Je kunt naar beneden scrollen om de DKIM signature header in raw en parsed formaat te bekijken. Hier kun je bepalen of je handtekening een l= tag bevat. Als deze aanwezig is, moet er actie worden ondernomen om deze kwetsbaarheid te verhelpen. 

Voorbeeld: Een DKIM-handtekening zonder de l-Tag DKIM Kwetsbaarheid

DKIM-handtekening: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notify.domain.com; s=selector1; t=1718098168; [email protected]; bh=SF9K/AZh8dO2XDYZlOtjrmHj5txv4H4qjhFr+q3ASuM=; h=Subject:Message-ID:To:Date:Content-Type:From:To:Cc:Subject; b=h0Jp5xjZSjUo06er2Gm5k0Fvt0cuC0xOnfobu1oYAFT2ugVxY0h/xly6x/E/pPT2S

DKIM kwetsbaarheden voorkomen: Wat zijn DKIM best practices?

Als je het DKIM-protocol optimaal wilt benutten, zijn hier enkele tips die onze experts aanbevelen: 

1. Vermijd het gebruik van de DKIM l= tag in uw DKIM signature header. 
2. Neem contact op met je e-mailprovider om nieuwe DKIM publieke sleutels (zonder de l= tag) aan je DNS toe te voegen. 
3. Roteer uw DKIM-sleutels regelmatig om ervoor te zorgen dat oude sleutels met de l-tag kwetsbaarheid kunnen worden vervangen door nieuwe sleutels zonder deze kwetsbaarheid. 
4. U kunt sterke DKIM-sleutels gebruiken, zoals 2048-bits sleutels in plaats van 1024-bits, om de sterkte van uw DKIM e-mailbeveiliging te verbeteren. 
5. Gebruik een gehoste DKIM Gebruik een gehoste DKIM-oplossing om uw DKIM-selectors en -sleutels te beheren en uw DKIM-verificatieresultaten te controleren vanuit één centraal dashboard.
6. Maak uw DKIM-sleutels met een automatische DKIM generator tool. Zo voorkomt u syntaxfouten die u gemakkelijk over het hoofd kunt zien.

Aanvullende protocollen voor gebruik met DKIM

Om de effectiviteit van DKIM te vergroten, kun je de volgende protocollen implementeren (samen met een bonusaanbeveling aan het einde!): 

1. Gebruik ARC (Authenticated Received Chain) om ervoor te zorgen dat legitieme e-mails door de verificatiecontroles komen, zelfs als ze worden doorgestuurd of als ze mailinglijsten gebruiken. Hierdoor wordt de DKIM l= tag automatisch overbodig. ARC bewaart automatisch de originele headers van je bericht om valse negatieven te voorkomen.
2. Configureer fallback-mechanismen zoals SPF en DMARC om je authenticatienauwkeurigheid en algemene beveiliging te verhogen. 
3. inschakelen DMARC-rapporten om je e-mailkanalen en verzendbronnen bij te houden. DMARC-rapporten kunnen je helpen schadelijke IP-adressen en afzenders te detecteren, zodat je snel actie tegen ze kunt ondernemen.

Door deze best practices toe te passen, kunnen organisaties hun e-mailbeveiliging aanzienlijk verbeteren en hun domeinreputatie beschermen. Hoewel de l= tag flexibiliteit kan bieden bij het afhandelen van e-mails die tijdens het transport kunnen worden gewijzigd, kan het de beveiliging van uw domein verzwakken. Daarom raden wij, samen met verschillende e-mailproviders, industrie-experts en organisaties, deze tag af. Om meer te weten te komen over domeinbeveiliging en e-mailverificatieservices, neem contact met ons op vandaag nog!

• Over
• Laatste berichten

Ahona Rudra

Expert 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)

• IP-reputatie versus domeinreputatie: waarmee kom je in de inbox terecht? - 1 april 2026
• Verzekeringsfraude begint in de inbox: hoe vervalste e-mails routinematige verzekeringsprocessen veranderen in diefstal van uitkeringen - 25 maart 2026
• FTC Safeguards Rule: Heeft uw financiële instelling DMARC nodig? - 23 maart 2026