Wat is DKIM?

Deze gids maakt deel uit van onze volledige gids over DKIM. Gerelateerd: het DKIM-record en hoe DKIM-handtekeningen werken.

DKIM - DomainKeys Identified Mail - is de tweede pijler van moderne e-mailauthenticatie. Terwijl SPF verifieert dat een bericht vanaf een geautoriseerde server is verzonden, gaat DKIM verder: het ondertekent het bericht zelf cryptografisch, wat bewijst dat de inhoud niet is gemanipuleerd en dat het beweerde verzendende domein het bericht daadwerkelijk heeft geautoriseerd.

RFC 6376 definieert DKIM als een methode om een domeinnaam aan een e-mailbericht te koppelen, waardoor een persoon, rol of organisatie enige verantwoordelijkheid voor het bericht kan opeisen. De handtekening overleeft het doorsturen van e-mail, wat een cruciaal voordeel is ten opzichte van SPF.

Het begrijpen van DKIM is essentieel voor iedereen die e-mailinfrastructuur beheert, omdat DKIM-uitlijning een van de twee wegen is om DMARC-authenticatie te laten slagen - en voor doorgestuurde mail is het vaak de enige weg.

Hoe DKIM werkt: het grote geheel

DKIM werkt volgens een eenvoudig cryptografisch principe: de verzendende server ondertekent het bericht met een privésleutel, en de ontvangende server verifieert de handtekening met een publieke sleutel die in DNS is gepubliceerd.

Het ondertekeningsproces (uitgaand)

1. De verzendende mailserver genereert een hash van specifieke e-mailheaders en de berichtbody
2. De server versleutelt deze hash met de DKIM-privésleutel van het domein
3. De server voegt een DKIM-Signature-header aan het bericht toe die de versleutelde hash, de selectornaam, het ondertekenende domein en metadata over welke headers zijn ondertekend bevat
4. Het bericht wordt naar de ontvangende server verzonden

Het verificatieproces (inkomend)

1. De ontvangende server haalt de DKIM-Signature-header uit het bericht
2. Het leest de waarden d= (domein) en s= (selector) uit de handtekening
3. Het voert een DNS-lookup uit voor <selector>._domainkey.<domain> om de publieke sleutel op te halen
4. Het gebruikt de publieke sleutel om de handtekening te ontsleutelen en de oorspronkelijke hash te herstellen
5. Het hasht onafhankelijk dezelfde headers en body met het opgegeven algoritme
6. Als de twee hashes overeenkomen, is de handtekening geldig - het bericht is authentiek en ongewijzigd

Voor een gedetailleerde technische uitleg van dit proces, zie Hoe DKIM werkt: een uitgebreide gids voor e-mailauthenticatie.

Voor de details van het verificatiealgoritme op RFC-niveau, zie Binnen RFC 6376: hoe DKIM-verificatie echt werkt.

De DKIM-Signature-header

Een DKIM-handtekeningheader ziet er zo uit:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt; t=1618884473;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Tag	Betekenis
v=1	DKIM-versie (altijd 1)
a=rsa-sha256	Ondertekeningsalgoritme
d=example.com	Ondertekenend domein (gebruikt voor DMARC-uitlijning)
s=selector1	Selector - identificeert welke publieke sleutel te gebruiken
c=relaxed/relaxed	Canonicalisatiemethode voor header/body
q=dns/txt	Querymethode voor de publieke sleutel
t=1618884473	Tijdstempel van ondertekening
h=from:to:subject:...	Lijst met headers die in de handtekening zijn opgenomen
bh=...	Body-hash
b=...	De handtekening zelf

DKIM-sleutels: publiek en privé

DKIM gebruikt asymmetrische cryptografie. De domeineigenaar genereert een sleutelpaar:

• Privésleutel - Veilig opgeslagen op de verzendende mailserver. Nooit gedeeld of gepubliceerd. Gebruikt om uitgaande berichten te ondertekenen.
• Publieke sleutel - Gepubliceerd in DNS als een TXT-record op <selector>._domainkey.<domain>. Gebruikt door ontvangende servers om handtekeningen te verifiëren.

