Wat is DKIM (DomainKeys Identified Mail)?

DKIM (DomainKeys Identified Mail) is een authenticatieprotocol voor e-mail waarmee ontvangende servers kunnen controleren of een bericht daadwerkelijk is verzonden door het domein waarvan het beweert afkomstig te zijn, en of de inhoud tijdens het verzenden niet is gewijzigd. Dit werkt door aan elke uitgaande e-mail een cryptografische handtekening toe te voegen, die de ontvangende server vergelijkt met een openbare sleutel die in de DNS van uw domein is gepubliceerd. 

In deze handleiding wordt uitgelegd hoe een DKIM-record eruitziet, hoe het ondertekenings- en verificatieproces stap voor stap verloopt, hoe je een daadwerkelijke DKIM-Signature-header kunt interpreteren en hoe je de meest voorkomende fouten kunt oplossen.

Wat is een DKIM-record?

Een DKIM-record is een reeks instructies die als TXT-record in de DNS van uw domein wordt gepubliceerd. Het bevat de openbare sleutel die hoort bij de privésleutel die uw e-mailserver gebruikt om uitgaande e-mail te ondertekenen. Wanneer een ontvangende server een handtekening wil controleren, zoekt hij dit record op, haalt de openbare sleutel op en gebruikt deze om te bevestigen dat het bericht niet is gewijzigd en daadwerkelijk afkomstig is van uw domein.

DKIM is in 2004 ontstaan uit een samensmelting van DomainKeys van Yahoo en Identified Internet Mail van Cisco, en is sindsdien uitgegroeid tot een van de meest gebruikte standaarden voor e-mailverificatie.

DKIM-recordformaat en naamgevingsconventie

Een DKIM-record wordt niet op je hoofddomein gepubliceerd. Het bevindt zich op een specifiek subdomein dat is opgebouwd uit een selector en het vaste label _domainkey. De naamgevingsconventie is:

[selector]._domainkey.[domain]

Een record met de selector „google” voor yourdomain.com zou dus worden gepubliceerd op:

google._domainkey.yourdomain.com

De waarde van dat TXT-record ziet er als volgt uit:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Elke tag heeft een specifieke functie:

Je kunt een geldig record genereren met onze DKIM-generator en controleren of deze correct is gepubliceerd met onze DKIM-checker .

Wat is een DKIM-selector?

Een DKIM-selector is een unieke identificatiecode die de ontvangende server aangeeft welk sleutelpaar is gebruikt om een bepaald bericht te ondertekenen. Het is de alfanumerieke tekenreeks die is gedefinieerd in de s=-tag van de DKIM-Signature-header, en hiermee kan een domein meerdere sleutels tegelijk beheren (bijvoorbeeld één selector voor je e-mailplatform en een andere voor een marketingservice). Elke leverancier via wie je berichten verstuurt, moet zijn eigen, herkenbare selector gebruiken.

Google Workspace gebruikt bijvoorbeeld ‘google’ als standaardselector, dus de volledige DNS-opzoeking voor een door Google ondertekend bericht zou google._domainkey.yourdomain.com zijn. Als de naam van je record s1._domainkey.yourdomain.com zou zijn, dan is s1 je selector.

Lees meer over selectors en hoe je ze kunt vinden in onze uitgebreide DKIM-selector gids. 

DKIM-record versus DKIM-handtekening: wat is het verschil?

Deze twee termen worden voortdurend door elkaar gehaald, dus het is de moeite waard om dit duidelijk te verduidelijken. Het DKIM-record is de statische TXT-vermelding in je DNS die de openbare sleutel bevat; je publiceert deze één keer en daarna blijft hij daar staan. De DKIM-handtekening is de DKIM-Signature-header die aan elke afzonderlijke e-mail wordt toegevoegd op het moment dat deze wordt verzonden, en die wordt gegenereerd met je privésleutel. Het ene is een vaste DNS-vermelding; het andere wordt voor elk bericht opnieuw aangemaakt. Het record is wat de handtekening verifieert. Verderop zullen we de handtekeningheader veld voor veld nader toelichten.

