# Wat is DKIM? Het e-mailauthenticatieprotocol uitgelegd URL: https://notificationharbor.com/nl/journal/wat-is-dkim Type: blog Locale: nl Published: 2026-09-08 Updated: 2026-09-09 --- > DKIM voegt een cryptografische RSA-handtekening toe aan elke uitgaande e-mail. De ontvangende MTA verifieert die via de publieke sleutel in DNS voordat hij beslist waar het bericht terechtkomt. DKIM (DomainKeys Identified Mail) is een cryptografisch e-mailauthenticatieprotocol. Wat is DKIM in de praktijk: het koppelt een RSA-handtekening aan elk uitgaand bericht dat je mailserver verstuurt. De ontvangende MTA haalt je publieke sleutel op uit DNS, verifieert die handtekening en rapporteert het resultaat als `dkim=pass` of `dkim=fail`. Dat resultaat voedt het reputatiemodel van je domein en bepaalt of DMARC-uitlijning standhoudt. Zonder geldige handtekening heeft de ontvangende MTA geen cryptografische bevestiging dat het bericht afkomstig is van jouw infrastructuur. ## DKIM is een ondertekeningsprotocol, geen filter De naam wekt een veelvoorkomend misverstand. DKIM blokkeert geen e-mail. Het plaatst berichten niet in quarantaine en handhaaft op zichzelf geen beleid. Wat het doet is elk uitgaand bericht voorzien van een verifieerbare claim: dit bericht is ondertekend door het domein in het veld `d=`, met de private sleutel die overeenkomt met selector `s=`. De ontvangende MTA neemt die claim, bouwt een DNS-query naar `._domainkey.`, haalt het TXT-record met de publieke sleutel op en voert de cryptografische verificatie uit. Als de verificatie slaagt, toont de authentication-results-header `dkim=pass`. Als die mislukt, zie je `dkim=fail` of `dkim=temperror`. Geen van beide uitkomsten leidt op zichzelf tot afwijzing. Het signaal voedt het reputatiemodel van de ontvangende server en, cruciaal, de DMARC-evaluatie. De taak van DKIM is een verifieerbaar resultaat produceren, niet ernaar handelen. ## Wat DKIM ondertekent en wat de handtekening dekt DKIM ondertekent twee dingen: geselecteerde berichtkoppen en de berichttekst. Het ondertekeningsalgoritme hasht beide en slaat het resultaat op in het kopveld `DKIM-Signature`. De koptekstlijst wordt bepaald door de tag `h=` in de handtekening. Een typische productieconfiguratie bevat `from:subject:date:message-id:content-type`. De koptekst `from` is de relevante voor DMARC-uitlijning. De body-hash dekt de volledige berichttekst, gecanonicaliseerd via `simple` of `relaxed`. Relaxed-canonicalisatie is wat de meeste productiestacks gebruiken. Het normaliseert witruimte voor het hashen, waardoor de handtekening kleine hervormattingen door relay-MTA's kan overleven. Simple is strenger: een enkele wijziging in afsluitende witruimte breekt de handtekening. In het veld `DKIM-Signature` van vrijwel elke goed geconfigureerde ESP zie je `c=relaxed/relaxed`. Wat DKIM niet ondertekent: de SMTP-envelopafzender, routeringskopteksten zoals `Received` en elke koptekst buiten de `h=`-lijst. Dit is bewust. Het ondertekenen van de envelop zou doorstuurscenarios breken, wat precies het voordeel van DKIM boven SPF is. ![Twee digitale enveloppen beveiligd met hangslot die DKIM-ondertekende e-mails in doorvoer weergeven](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/95ba5d-img-2.webp) ## De selector: een toegangsbeheermechanisme dat teams behandelen als label De selector is het deel van DKIM dat de meeste teams onderschatten totdat ze sleutels onder druk moeten roteren. Het veld `s=` in je DKIM-Signature wijst naar een specifieke publieke sleutel in DNS. Het opzoekformaat is `._domainkey.`. Als je selector `mail2026` is en je domein `example.com`, zoekt de resolver naar een TXT-record op `mail2026._domainkey.example.com`. Een enkel domein kan meerdere actieve selectors tegelijk hebben. Elke verzendservice, elke ESP, elke interne MTA moet zijn eigen selector gebruiken. Dit biedt drie concrete operationele mogelijkheden: - Onafhankelijke sleutelrotatie per service zonder andere verzenders te raken. - Traceerbare attributie in authenticatielogboeken: de selector vertelt welke ondertekeningssleutel voor een bepaald bericht is gebruikt. - Schoon offboarden: verwijder het DNS-record van de selector en die ESP kan je domein niet langer ondertekenen, ongeacht wat ze aan hun kant doen. Wat de traces in de praktijk laten zien: teams die een gedeelde selector configureren over alle verzendservices kunnen de toegang voor een enkele afzender niet intrekken zonder alle andere te verstoren. De selector is niet cosmetisch. Het is een toegangsbeheermechanisme. ![Terminal met DNS TXT-records voor DKIM-selectorconfiguratie](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/02b314-img-3.webp) ## DKIM en DMARC-uitlijning: hoe de handhavingslaag werkt DKIM doorgeven is een vereiste voor een specifiek type DMARC-pass genaamd DKIM-uitlijning. DMARC vereist minimaal een van twee uitlijningsvoorwaarden: SPF-uitlijning of DKIM-uitlijning. DKIM-uitlijning betekent dat het domein in de `From:`-header overeenkomt met de `d=`-waarde in de DKIM-handtekening, en de handtekening verifieert. Als beide voorwaarden gelden, beschouwt DMARC het bericht als geauthenticeerd. Dit is waarom DKIM het duurzamere authenticatiesignaal is. SPF-uitlijning breekt bij doorsturen: wanneer een bericht wordt doorgestuurd, verandert de SMTP-envelopafzender en mislukt SPF-evaluatie tegen het nieuwe verzend-IP. DKIM-uitlijning overleeft doorsturen omdat de handtekening en de `From:`-header meereizen met de berichttekst en niet worden herschreven door relay-MTA's, zolang de berichttekst onderweg niet wordt gewijzigd. Voor domeinen met een DMARC-beleid `p=reject` wordt een bericht dat zowel SPF- als DKIM-uitlijning mislukt, afgewezen door de ontvangende MTA. Dat is het mechanisme dat vervalste e-mail van jouw domein op schaal tegenhoudt. DKIM is hier niet de laatste verdedigingslinie. Maar het is de linie die standhoudt wanneer doorsturen in het pad zit. Sinds 2024 vereisen Google, Yahoo en Microsoft DKIM voor bulkverzenders die 5.000 of meer berichten per dag naar hun MX sturen. Berichten van niet-ondertekende domeinen worden standaard naar spam gerouteerd of afgewezen. Dit is geen marketingfunctie. Het is een infrastructuurvereiste. ## Sleutellengte en rotatie: praktische beslissingen voor 2026 De meeste DKIM-implementaties gebruiken RSA-SHA256. De kernvraag is de sleutellengte. RSA-sleutels van 1024 bits komen nog steeds voor in legacy-configuraties. NIST schafte 1024-bits RSA af voor de meeste gebruikssituaties in 2015. Een sleutel van 2048 bits biedt aanzienlijk meer veiligheidsmarge en wordt ondersteund door elke grote MTA en ontvangend provider. Als je vandaag een nieuwe sleutel genereert, gebruik dan 2048 bits. Sommige teams hebben hun actieve ondertekeningssleutel gemigreerd naar 2048 bits, maar lieten oude selectors van 1024 bits gepubliceerd in DNS achter omdat niemand de inventaris heeft geauditeerd. Drie signalen die het gedrag van het systeem veranderen: als je `k=rsa` ziet met een 1024-bits sleutel in een oude selector, is die selector een kwetsbaarheid, ook als je huidige ondertekeningsinfrastructuur al is overgegaan. Een geldige maar afgeschreven selector is exploiteerbaar. Rotatieschema voor sleutels: de meeste infrastructuurteams roteren jaarlijks, sommige elk kwartaal voor gevoeligere domeinen. De volgorde is belangrijk: - Genereer een nieuw sleutelpaar. - Publiceer de nieuwe publieke sleutel onder een nieuwe selectornaam in DNS. - Wacht op TTL-propagatie, doorgaans 24 tot 48 uur voor records met een lage TTL. - Schakel de ondertekeningssleutel in je MTA-configuratie over naar de nieuwe selector. - Verifieer DKIM pass op uitgaande berichten via een mail-testtool of door de authentication-results-headers te inspecteren op een testbericht. - Verwijder na bevestiging dat de nieuwe sleutel actief is en correct ondertekent het oude DNS-record. De rotatie is niet-verstorend als je de volgorde volgt: eerst DNS, dan omschakeling van ondertekening, verwijdering van het oude record als laatste. Stappen 4 en 6 omkeren veroorzaakt een `dkim=fail`-venster. ## Operationele signalen om te monitoren na DKIM-configuratie DKIM is geen eenmalige configuratietaak. De volgende signalen geven aan dat er iets is veranderd of kapotgegaan. **`dkim=temperror` in ontvangen headers.** Tijdelijke fouten duiden doorgaans op DNS-opzoekproblemen aan de ontvangende kant, of een TTL-mismatch tijdens sleutelrotatie. Als je dit ziet op uitgaande berichten kort na een sleutelrotatie, wacht dan op volledige propagatie voordat je concludeert dat de sleutel zelf verkeerd is geconfigureerd. **`dkim=fail` op berichten die je hebt verstuurd.** Aanpassing van de berichttekst door een tussenliggende relay is de meest voorkomende oorzaak. Controleer of er een doorsturhop, een mailinglistprocessor of een voettekstinjecterende relay in het bezorgpad zit. Als de fout consistent is bij een enkele flow, breng dan de relay-keten hop voor hop in kaart. **Ontbrekende `DKIM-Signature`-header.** De ondertekeningsdaemon op je MTA draait niet, het pad naar de ondertekeningssleutel is onjuist, of de domein-selectortoewijzing is verkeerd geconfigureerd in je MTA-configuratie. Dit is een volledige DKIM-uitval voor de betreffende berichtflows. **Selector TXT-record ontbreekt in DNS.** De DNS-zone is bewerkt of gemigreerd zonder het DKIM-selectorrow te bewaren. Verifieer met `dig TXT ._domainkey.` via een externe resolver. Bij een meervoudige regionale verzendconfiguratie worden inconsistente DKIM-resultaten over nodes heen vaak veroorzaakt doordat verschillende nodes verschillende selectorconfiguraties gebruiken. Bevestig dat de ondertekeningssleutelconfiguratie gesynchroniseerd is over alle verzendnodes voordat je een rotatie uitrolt. ## Waartegen DKIM niet beschermt DKIM is geen spamfilter. Een afzender kan een nieuw domein registreren, geldig DKIM configureren en volledig geauthenticeerde spam versturen. De handtekening verifieert probleemloos. Authenticatie bevestigt herkomst, niet intentie of contentkwaliteit. DKIM behandelt ook geen spoofing van weergavenamen, waarbij de `From:`-header een vertrouwde naam toont zoals "Salarisadministratie" gekoppeld aan een domein dat door de aanvaller wordt beheerd. De cryptografische verificatie werkt op het domein, niet op de visuele presentatie in de MUA. De meeste phishing op MUA-niveau maakt gebruik van misleiding van weergavenamen in plaats van exacte domeinspoofing. Waartegen DKIM wel beschermt: exacte domeinspoofing, waarbij een aanvaller probeert te verzenden als jouw domein zonder jouw private sleutel te bezitten. In combinatie met een DMARC-beleid `p=reject` dat DKIM-uitlijning afdwingt, voorkomt dit dat die klasse van vervalste berichten inboxen bereikt bij ontvangende providers die DMARC handhaven. Een praktische noot: DKIM alleen is niet voldoende. Het beschermingsmodel vereist DMARC-beleidshandhaving bij de ontvangende MTA. DKIM is de authenticatielaag die DMARC betekenisvol maakt. SPF is de andere authenticatielaag en verwerkt envelopafzenderverificatie. Alle drie werken samen. De afwezigheid van een van hen laat een gat in de handhavingsketen. Als je DKIM en SPF al hebt geconfigureerd maar nog geen DMARC-record hebt gepubliceerd, bestaan de handtekeningen maar is geen handhavingsbeleid actief. Monitoringmodus (`p=none` met `rua`-rapportage) is een redelijke eerste stap: je ontvangt geaggregeerde rapporten met authenticatiepasspercentages over je verzenddomein voordat je je vastlegt op `p=quarantine` of `p=reject`. Ook belangrijk: de authenticatieresultaten worden opgenomen in de e-mailheader van elk ontvangen bericht. Systeembeheerders en deliverability-engineers kunnen deze headers inspecteren om te begrijpen waarom een bericht slaagde of mislukte bij DKIM-verificatie. Dit is de eerste stap bij het debuggen van authenticatieproblemen. ## FAQ ### Wat is DKIM en hoe werkt het? DKIM (DomainKeys Identified Mail) is een cryptografisch e-mailauthenticatieprotocol. Je verzendserver ondertekent elk uitgaand bericht met een RSA private sleutel en voegt de handtekening toe aan een DKIM-Signature-header. De ontvangende MTA bevraagt je DNS voor de overeenkomende publieke sleutel onder het selectorsubdomein, verifieert de handtekening en rapporteert dkim=pass of dkim=fail. Dat resultaat voedt de reputatiescoring van de inbox en de evaluatie van DMARC-uitlijning. ### Waartegen beschermt DKIM? DKIM beschermt tegen exacte domeinspoofing: een aanvaller die beweert te verzenden vanuit jouw domein zonder toegang tot je private ondertekeningssleutel. In combinatie met een DMARC-beleid p=reject en DKIM-uitlijning voorkomt het die klasse van vervalste berichten inboxen te bereiken. Het biedt geen bescherming tegen spoofing van weergavenamen, spam van legitiem geauthenticeerde domeinen of contentgebaseerde phishing waarbij de aanvaller zijn eigen geldige domein beheert. ### Wat is een DKIM-selector en waarom is die belangrijk? Een DKIM-selector is een label in de DKIM-Signature-header (het s=-veld) dat de ontvangende MTA vertelt welke publieke sleutel in DNS op te zoeken. Het DNS-queryformaat is selector._domainkey.jouwdomein.com. Meerdere selectors kunnen naast elkaar bestaan op een enkel domein, elk verwijzend naar een andere publieke sleutel. Dit maakt onafhankelijke sleutelrotatie per verzendservice mogelijk en maakt intrekken eenvoudig: verwijder het DNS-record van de selector en die afzender kan je domein niet langer ondertekenen. ### Hoe vaak moeten DKIM-sleutels worden geroteerd? De meeste productieteams roteren DKIM-sleutels jaarlijks. De veilige volgorde is: publiceer de nieuwe publieke sleutel onder een nieuwe selector in DNS, wacht op TTL-propagatie (24 tot 48 uur), schakel de ondertekeningssleutel op je MTA over naar de nieuwe selector, verifieer dkim=pass op uitgaande testberichten en verwijder dan het oude DNS-record. Het oude record verwijderen voordat de nieuwe sleutel bevestigd actief is, veroorzaakt een dkim=fail-venster. ### Overleeft DKIM het doorsturen van e-mail? Ja, in tegenstelling tot SPF. Wanneer een bericht wordt doorgestuurd, verandert de SMTP-envelopafzender en mislukt SPF-uitlijning tegen het nieuwe verzend-IP. DKIM-uitlijning overleeft doorsturen omdat de handtekening meereist met de berichtheaders en -tekst en niet wordt herschreven door relay-MTA's, zolang de berichttekst onderweg niet wordt gewijzigd. Dit maakt DKIM het betrouwbaardere authenticatiesignaal voor DMARC-beleidshandhaving bij doorgestuurde mail. ### Welke DKIM-sleutellengte te gebruiken in 2026? Gebruik RSA-sleutels van 2048 bits. NIST schafte 1024-bits RSA af voor de meeste gebruikssituaties in 2015, en 1024-bits sleutels vormen een berekenbaar risico bij de huidige computerkosten. Alle grote MTA's en ontvangende providers ondersteunen 2048-bits sleutels. Als je nog legacy-selectors van 1024 bits in DNS hebt gepubliceerd, auditeer die dan: een geldige maar afgeschreven selector is een beveiligingsrisico, ook als je huidige ondertekeningsinfrastructuur al is overgegaan op langere sleutels. ### Wat is het verschil tussen DKIM, SPF en DMARC? SPF authenticeert het SMTP-envelopafzenderdomein door te controleren of het verzendende IP is vermeld in de DNS van dat domein als geautoriseerd. DKIM authenticeert het bericht zelf via een cryptografische handtekening op headers en tekst. DMARC gebruikt de SPF- en DKIM-uitlijningsresultaten om een domeineigenaarbeleid af te dwingen: none, quarantine of reject. SPF mislukt bij doorsturen; DKIM overleeft dat doorgaans. DMARC vereist dat minstens een uitlijning slaagt voordat het zijn beleid toepast.