DNS-recordformaat

Een DKIM DNS-record ziet er zo uit:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Tag	Betekenis
v=DKIM1	Versie
k=rsa	Sleuteltype (RSA is de standaard; Ed25519 komt op)
p=...	De publieke sleutel, base64-gecodeerd

U kunt de DKIM-publieke sleutel van elk domein opzoeken met de DKIM-lookuptool.

Sleutelgroottes

• 1024-bit RSA - De minimaal aanbevolen sleutelgrootte. Wordt nog steeds veel gebruikt, maar wordt naar moderne maatstaven als zwak beschouwd.
• 2048-bit RSA - De huidige aanbevolen standaard. Biedt sterke beveiliging, maar produceert langere DNS-records die mogelijk het opsplitsen van TXT-records vereisen.
• Ed25519 - Een nieuwer, efficiënter algoritme dat kortere handtekeningen en sleutels produceert. Ondersteund door een groeiend aantal mailservers, maar nog niet universeel.

Uitgebreide gids: DKIM’s cryptografische algoritmen begrijpen: RS256 vs RS512 en opkomende trends

Selectors: meerdere sleutels beheren

DKIM-selectors stellen een domein in staat om meerdere DKIM-sleutels tegelijk te publiceren. Elke sleutel wordt geïdentificeerd door een selectorstring, en de s=-tag in de DKIM-Signature-header vertelt de ontvanger welke selector (en dus welke publieke sleutel) voor verificatie te gebruiken.

Selectors dienen verschillende doelen:

• Meerdere verzenddiensten - Uw primaire mailserver en elke externe dienst (SendGrid, Mailchimp, enz.) kunnen elk hun eigen DKIM-sleutelpaar met een unieke selector hebben
• Sleutelrotatie - Bij het roteren van sleutels kunt u de nieuwe sleutel onder een nieuwe selector publiceren terwijl de oude selector actief blijft tijdens de overgangsperiode
• Departementale scheiding - Verschillende teams of afdelingen kunnen verschillende selectors gebruiken voor tracking- en beheerdoeleinden

Gangbare naamgevingsconventies voor selectors zijn s1, s2, google, sendgrid, k1 of op datum gebaseerde namen zoals 202604.

Canonicalisatie: omgaan met berichtwijzigingen

E-mailberichten worden onderweg vaak gewijzigd - witruimte wordt toegevoegd of verwijderd, headers worden herschreven en regeleindes kunnen veranderen. Canonicalisatie bepaalt hoe de onderteken- en verificatieprocessen het bericht normaliseren vóór het hashen, zodat kleine wijzigingen de handtekening niet breken.

Er zijn twee canonicalisatiemodi, onafhankelijk toegepast op headers en body:

• simple - Vrijwel geen tolerantie voor wijzigingen. Headers moeten exact overeenkomen (behalve voor witruimte aan het einde). De body wordt alleen genormaliseerd voor lege regels aan het einde. Gebruik dit wanneer u het volledige afleveringspad beheert en geen tussenpersoon het bericht zal wijzigen.
• relaxed - Toleranter. Headernamen worden in kleine letters gezet, witruimte wordt genormaliseerd en meerdere spaties worden tot één samengevoegd. In de body wordt witruimte aan het einde van elke regel verwijderd. Gebruik dit voor de meeste praktijksituaties.

De instelling c=relaxed/relaxed (relaxed voor zowel headers als body) is de meest gebruikelijke en aanbevolen configuratie.

DKIM-uitlijning

DKIM-uitlijning is een DMARC-concept dat bepaalt of het domein in de DKIM-handtekening (d=-waarde) overeenkomt met het domein in de zichtbare From-header. Dit is cruciaal omdat DMARC vereist dat ten minste een van SPF of DKIM zowel geldig als uitgelijnd is.