Meer informatie over dit laatste vind je in onze uitgebreide gids over DKIM-handtekeningen. 

Hoe werkt DKIM?

DKIM-authenticatie verloopt in vier stappen, vanaf het genereren van de sleutels tot en met de uiteindelijke beslissing over slagen of mislukken aan de ontvangende kant.

Stap 1: Genereren van een sleutelpaar

Uw e-mailprovider of uzelf genereert een cryptografisch sleutelpaar: een privésleutel die geheim blijft op de verzendende mailserver, en een openbare sleutel die via DNS wordt gepubliceerd als het hierboven beschreven DKIM-record. De twee zijn wiskundig aan elkaar gekoppeld, dus alles wat met de privésleutel is ondertekend, kan alleen worden geverifieerd met de bijbehorende openbare sleutel.

Stap 2: De uitgaande e-mail ondertekenen

Wanneer je een bericht verstuurt, gebruikt de verzendende server (de Mail Transfer Agent) de privésleutel om een hash te berekenen van bepaalde delen van de e-mail (de headers die in de h=-tag van de handtekening worden vermeld, plus de berichttekst) en voegt het resultaat toe als een DKIM-Signature-header aan het uitgaande bericht.

Stap 3: DNS-opzoeking door de ontvangende server

De ontvangende server leest de DKIM-Signature-header, haalt daaruit de selector (s=) en het ondertekenende domein (d=) en vraagt via DNS de openbare sleutel op bij [selector]._domainkey.[domain], precies volgens de naamgevingsconventie die hierboven in het gedeelte over DKIM-records is beschreven. Hier komen de ondertekening per bericht en het statische DNS-record samen.

Stap 4: Controle

Met behulp van de opgehaalde openbare sleutel controleert de ontvangende server de handtekening en berekent hij zelfstandig de hash opnieuw op basis van het bericht dat hij daadwerkelijk heeft ontvangen. Vervolgens vergelijkt hij de twee. Als ze overeenkomen, is DKIM geslaagd: het bericht is intact en geautoriseerd door het ondertekenende domein. Als ze niet overeenkomen, is DKIM mislukt en kan het bericht worden gemarkeerd, in quarantaine worden geplaatst of worden geweigerd, afhankelijk van het DMARC-beleid van het domein. 

Je kunt je eigen configuratie op elk moment controleren met onze gratis DKIM-checker, waarnaar hierboven een link staat.

De inhoud van een DKIM-Signature-header 

Zo ziet een echte DKIM-Signature-header eruit in een ontvangen e-mail:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
c=relaxed/relaxed; h=from:to:subject:date:message-id;
bh=abc123...; b=xyz789...

Elk veld bevat een deel van de informatie die de ontvanger nodig heeft om het bericht te verifiëren:

De twee velden die het eigenlijke werk doen, zijn bh (de body-hash) en b (de cryptografische handtekening). Het d=veld is het belangrijkste voor DMARC: als dit niet overeenkomt met het zichtbare ‘From’-domein, kan DKIM slagen, terwijl DMARC toch kan mislukken.

Wat betekent „canonicalisatie“? (soepel versus strikt)

De c=-tag bepaalt in hoeverre de handtekening tolerante is ten aanzien van kleine opmaakwijzigingen die tijdens de overdracht zijn aangebracht. 

Ontspannen modus (de gebruikelijke, aanbevolen keuze) tolereert kleine verschillen in witruimte en hoofdlettergebruik, die bijna onvermijdelijk zijn wanneer e-mail via servers wordt verzonden. 

