Wat is DKIM en waarom is het in 2026 belangrijk?
DKIM (DomainKeys Identified Mail) is een e-mailauthenticatiestandaard gedefinieerd in RFC 6376 waarmee een verzendend domein uitgaande berichten cryptografisch kan ondertekenen. De ontvanger haalt de bijbehorende public key uit DNS, herberekent de handtekening en bevestigt dat het bericht door de domeinbeheerder is geautoriseerd en onderweg niet is gewijzigd. Zonder DKIM kan een spoofer je From:-adres vervalsen, je afzenderreputatie schaden en stilletjes antwoorden omleiden naar lookalike-domeinen — een probleem dat de meeste teams pas opmerken nadat de deliverability instort.
In 2026 is DKIM niet langer optioneel. De bulkverzenderregels van Gmail en Yahoo — gehandhaafd vanaf februari 2024 en aangescherpt door 2025 — vereisen dat elk domein dat meer dan 5.000 berichten per dag verstuurt geldige SPF, DKIM en DMARC publiceert. Microsoft 365 kondigde gelijkwaardige handhaving aan voor afzenders met hoog volume. Falende DKIM verlaagt niet langer alleen je inboxratio; het triggert harde rejects, dmarc=fail-rapporten en in veel gevallen verwijdering van de allow-list van de ontvanger. Wekelijks DKIM valideren is de goedkoopste deliverability-verzekering die je kunt kopen.
Hoe DKIM werkt — public/private-key cryptografie
DKIM is gebouwd op standaard asymmetrische cryptografie. Wanneer je DKIM opzet, genereert je mailplatform een RSA-sleutelpaar: een private key die op de verzendende server blijft en een public key die je publiceert in DNS. Elk uitgaand bericht wordt gehasht (body + geselecteerde headers), de hash wordt versleuteld met de private key, en het resultaat wordt als DKIM-Signature-header toegevoegd. De ontvanger haalt je public key op uit DNS, decodeert de handtekening, herberekent de hash uit het bericht dat hij ontving, en vergelijkt de twee. Matchen ze, dan slaagt DKIM; matchen ze niet, dan is de handtekening gebroken en wordt het bericht als verdacht behandeld.
De DKIM-Signature-header bevat de metadata die ontvangers nodig hebben om te verifiëren: v= (versie), a= (algoritme, normaal rsa-sha256), d= (signing domain), s= (selector), c= (canonicalisatie, normaal relaxed/relaxed), h= (ondertekende headers), bh= (body hash) en b= (de handtekening). Samen vertellen ze de ontvanger precies welk DNS-record op te halen en welke bytes zijn afgedekt.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KX5vRn3...truncated...Wat is een DKIM-selector?
Een DKIM-selector is een korte label waarmee één enkel domein meerdere DKIM-sleutels tegelijkertijd kan publiceren. Ontvangers vinden de public key door selector en signing domain te combineren tot een DNS-naam in de vorm selector._domainkey.domain.com. Bijvoorbeeld: Google Workspace gebruikt google._domainkey.example.com, terwijl een door Mailgun ondertekend bericht zoekt naar k1._domainkey.example.com. Selectors zijn cruciaal omdat je hiermee sleutels kunt rouleren, verschillende verzendplatforms parallel kunt draaien (transactioneel, marketing, sales) en nieuwe sleutels gefaseerd kunt invoeren voordat je oude opruimt — allemaal zonder dat twee records ooit botsen. Er is geen wildcard of fallback op _domainkey.domain.com zelf; de selector is verplicht.
Example DNS record format:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."5 veelvoorkomende DKIM-fouten en hoe je ze oplost
DNS-lookup geeft niets terug
De ontvanger heeft selector._domainkey.jouwdomein.com gequeried en kreeg NXDOMAIN. Dit is de meest voorkomende DKIM-failure. Oorzaken: het TXT-record is nooit gepubliceerd, het is gepubliceerd onder de verkeerde selector, of het is toegevoegd aan de apex (jouwdomein.com) in plaats van aan het selectorsubdomein. Los het op door de exacte naam te publiceren die je provider gaf (bijv. google._domainkey) als TXT-record en verifieer propagatie met dig TXT selector._domainkey.jouwdomein.com of door deze checker opnieuw te draaien. Sta tot 48 uur toe voor wereldwijde propagatie.
Public key ongeldig
DNS geeft een record terug maar de p=-waarde is misvormd, afgekapt of geweigerd door de ontvanger. De meest voorkomende oorzaak is een 2048-bits sleutel die over meerdere TXT-strings is gesplitst en onjuist is samengevoegd — veel DNS-UI's voegen ongewenste aanhalingstekens, spaties of regeleinden toe. Los het op door de public key exact te kopiëren zoals je mailplatform hem exporteerde, te plakken als één enkele TXT-waarde (de meeste providers splitsen automatisch op de 255-byte-grens), en te bevestigen dat het record v=DKIM1; k=rsa; p=BASE64KEY bevat zonder witruimte binnen het base64-blok.
Body hash mismatch
DKIM tekende bh=ABC maar de ontvanger berekende bh=XYZ uit de body die hij ontving, dus verificatie faalt. Dit betekent dat iets het bericht na ondertekening heeft aangepast. Veelvoorkomende oorzaken: een downstream gateway (anti-virus, DLP, mailinglijst) herschrijft links of voegt een footer toe, een SMTP-relay re-encodeert regeleinden, of een forwarder strijkt bijlagen. Los het op door te tekenen met relaxed/relaxed-canonicalisatie (tolereert witruimteveranderingen), de herschrijvende middleware te verwijderen, of — voor mailinglijsten — ARC te implementeren zodat de oorspronkelijke DKIM bewaard blijft over hops.
Handtekeningverificatie mislukt
De body hash matchte maar de cryptografische handtekening verifieerde niet tegen de public key. Oorzaken: de ondertekenende server gebruikte een private key die niet langer matcht met de gepubliceerde public key (gebeurt vaak na een sleutelrotatie waarbij DNS is bijgewerkt maar de cache van de mailserver niet), de public key in DNS is bewerkt en beschadigd, of het signing-algoritme in a= matcht niet met het sleuteltype. Los het op door de public key opnieuw te exporteren vanaf het verzendende platform, hem letterlijk te herpubliceren en de mailservice te herstarten zodat hij zijn private key opnieuw inlaadt.
Selector niet gevonden / verkeerd
Je mailserver tekent met selector s1, maar DNS publiceert alleen s2, of je bent gemigreerd van provider en de oude selector is uitgefaseerd. Los het op door de s=-tag te checken in de DKIM-Signature-header van een echte uitgaande e-mail (de meeste clients laten je full headers bekijken), te bevestigen dat een TXT-record bestaat op exact die selector, en eventuele verlopen selectors zonder bijbehorende private key te verwijderen — oude selectors met lege p=-waarden veroorzaken hard fails.
Stapsgewijze DKIM-setup
- 1
Kies een sleutellengte (1024 vs 2048 bit)
Kies in 2026 altijd 2048-bits RSA. 1024-bits sleutels worden door de meeste ontvangers nog geaccepteerd, maar Gmail, Yahoo en Microsoft markeren ze nu actief als zwak in DMARC-rapporten, en security-teams falen routinematig audits die 1024-bits DKIM in productie aantreffen. De enige reden om naar 1024 te gaan is een legacy DNS-provider die geen TXT-record langer dan 255 bytes kan opslaan — en zelfs daarvan ondersteunen vrijwel alle providers tegenwoordig multi-string-TXT-splitting. 2048-bits sleutels voegen ongeveer twee milliseconden toe aan de signing-tijd, wat verwaarloosbaar is voor elke productie-mailserver.
- 2
Genereer het sleutelpaar
De meeste platforms genereren sleutels voor je — Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark en Amazon SES bieden allemaal een one-click DKIM-setup-pagina die beide helften produceert en je de te publiceren public key toont. Draai je je eigen server (Postfix + OpenDKIM, Exim, of Haraka), gebruik dan opendkim-genkey -b 2048 -d jouwdomein.com -s s1, dat schrijft s1.private (geheimhouden) en s1.txt (publiceren). Hergebruik nooit een sleutel over domeinen of platforms.
- 3
Voeg de public key toe als TXT-record
Maak een TXT-record op selector._domainkey.jouwdomein.com — bijvoorbeeld s1._domainkey.example.com — met de waarde v=DKIM1; k=rsa; p=MIIBIjANBgkq... geplakt uit het .txt-bestand dat je generator produceerde. Veel DNS-providers splitsen de waarde automatisch in 255-byte-stukken; dat is prima, ontvangers voegen ze weer samen. Zet TTL op 3600 seconden tijdens het testen en verhoog naar 86400 zodra het record stabiel is. Neem de omringende aanhalingstekens uit de generatoroutput niet op als deel van de waarde.
- 4
Configureer je e-mailservice om met de private key te tekenen
Op gehoste platforms is dit automatisch zodra je het DNS-record publiceert en op Verify klikt. Op self-hosted servers verwijs je je milter (OpenDKIM, Rspamd) naar het .private-bestand, stel je de selector in op de match met het DNS-record, en herstart je het mailproces. Stuur een testbericht naar een Gmail-adres en bekijk de raw source — je zou een Authentication-Results: dkim=pass header.d=jouwdomein.com-header moeten zien. Zie je dkim=none, dan tekent de server nog niet; zie je dkim=fail, dan matchen de sleutels niet.
- 5
Test met een gratis DKIM-checker
Gebruik deze DKIM Checker om DNS-publicatie te bevestigen, stuur dan een echt testbericht naar mail-tester.com of een Gmail-account dat je beheert en inspecteer de headers. Verwacht: Authentication-Results toont dkim=pass en de selector matcht je gepubliceerde record. Test opnieuw na elke sleutelrotatie, elk nieuw verzendplatform, en minimaal eens per kwartaal. Voeg de check toe aan je monitoringtool zodat een stille DKIM-failure niet wekenlang je deliverability kan saboteren.
Veelvoorkomende DKIM-selectors per provider
Verschillende e-mailplatforms kiezen elk hun eigen selector-conventie. Die conventie kennen maakt troubleshooten een stuk sneller — krijg je een bericht van Google Workspace en is DKIM gebroken, dan weet je al om google._domainkey op te zoeken voordat je vijftig alternatieven scant. Hieronder de selectors die de grote providers in 2026 gebruiken:
Google Workspace — google._domainkey.jouwdomein.comMailgun — k1._domainkey.jouwdomein.com (soms mta._domainkey)SendGrid — s1._domainkey.jouwdomein.com en s2._domainkey.jouwdomein.com (CNAME-gebaseerd)Mailchimp — k1._domainkey.jouwdomein.com en k2._domainkey.jouwdomein.comMicrosoft 365 — selector1._domainkey.jouwdomein.com en selector2._domainkey.jouwdomein.comPostmark — pm._domainkey.jouwdomein.com (of 20XXXXXXX.pm._domainkey)Amazon SES — custom random selectors zoals abc123._domainkey.jouwdomein.com (CNAME-gebaseerd)Mandrill (van Mailchimp) — mandrill._domainkey.jouwdomein.comConstant Contact — ctct1._domainkey.jouwdomein.com en ctct2._domainkey.jouwdomein.comConvertKit — ck._domainkey.jouwdomein.comMailjet — mailjet._domainkey.jouwdomein.comBrevo (voorheen Sendinblue) — mail._domainkey.jouwdomein.com
De DKIM Checker van Nova Uptime scant automatisch alle bovenstaande selectors plus 38 meer parallel, dus je hoeft niet vooraf te weten welke je provider gebruikt.
Gmail- en Yahoo-vereisten in 2026
Sinds februari 2024 handhaven Gmail en Yahoo strengere authenticatie op elk domein dat meer dan 5.000 berichten per dag naar hun gebruikers verstuurt. De regels: elk bericht moet ondertekend zijn met een geldig DKIM-record (2048-bits aanbevolen), SPF moet uitlijnen met het From:-domein, en er moet een DMARC-policy gepubliceerd zijn — minimaal p=none — met een bereikbaar rua=-rapportageadres. Door 2025 en in 2026 hebben beide providers de volumegrens verlaagd en zijn ze begonnen berichten direct te weigeren (5.7.26) in plaats van naar spam te routen. Microsoft 365 begon in mei 2025 met gelijkwaardige handhaving. Het praktische effect: één gebroken DKIM-record veroorzaakt nu harde bounces in plaats van alleen inboxplaatsingsproblemen, en herstel duurt dagen omdat DMARC-rapporten 24 uur vertraging hebben. Continue monitoring is niet langer optioneel.