Relaxed uitlijning

De organisatiedomeinen moeten overeenkomen, maar subdomeinen zijn toegestaan. Bijvoorbeeld:

• From: user@example.com met d=mail.example.com - Slaagt voor relaxed uitlijning (zelfde organisatiedomein)
• From: user@example.com met d=example.com - Slaagt voor relaxed uitlijning

Strict uitlijning

De domeinen moeten exact overeenkomen:

• From: user@example.com met d=example.com - Slaagt voor strict uitlijning
• From: user@example.com met d=mail.example.com - Faalt voor strict uitlijning

Uitgebreide gids: DKIM-uitlijning beheersen: sleutels, handtekeningen en waarom e-mails verificatie niet halen

DKIM-sleutelrotatie

DKIM-privésleutels moeten periodiek worden geroteerd om de schade te beperken als een sleutel wordt gecompromitteerd. Het rotatieproces omvat:

1. Een nieuw sleutelpaar met een nieuwe selector genereren
2. De nieuwe publieke sleutel in DNS publiceren
3. De verzendende server configureren om met de nieuwe privésleutel te ondertekenen
4. Wachten op DNS-propagatie en handtekeningen met de nieuwe sleutel verifiëren
5. De oude publieke sleutel na een overgangsperiode uit DNS verwijderen

Hoe vaak moet u roteren? Er is geen universele standaard, maar gangbare aanbevelingen variëren van elke 6 maanden tot jaarlijks. Omgevingen met hoge beveiligingseisen kunnen vaker roteren.

Uitgebreide gids: Wanneer moet u uw DKIM-sleutels roteren?

Waarom DKIM faalt

DKIM-verificatie kan om verschillende redenen mislukken:

Berichtwijziging onderweg

Als een ondertekende header of de berichtbody na ondertekening wordt gewijzigd, komt de hash niet overeen en mislukt de verificatie. Veelvoorkomende boosdoeners zijn:

• Mailinglijsten die footers toevoegen of de onderwerpregel wijzigen
• E-mailgateways die headers herschrijven voor compliance- of beveiligingsscans
• Doorstuurdiensten die berichtheaders wijzigen

DNS-problemen

• Het DKIM-publieke-sleutelrecord bestaat niet of is onbereikbaar
• De selector in de handtekening komt niet overeen met een gepubliceerde sleutel
• DNS-propagatievertragingen na een sleutelrotatie

Configuratiefouten

• De privésleutel komt niet overeen met de gepubliceerde publieke sleutel
• Het ondertekeningsalgoritme in de handtekening komt niet overeen met het sleuteltype
• Headers vermeld in de h=-tag zijn niet meegenomen in de daadwerkelijke handtekeningberekening

Uitgebreide gidsen:

• Waarom faalt DKIM? Wat kunt u eraan doen?
• Ongeldige DKIM-handtekeningfout: zo lost u het op
• De veelvoorkomende SPF- en DKIM-fouten in 2026 vermijden

DKIM vs SPF: aanvullend, niet concurrerend

DKIM en SPF dienen verschillende doelen en hebben verschillende sterke punten:

Kenmerk	SPF	DKIM
Wat het verifieert	IP-adres van de verzendende server	Berichtintegriteit en herkomst
Hoe het werkt	DNS-lookup van geautoriseerde IP’s	Verificatie van cryptografische handtekening
Overleeft doorsturen	Nee - doorsturen wijzigt het verzendende IP	Ja - handtekening reist mee met het bericht
Beschermt inhoudsintegriteit	Nee	Ja - detecteert manipulatie
DNS-recordtype	TXT op het domein	TXT op selector._domainkey.domain
Basis voor DMARC-uitlijning	Return-Path-domein	d=-domein in handtekening

Omdat SPF breekt bij het doorsturen van e-mail (het IP van de doorstuurserver staat niet in het SPF-record van het oorspronkelijke domein), is DKIM vaak de enige authenticatiemethode die slaagt voor doorgestuurde berichten. Dit maakt DKIM-uitlijning essentieel voor domeinen die mailinglijsten, doorstuurregels of enige relayinfrastructuur gebruiken.