De strikte modus (ook wel ‘simple’ genoemd) vereist een byte-voor-byte-overeenkomst en mislukt bij de geringste wijziging. Dit is van belang omdat mailinglijsten en doorstuurservers vaak kleine aanpassingen aanbrengen (een toegevoegde voettekst, een herschreven regel) die de strikte kanonisering zouden doen mislukken, maar bij ‘relaxed’ wel doorgaan. De waarde ziet eruit als c=relaxed/relaxed, waarbij het eerste deel van toepassing is op headers en het tweede op de body.

Waarom is DKIM belangrijk?

Controleert de integriteit van e-mails (voorkomt manipulatie)

De handtekening is een verzegeling tegen manipulatie. Als een bericht tijdens het verzenden wordt onderschept en gewijzigd, zal de door de ontvanger herberekende hash niet overeenkomen met de ondertekende hash; de verificatie mislukt dan en de e-mail wordt geweigerd of gemarkeerd. Dit is de kerntaak van DKIM: garanderen dat de inhoud die aankomt, ook daadwerkelijk de inhoud is die is verzonden.

Beschermt de reputatie van de afzender en de afleverbaarheid

Correct ondertekende e-mails wekken vertrouwen bij e-mailproviders. Een geverifieerd verzenddomein dat consequent wordt geauthenticeerd, bouwt een sterkere reputatie op bij internetproviders, waardoor uw legitieme berichten eerder in de inbox terechtkomen dan in de spamfolder – een direct voordeel voor zowel marketing- als transactionele e-mails.

Blijft intact bij het doorsturen van e-mails (in tegenstelling tot SPF)

Dit is het allerbelangrijkste praktische verschil tussen de twee protocollen, en het is gemakkelijk over het hoofd te zien. Omdat een DKIM-handtekening wordt meegestuurd met het bericht mee, blijft deze geldig, zelfs nadat de e-mail is doorgestuurd. SPF daarentegen vergelijkt het IP-adres van de verzendende server met het SPF-record van het oorspronkelijke domein. Wanneer een bericht wordt doorgestuurd, staat het IP-adres van de doorstuurserver dus niet op die lijst en werkt SPF niet meer. Daarom is DKIM de betrouwbaardere van de twee voor het handhaven van DMARC-alignment bij doorgestuurde en indirecte e-mailstromen.

Vereist door Google, Yahoo en Microsoft voor bulkverzenders

DKIM is niet langer optioneel voor verzenders met grote verzendvolumes. Volgens de vereisten van Google en Yahoo die in februari 2024 van kracht werden, en de vergelijkbare regels van Microsoft die vanaf mei 2025 worden ingevoerd, moet elk domein dat ongeveer 5.000 of meer berichten per dag naar deze providers verstuurt, zich authenticeren met DKIM (naast SPF en DMARC), anders loopt u het risico dat uw e-mail wordt geweigerd of als spam wordt gefilterd. Zelfs onder die drempel is DKIM nu de basisvoorwaarde voor een goede afleverbaarheid.

DKIM versus SPF versus DMARC: hoe ze samenwerken

DKIM is een van de drie standaarden voor e-mailverificatie die bedoeld zijn om samen te worden gebruikt, en niet afzonderlijk. De taken zijn als volgt verdeeld:

Simpel gezegd: SPF controleert de verzendende server, DKIM controleert de integriteit van het bericht, en DMARC koppelt beide terug aan het domein dat uw ontvangers daadwerkelijk in het 'Van'-veld zien, en voegt vervolgens een beleid toe dat ontvangers vertelt wat ze moeten doen als een controle mislukt. DKIM en SPF zorgen voor de authenticatie; DMARC zorgt voor de afstemming en handhaving. U wilt ze alle drie.

Veelvoorkomende DKIM-fouten en hoe je ze kunt oplossen

Geen van de best gerangschikte pagina’s over ‘wat is DKIM’ legt uit wat er nu precies misgaat. Hieronder staan de vier meest voorkomende fouten en hoe je ze kunt oplossen. 

DKIM-handtekening niet gevonden

