De IETF DKIM-werkgroep heeft op 17 mei 2026 een nieuwe versie van de DKIM2-specificatie gepubliceerd. Dit is de derde herziening van het document van de werkgroep, waarmee gestaag wordt voortgegaan op weg naar een definitieve RFC. Voor iedereen die DKIM2 al sinds de eerste conceptversies volgt, is dit het duidelijkste teken tot nu toe dat de werkgroep bijna klaar is met een versie die daadwerkelijk in gebruik kan worden genomen.
Heb je eerst wat achtergrondinformatie nodig voordat je verder leest? Bekijk dan onze uitgebreide uitleg over 'Wat is DKIM2?' voor meer achtergrondinformatie.
Wat is er veranderd in deze update?
De nieuwe versie heet draft-ietf-dkim-dkim2-spec-02. Het is geschreven door Richard Clayton (Yahoo), Wei Chuang (Google) en Bron Gondwana (Fastmail), hetzelfde team dat vanaf het begin aan het document heeft gewerkt. Het eerste officiële concept van de IETF-werkgroep was draft-ietf-dkim-dkim2-spec-00, gepubliceerd op 24 maart 2026, dat het eerdere individuele concept (draft-clayton-dkim2-spec) verving. Sindsdien heeft het document herzieningen ondergaan: -01 in april en -02 in mei, waarbij de specificatie werd vormgegeven door de bredere werkgroep in plaats van alleen door de oorspronkelijke auteurs.
De herziening van 17 mei is een incrementele update waarmee de technische details van de specificatie verder worden verfijnd. De belangrijkste wijzigingen zijn:
- Authentication-Results-headers die niet worden ondertekend: deze headers veranderen vaak wanneer e-mail systemen passeert, dus door ze niet in de handtekening op te nemen, worden onnodige verificatiefouten voorkomen.
- Duidelijkere regels voor de vlaggen `donotmodify` en `donotexplode`: afzenders kunnen nu duidelijker aangeven dat een bericht niet mag worden gewijzigd of naar meerdere ontvangers mag worden verzonden, en verificateurs beschikken nu over expliciete controles en foutmeldingen wanneer deze verzoeken worden genegeerd.
- Het z-body-recept is verwijderd: hoewel dit oorspronkelijk was opgenomen voor afgebroken bounceberichten, bleek het in de praktijk niet nodig te zijn. Door het te schrappen wordt de specificatie vereenvoudigd zonder dat er functionaliteit verloren gaat.
- Strengere technische regels: verduidelijkingen over Base64-opvulling, scheidingstekens met puntkomma’s in headervelden en JSON-opmaak verminderen onduidelijkheden en maken het eenvoudiger om compatibele implementaties te bouwen.
Lezers die de specificatie op de voet volgen, kunnen de verschillende versies rechtstreeks vergelijken via de IETF Datatracker.
De twee problemen die DKIM2 oplost

Deze herziening kwam tot stand vanwege twee al lang bestaande problemen met DKIM1.
De eerste is de DKIM-replay-aanval. Hierbij neemt een aanvaller een legitiem ondertekend bericht en verstuurt dit opnieuw naar andere mailboxen, waarbij hij misbruik maakt van de goede reputatie van het oorspronkelijke domein. DKIM2 lost dit op door de gegevens van de ontvanger op te nemen in de ondertekende inhoud en een bewakingsketen op te bouwen voor elke stap die het bericht doorloopt. Herhaalde berichten zien er voor een verificateur niet langer echt uit.
Ten tweede zijn er de beschadigde handtekeningen tijdens het doorsturen. Mailinglijsten en doorstuurprogramma’s wijzigen vaak de headers of de inhoud van het bericht op een manier die de oorspronkelijke DKIM-handtekening ongeldig maakt. Daarom slagen berichten die via tools als Mailman worden verzonden, vaak niet voor de DMARC-controles voor het domein van de afzender. DKIM2 lost dit probleem standaard op. Elk systeem dat het bericht verwerkt, registreert de aangebrachte wijzigingen en voegt zijn eigen handtekening toe aan de keten. Controleurs kunnen het bericht vervolgens terugvolgen naar de oorspronkelijke afzender zonder dat de keten wordt onderbroken.
Voor meer informatie over het doorstuurprobleem verwijzen wij u naar ons artikel over DMARC en mailinglijsten.
ARC wordt stopgezet
De oplossing voor het doorsturen bevat ook uitleg over een gerelateerde update die de moeite waard is om te weten. Op 22 april 2026 hebben Trent Adams (Proofpoint) en John Levine (Taughannock Networks) het volgende ingediend draft-ietf-dmarc-arc-to-historic-00 in bij de IETF DMARC-werkgroep. Hierin wordt voorgesteld om Authenticated Received Chain (ARC) te herclassificeren als een historische standaard.
De reden die in het ontwerp wordt genoemd voor het beëindigen van het ARC-experiment, is dat de operationele ervaring die met ARC is opgedaan, wordt verwerkt in het voorgestelde DKIM2-project, dat bedoeld is als opvolger van DKIM. Met andere woorden: de lessen die uit ARC zijn getrokken, gaan niet verloren. Ze worden verwerkt in een strakkere oplossing.
Als je meer wilt weten over ARC en wat het precies doet, kun je onze gids 'Wat is ARC?' doornemen.
Wat domeineigenaren nu moeten doen

Voor de meeste afzenders is het antwoord: niets dringends.
DKIM2-sleutels maken gebruik van dezelfde DNS-recordstructuur als de huidige DKIM-sleutels, waardoor uw bestaande DNS-configuratie gewoon blijft gelden. De specificatie gaat ervan uit dat DKIM1 en DKIM2 nog geruime tijd naast elkaar zullen bestaan, dus er is geen verplichte overstap. De eerste implementaties bij grote e-mailproviders worden eind 2026 verwacht, waarna de bredere uitrol zich zal voortzetten tot in 2027 en daarna.
Het is nu van belang dat je ervoor zorgt dat je huidige DKIM-configuratie in orde is. Dat betekent dat sleutels correct moeten zijn gepubliceerd, dat er een verstandige rotatie moet zijn en dat er geen overgebleven selectors mogen zijn. Eventuele problemen die je nu hebt, zullen je ook in het DKIM2-tijdperk blijven achtervolgen. Als je de basisbeginselen nog eens wilt doornemen, begin dan met het artikel ‘Wat is DKIM?’.
Als u liever niet zelf de ondertekeningssleutels wilt beheren wanneer de overgang van start gaat, zorgt de gehoste DKIM-dienst van PowerDMARC voor de publicatie, vernieuwing en monitoring, zodat u helemaal klaar bent wanneer DKIM2 wordt uitgerold.