Uitgebreide gidsen:

• Hoe SPF verschilt van DKIM en DMARC
• Zijn uw SPF- en DKIM-identifiers uitgelijnd?
• Hoe u SPF-tests, DKIM en DMARC combineert voor beveiliging

DKIM voor doorgestuurde en gerelayde mail

Een van DKIM’s belangrijkste praktische voordelen ten opzichte van SPF is het gedrag bij het doorsturen van e-mail. Wanneer een bericht via een tussenserver wordt doorgestuurd (een mailinglijst, een automatische doorstuurregel of een relaydienst), breekt SPF omdat het IP-adres van de doorstuurserver niet in het SPF-record van het oorspronkelijke domein staat. DKIM daarentegen overleeft het doorsturen zolang de berichtinhoud niet wordt gewijzigd. Als u dit voor het eerst configureert, beantwoordt de AutoSPF FAQ de meest voorkomende installatievragen.

Daarom is DKIM cruciaal voor DMARC-compliance in omgevingen met:

• Mailinglijsten - Organisaties die deelnemen aan branchemailinglijsten of interne distributiegroepen
• E-mail doorsturen - Gebruikers die e-mail van de ene provider naar de andere doorsturen (bijv. een universiteitsadres doorsturen naar Gmail)
• Shared hosting - Omgevingen waar e-mail door gedeelde relayservers gaat
• E-mailgateways - Beveiligingsapparaten die mail relayen zonder de inhoud te wijzigen

DKIM breekt echter als de tussenpersoon de ondertekende delen van het bericht wijzigt. Veelvoorkomende wijzigingen die DKIM breken, zijn het toevoegen van footers, het herschrijven van de onderwerpregel of het verwijderen van bijlagen. Mailinglijstsoftware zoals Mailman en LISTSERV voegt vaak lijstheaders en footers toe, wat op body gebaseerde DKIM-handtekeningen kan breken.

De oplossing is om DKIM te configureren met c=relaxed/relaxed-canonicalisatie (die kleine witruimtewijzigingen tolereert) en ervoor te zorgen dat alle mailinglijstsoftware die u gebruikt zo is geconfigureerd dat DKIM-handtekeningen waar mogelijk behouden blijven.

Veelvoorkomende DKIM-configuratiepatronen

Verschillende e-mailinfrastructuuropstellingen vereisen verschillende DKIM-configuratiebenaderingen:

Enkele provider

Als al uw e-mail via één provider gaat (bijv. Google Workspace), verzorgt die provider automatisch de DKIM-ondertekening. U hoeft alleen de publieke sleutel die ze aanleveren in uw DNS te publiceren.

Meerdere providers met afzonderlijke selectors

Wanneer meerdere diensten namens u e-mail versturen, krijgt elke dienst zijn eigen DKIM-sleutelpaar met een unieke selector. Bijvoorbeeld:

• google._domainkey.example.com - DKIM-sleutel van Google Workspace
• s1._domainkey.example.com - DKIM-sleutel van SendGrid
• k1._domainkey.example.com - DKIM-sleutel van Mailchimp

Elke dienst ondertekent berichten met zijn eigen privésleutel, en ontvangers zoeken de juiste publieke sleutel op op basis van de selector in de DKIM-Signature-header.

On-premises ondertekening

Organisaties die hun eigen mailservers draaien (Exchange, Postfix, Exim) moeten hun eigen sleutelparen genereren, de privésleutel op de mailserver installeren en de publieke sleutel in DNS publiceren. U kunt een sleutelpaar aanmaken met onze gratis DKIM-generator. Dit geeft u volledige controle over het ondertekeningsproces, maar vereist dat u sleutelgeneratie, -rotatie en -opslag beheert.

DKIM en TLS: verschillende beveiligingslagen