Wat dit betekent: Deze foutmelding geeft aan dat de ontvangende server geen DKIM-handtekening heeft gevonden. Meestal betekent dit dat DKIM niet is geconfigureerd voor de verzendservice die u hebt gebruikt, of dat het DNS-record nooit is gepubliceerd. 

Hoe dit op te lossen: schakel DKIM-ondertekening in voor elke dienst die e-mail verstuurt namens uw domein, en controleer of het record in DNS aanwezig is.

DKIM-handtekeningcontrole mislukt

Wat dit betekent: Er was een handtekening aanwezig, maar deze kon niet worden geverifieerd, wat betekent dat de hoofdtekst of de ondertekende headers na het ondertekenen zijn gewijzigd. De meest voorkomende oorzaak is dat een mailinglijst of doorstuurserver een voettekst heeft toegevoegd, het onderwerp heeft herschreven of headers heeft verwijderd. 

Hoe dit op te lossen: Ontspannen canonicalisatie vermindert dit, en ARC (Authenticated Received Chain) is specifiek bedoeld om authenticatieresultaten bij het doorsturen te behouden. ARC wordt echter binnenkort afgeschaft, en DKIM2 zal, zodra het is ingevoerd, de problemen bij het doorsturen aanzienlijk verminderen. 

Openbare sleutel niet gevonden in DNS

Wat dit betekent: De ontvanger heeft de openbare sleutel opgezocht, maar er werd niets gevonden. Dit komt meestal door een discrepantie tussen de selector of het domein in de DKIM-Signature-header en de daadwerkelijke DNS-recordnaam, een vertraging in de DNS-propagatie na een recente wijziging, of een simpele typefout in de recordnaam, meestal een ontbrekende onderstrepingsteken in _domainkey.

Hoe dit op te lossen: Controleer uw domein met een DKIM-checker om alle fouten te bekijken en deze één voor één te verhelpen. 

Sleutel te kort / zwakke sleutel

Wat dit betekent: Veel oudere e-mailplatforms en hostingpanelen genereren nog steeds standaard 1024-bits sleutels. RFC 8301 beschouwt 1024-bits als het absolute minimum, maar beveelt ten minste 2048-bits aan voor ondertekening, en NIST classificeert 1024-bits RSA als uitsluitend bestemd voor verouderd gebruik. Grote e-mailproviders zoals Google accepteren 1024-bit nog steeds als minimum, maar raden 2048-bit aan. Een 1024-bit-sleutel is tegenwoordig dus geen regelrechte mislukking; hij voldoet gewoon niet aan de huidige standaard en de veiligheidsmarge wordt steeds kleiner.

Hoe dit op te lossen: gebruik standaard een 2048-bits RSA-sleutel met rsa-sha256. Let bij het upgraden op twee dingen: een 2048-bits openbare sleutel is te lang voor één DNS TXT-string van 255 bytes, dus deze moet in hetzelfde record worden opgesplitst in meerdere strings tussen aanhalingstekens, en je moet de sleutels elke 6 tot 12 maanden vernieuwen. 

DKIM-best practices

• Gebruik 2048-bits sleutels, geen 1024-bits: Langere sleutels zijn sterker en worden steeds vaker door grote providers vereist.
• Wissel de sleutels minstens één keer per jaar: Publiceer de nieuwe sleutel in DNS voordat u de oude deactiveert, zodat er tijdens de overstap geen verificatieonderbreking ontstaat.
• Onderteken alle bronnen van uitgaande e-mail: Elke dienst van een derde partij (CRM, e-mailmarketingplatform, helpdesk) moet zijn eigen DKIM-ondertekening hebben, geconfigureerd onder zijn eigen selector.
• Houd de slagings- en mislukkingspercentages bij: Bekijk uw geaggregeerde DMARC-rapporten, zodat u een defecte selector of een niet-ondertekende afzender kunt opsporen voordat dit de afleverbaarheid negatief beïnvloedt.

Beperkingen van DKIM

DKIM is essentieel, maar op zichzelf niet voldoende. Hieronder volgen enkele reële beperkingen:

DKIM voorkomt op zichzelf geen vervalsing van het ‘Van’-adres

DKIM verifieert het domein in de `d=`-tag van de handtekening en bevestigt dat het bericht niet is gewijzigd, maar controleert niet of `d=` overeenkomt met het ‘Van’-adres dat de ontvanger te zien krijgt. Die controle op overeenstemming is de taak van DMARC. En als een aanvaller toegang krijgt tot een legitiem account of een legitieme server, kan hij een geldig ondertekende e-mail versturen.

DKIM is afhankelijk van een correcte DNS-configuratie

Een verkeerd geconfigureerd record, een vertraging bij de verspreiding of een verkeerde selector kan ervoor zorgen dat DKIM zelfs bij legitieme e-mails mislukt.

DKIM hanteert op zichzelf geen beleid

DKIM levert alleen een ‘geslaagd/mislukt’-resultaat op en geeft ontvangers geen aanwijzingen over wat ze moeten doen bij een mislukking. Door het te combineren met DMARC, dat de resultaten van DKIM (en/of SPF) gebruikt om een quarantaine- of afwijzingsbeleid toe te passen, wordt authenticatie pas echte bescherming.

Sleutelbeheer zorgt voor meer operationele complexiteit

Het beheren van sleutels voor meerdere verzenddiensten, het veilig rouleren ervan en het op één lijn houden van alle externe verzenders vereist voortdurende aandacht en regelmatige controle. Dit handmatig doen voor meerdere domeinen is niet alleen tijdrovend, maar ook een aanslag op de beschikbare middelen.

DKIM inschakelen met PowerDMARC

Met PowerDMARC kunnen domeineigenaren DKIM naast SPF en DMARC instellen, met realtime monitoring en rapportage, zodat u de authenticatieresultaten kunt volgen en fouten direct kunt opsporen zonder dat u daar handmatig iets voor hoeft te doen. 

Het platform ondersteunt meerdere domeinen en grote e-mailvolumes, en maakt gebruik van gehoste DKIM met de andere authenticatieprotocollen voor volledige bescherming tegen e-mailfraude. U kunt DKIM en DMARC binnen enkele minuten configureren, in plaats van handmatig met DNS te moeten worstelen.

Met Hosted DKIM van PowerDMARC profiteert u van:

• Eenmalige CNAME-configuratie, daarna geen DNS-wijzigingen meer: Koppel uw domein één keer en beheer vervolgens elke wijziging in selectors en sleutels vanuit één clouddashboard, in plaats van bij elke update de DNS aan te passen.
• Sleutels roteren zonder DNS-toegang: Plan en voer sleutelrotatie direct uit via het dashboard, zonder vertragingen bij de propagatie of handmatige aanpassingen aan records, zodat er geen downtime is en er geen ruimte is voor syntaxfouten.
• Volledige flexibiliteit qua sleutellengte: Kies sleutels van 1024, 2048 of 4096 bits en verhoog de sleutelsterkte zonder de authenticatie te onderbreken.
• Een speciaal DKIM Analytics-dashboard: Volg het e-mailvolume, de DKIM-slaagpercentages en de prestaties per selector in realtime voor snel inzicht en probleemoplossing.
• Beheer voor meerdere domeinen en geschikt voor MSP’s: Beheer DKIM voor honderden domeinen en subdomeinen vanuit één plek, met een multi-tenant-overzicht dat speciaal is ontwikkeld voor ondernemingen en serviceproviders.
• Een complete authenticatiestack op één platform: DKIM werkt samen met DMARC, SPF, MTA-STS en BIMI en kan worden geïntegreerd met providers zoals Google Workspace en Microsoft 365.

Veelgestelde Vragen

1. Waar staat DKIM voor?