DKIM en TLS (Transport Layer Security) dragen beide bij aan e-mailbeveiliging, maar werken op verschillende lagen:

• TLS versleutelt de verbinding tussen mailservers tijdens verzending en voorkomt afluisteren onderweg. Het verifieert niet de identiteit van de afzender en beschermt niet tegen spoofing.
• DKIM verifieert de identiteit van de afzender en de berichtintegriteit, maar versleutelt de berichtinhoud niet.

Beide zijn nodig voor uitgebreide e-mailbeveiliging.

Uitgebreide gids: TLS en DKIM: waarom u beide nodig hebt voor sterke e-mailbeveiliging

DKIM instellen voor uw platform

DKIM-configuratie verschilt per e-mailplatform. Het algemene proces is:

1. Genereer een DKIM-sleutelpaar (uw e-mailplatform doet dit meestal)
2. Publiceer de publieke sleutel als een DNS TXT-record op de juiste selectorlocatie
3. Schakel DKIM-ondertekening in op het verzendende platform
4. Verifieer de configuratie met een DKIM-lookup

Voor platformspecifieke instructies, zie deze gidsen:

• Definitieve gids voor Microsoft 365 SPF- en DKIM-configuratie
• DKIM-authenticatie: een complete gids voor veilige e-mailbezorging
• SPF en DKIM instellen voor Salesforce
• SPF en DKIM beheersen voor SendGrid
• Complete gids voor het instellen van Mailgun SPF en DKIM
• Hoe AutoSPF SPF en DKIM in cPanel mogelijk maakt

DKIM in de authenticatiestack

DKIM is een van de drie protocollen die samenwerken om e-mail te authenticeren:

• SPF - Verifieert dat de verzendende server geautoriseerd is
• DKIM - Verifieert berichtintegriteit en levert een handtekening op domeinniveau (deze gids)
• DMARC - Koppelt SPF en DKIM met uitlijningsvereisten, definieert het handhavingsbeleid en maakt rapportage mogelijk

DMARC vereist dat ten minste een van SPF of DKIM slaagt en is uitgelijnd met het From-headerdomein. In de praktijk maximaliseert het configureren van zowel SPF als DKIM uw kans om DMARC te laten slagen, want als de ene methode faalt (bijv. SPF faalt door doorsturen), kan de andere nog steeds een geldig uitgelijnd resultaat leveren.

Uitgebreide gidsen:

• Hoe SPF, DKIM en DMARC samenwerken tijdens authenticatiefouten
• E-mailauthenticatieprotocollen: SPF, DKIM, DMARC uitgelegd
• Hoe u SPF-flattener-compatibiliteit met DMARC en DKIM test

Diagnostische tools

• DKIM-lookuptool - Zoek en valideer DKIM-publieke sleutels voor elk domein en elke selector
• Domein-authenticatiechecker - Controleer SPF, DKIM en DMARC in één lookup
• SPF-checker - Valideer uw SPF-record naast DKIM
• DMARC-checker - Verifieer uw DMARC-beleid en uitlijningsinstellingen

Volgende stappen

1. Verifieer uw huidige DKIM-opstelling - Gebruik de DKIM-lookuptool om te controleren of uw domein geldige DKIM-sleutels heeft gepubliceerd
2. Controleer uitlijning - Zorg ervoor dat het d=-domein in uw DKIM-handtekeningen overeenkomt met uw From-headerdomein
3. Beoordeel sleutelsterkte - Bevestig dat u ten minste 2048-bit RSA-sleutels gebruikt
4. Plan sleutelrotatie - Stel een rotatieschema op en documenteer het proces
5. Implementeer DMARC - Als u dat nog niet hebt gedaan, stel DMARC in om SPF- en DKIM-uitlijning af te dwingen en geaggregeerde rapporten te ontvangen
6. Monitor met DMARC-rapporten - Gebruik DMARC-aggregaatrapporten om DKIM-fouten op alle ontvangende servers te identificeren