DKIM staat voor DomainKeys Identified Mail. Het is een authenticatieprotocol voor e-mail dat gebruikmaakt van een cryptografische handtekening om te controleren of een bericht daadwerkelijk afkomstig is van het opgegeven domein en tijdens het verzenden niet is gewijzigd.

2. Wat is DKIM in eenvoudige bewoordingen?

Je kunt DKIM zien als een fraudebestendig zegel op je e-mail. Je server ondertekent elk bericht met een privésleutel, en de ontvangende server controleert dat zegel aan de hand van een openbare sleutel in je DNS. Als het zegel intact is, is de e-mail authentiek en ongewijzigd.

3. Hoe stel ik DKIM in voor mijn domein?

Om DKIM in te stellen, moet je een sleutelpaar genereren (via je e-mailprovider of onze DKIM-generator), je verzendserver zo configureren dat uitgaande e-mail met de privésleutel wordt ondertekend, en de openbare sleutel als een TXT-record publiceren op selector._domainkey.yourdomain.com. Je kunt onze volledige handleiding voor het instellen van DKIM gids voor stapsgewijze instructies.

4. Is DKIM op zichzelf voldoende?

Nee. DKIM controleert de integriteit van het bericht, maar controleert niet het zichtbare „Van”-adres en dwingt ook geen beleid af. Voor volledige bescherming tegen spoofing moet u het combineren met SPF en DMARC.

5. Wat is het verschil tussen DKIM en SPF?

SPF bepaalt welke servers e-mail mogen versturen namens uw domein (controle van het pad), terwijl DKIM controleert of de inhoud van het bericht niet is gewijzigd en door het domein is ondertekend (controle van integriteit en herkomst). DKIM-handtekeningen blijven vaak intact bij het doorsturen, terwijl SPF meestal niet meer werkt wanneer e-mail wordt doorgestuurd.

6. Hoe kan ik controleren of DKIM correct is ingesteld?

Gebruik de gratis DKIM-checker van PowerDMARC om te controleren of je DKIM-record correct is ingesteld. Voer gewoon je domein en selector in, waarna de tool de DNS raadpleegt om te controleren of je record is gepubliceerd, correct is opgebouwd en kan worden opgehaald.

7. Wat gebeurt er als DKIM mislukt?

Een DKIM-fout betekent dat het bericht is gemanipuleerd of niet correct is ondertekend. Ontvangers kunnen het als spam markeren, en als er een DMARC-beleid van kracht is en SPF ook niet voldoet, kan het bericht in quarantaine worden geplaatst of direct worden geweigerd.

8. Hoe vaak moeten DKIM-sleutels worden vernieuwd?

DKIM-sleutels moeten minstens één keer per jaar worden vernieuwd. Zorg ervoor dat je de nieuwe sleutel altijd eerst in het DNS publiceert voordat je de oude deactiveert, zodat er geen periode ontstaat waarin e-mails niet kunnen worden geverifieerd.

9. Kan DKIM phishing voorkomen?

DKIM alleen kan phishing niet voorkomen. DKIM maakt het moeilijker om je e-mail te vervalsen en voorkomt dat de inhoud wordt gemanipuleerd, maar het voorkomt niet dat het zichtbare ‘Van’-adres wordt vervalst; alleen DMARC-alignment doet dat. DKIM is een noodzakelijke onderdeel van een anti-phishingopstelling, maar niet de volledige oplossing.

10. Heeft DKIM invloed op de afleverbaarheid van e-mail?

DKIM heeft een positieve invloed op de afleverbaarheid van uw e-mails. Een correct ondertekende e-mail versterkt uw reputatie als afzender bij internetproviders, waardoor uw e-mails vaker in de inbox terechtkomen. Aangezien Google, Yahoo en Microsoft DKIM inmiddels verplicht stellen voor bulkverzenders, kan het ontbreken hiervan ertoe leiden dat uw e-mail in de spamfolder terechtkomt of wordt geweigerd.