DKIM voor Gmail: Een complete installatiegids voor 2026

Je hebt het waarschijnlijk wel eens meegemaakt. Een klantvraag, een opvolging van een offerte of een campagne waar je veel tijd in hebt gestoken belandt in de spam, en de enige aanwijzing is dat de afzender er prima uitziet terwijl Gmail het bericht toch als verdacht behandelt. Dat is precies waar DKIM voor Gmail belangrijk is, omdat het Gmail een cryptografisch signaal geeft dat je e-mail echt van jouw domein afkomstig is en onderweg niet is gewijzigd.

Gmail behandelt authenticatie niet langer als een leuke extra. De eigen gegevens van Google laten zien dat 76,9% van de e-mails die Gmail ontvangt ondertekend is met DKIM, en Google vereist van bulkverzenders dat zij SPF, DKIM en DMARC gebruiken (Google’s Gmail-richtlijnen voor authenticatie). Als je nieuwsbrieven, verkoopmails, ondersteuningsupdates of mail-merge-campagnes verstuurt, maakt dat DKIM onderdeel van de basisinstallatie, niet van een latere optimalisatie. Voor een bredere inleiding over de authenticatiestack, zie email authentication basics.

Waarom je Gmail-berichten DKIM-authenticatie nodig hebben

Wanneer een klant zegt dat ze je offerte, opvolging of campagnemail nooit hebben gezien, begint het probleem vaak bij vertrouwen. Gmail moet beslissen of het bericht eruitziet alsof het oprecht van jouw domein komt, en die beslissing beïnvloedt of het de inbox, het tabblad promoties of de spam bereikt.

DKIM, DomainKeys Identified Mail, geeft Gmail dat bewijs. Het ondertekent uitgaande e-mail met een domeinspecifieke sleutel, en Gmail controleert die handtekening wanneer het bericht aankomt. Als de handtekening overeenkomt, heeft het bericht een sterkere basis om als legitieme zakelijke e-mail te worden behandeld en is de kans kleiner dat het tijdens het filteren wordt tegengehouden.

Ondertekende e-mail helpt ook om je domein te beschermen tegen spoofing. Zonder DKIM kan iemand een bericht sturen dat lijkt te komen van jouw bedrijf, en inbox-providers hebben minder signalen om jouw mail te scheiden van een valse kopie. Dat is een direct risico voor kleine bedrijven die vertrouwen op Gmail voor klantreacties, facturen en mail-merge-campagnes.

Een ondertekend domein geeft je ook een schoner reputatiesignaal. Gmail kijkt naar authenticatie als onderdeel van het bredere vertrouwensplaatje, dus een correct ondertekend bericht ondersteunt je reputatie als afzender in plaats van Gmail te dwingen te raden of de mail veilig is. Voor het grotere plaatje over hoe de stukjes in elkaar passen, zie this authentication overview.

Veel kleine bedrijven proberen de bezorgbaarheid te verbeteren door onderwerpregels te wijzigen, verzendingen te spreiden of de hoofdtekst te herschrijven. Die aanpassingen kunnen helpen bij de betrokkenheid, maar ze vervangen authenticatie niet. Als het bericht zelf niet correct is ondertekend, heeft Gmail nog steeds een reden om het met voorzichtigheid te behandelen.

Genereer je DKIM-sleutel in Google Workspace

Begin in de Google Workspace-beheerdersconsole en ga vervolgens naar het gedeelte voor e-mailauthenticatie voor het domein dat je wilt ondertekenen. Het installatieproces van Google is ontworpen rond één simpel idee: genereer een nieuw record, publiceer het in DNS, keer dan terug naar de beheerdersconsole en klik op Start authenticatie (Google Workspace DKIM setup sequence).

Zoek het authenticatiescherm

Het pad bevindt zich meestal onder Apps, dan Google Workspace, dan Gmail, en dan E-mail verifiëren. Dat is waar Google het DKIM-materiaal aanmaakt dat aan jouw domein is gekoppeld. Als je meer dan één domein beheert, wees dan voorzichtig dat je het domein kiest dat verantwoordelijk is voor het verzenden van e-mail, in plaats van alleen het domein dat eigenaar is van je website.

Het selector-voorvoegsel is onderdeel van de recordnaam die Google je geeft. Zie het als een label dat Gmail helpt te weten naar welke DKIM-sleutel het later moet zoeken. De documentatie van Google laat ook zien dat 2048-bit sleutels de voorkeursoptie zijn wanneer je omgeving dit ondersteunt, wat een verschuiving weerspiegelt naar sterkere cryptografische authenticatie in plaats van het absolute minimum.

Operationele opmerking: genereer de sleutel eerst in Google en kopieer vervolgens de exacte hostnaam en TXT-waarde die het je geeft. Het raden van de recordnaam is een van de snelste manieren om de installatie te verbreken.

Kopieer de recordgegevens zorgvuldig

Google toont een DNS-hostnaam en een TXT-recordwaarde. Die twee onderdelen zijn belangrijker dan het schermproces zelf. De hostnaam is wat DNS gebruikt om de sleutel te publiceren, en de TXT-waarde is de openbare helft van het handtekeningrecord.

Als je een mailtool of een met Gmail verbonden outreach-workflow gebruikt, is dit ook het punt waarop je ervoor moet zorgen dat je het juiste verzenddomein instelt. Voor bedrijven die één domein in Gmail gebruiken en een ander in een verzendplatform, is de verkeerde domeinkeuze een veelvoorkomende bron van verwarring. Als je ook de SPF-kant van het plaatje nodig hebt, past this Gmail SPF guide goed bij de DKIM-installatie.

Houd de recordtekst precies zoals Google deze verstrekt. Zelfs een kleine typefout in het hostlabel of de geplakte waarde kan voorkomen dat het domein later wordt geverifieerd, en dat zul je niet weten door alleen naar het Gmail-opstelscherm te kijken.

Publiceer het DKIM-record naar de DNS van je domein

Je DNS-provider is de plek waar de DKIM-sleutel actief wordt voor de buitenwereld. Google kan het record genereren, maar Gmail zal de handtekening niet vertrouwen totdat die openbare sleutel bestaat in de DNS-zone voor het domein van waaruit je verzendt.

Open het DNS-beheergedeelte voor het domein en voeg een TXT-record toe met de exacte hostnaam en TXT-waarde die Google je geeft. Dat record is wat Gmail in staat stelt om uitgaande e-mail later te controleren. Als je provider een vereenvoudigde interface gebruikt, zoek dan naar DNS-records, domeinrecords of geavanceerde DNS-instellingen.

Nauwkeurigheid is hier belangrijker dan snelheid. Kopieer de tekst precies zoals getoond, want dit is niet de plek om de waarde in te korten, opnieuw op te maken of op te schonen. Een ontbrekend teken of een extra spatie kan de authenticatie verbreken, ook al ziet het record er in één oogopslag goed genoeg uit.

Voorbeeldvorm, niet blindelings kopiëren:
Hostnaam, de DKIM-selector die Google heeft gegenereerd.
Type, TXT.
Waarde, de volledige DKIM-reeks die Google je heeft gegeven.

Voor mail-merge-tools en met Gmail verbonden outreach-workflows moet de domeinkeuze overeenkomen met de mailbox die de berichten verzendt. Als je verzendplatform een ander domein gebruikt dan het domein in Google Workspace, zal een record in de verkeerde zone niets doen voor de bezorgbaarheid. Als je ook de SPF-kant op één lijn moet krijgen, is this SPF setup resource for Gmail een nuttige metgezel terwijl je de authenticatierecords afrondt.

Nadat je het record hebt gepubliceerd, moet je DNS de tijd geven om bij te werken voordat je gaat testen. Sommige providers tonen de wijziging snel, terwijl andere er langer over doen om overal op internet te verschijnen. Richtlijnen voor DNS-propagatie leggen uit waarom beheerders vaak wachten voordat ze proberen het ondertekenen in Google Admin in te schakelen, aangezien de DNS-kant meestal het traagste onderdeel van de installatie is (DNS propagation timing guidance).

Als je SPF al beheert, houd de volledige recordset dan consistent over het hele domein. DKIM, SPF en het verzenddomein moeten in dezelfde richting wijzen, vooral als je verzendt vanuit Gmail en een apart outreach-platform. Een record dat op het verkeerde domein is gepubliceerd, helpt Gmail niet om de mail die je systeem verlaat te vertrouwen.

Zodra het record op zijn plaats staat, keer je terug naar Google Admin en bereid je je voor om het ondertekenen te activeren. Als het DNS-item misvormd is, zal Google de sleutel niet kunnen verifiëren, en het probleem zal eruitzien als een Gmail-probleem, ook al begon het in DNS.

Verifieer en test je DKIM-installatie

Nadat het DNS-record live is, keer je terug naar Google Admin en klik je op Start authenticatie. Die schakelaar maakt niet uit zichzelf DKIM aan; het vertelt Google om te beginnen met het ondertekenen van e-mail nadat het de openbare sleutel in DNS kan zien. De installatie wordt pas als voltooid beschouwd wanneer Google het domein als volledig geverifieerd toont in de beheerdersconsole.

De schoonste controle is nog steeds een echt bericht dat naar een externe mailbox wordt gestuurd. De eigen richtlijnen van Google zeggen dat je de headers moet inspecteren en moet zoeken naar een Authentication-Results regel die expliciet dkim=pass header.i=@jouwdomein.nl toont (Google Workspace DKIM verification guidance). Dat vertelt je dat de handtekening het transport heeft overleefd en overeenkomt met het domein dat het hoorde te vertegenwoordigen.

Hoe een succesvol resultaat eruitziet

Een geslaagde test toont meestal het DKIM-resultaat in de ruwe headers, niet in de normale berichtweergave. Je ziet mogelijk ook gerelateerde velden die de ondertekenende identiteit bevestigen, maar de belangrijkste regel is de regel die zegt dat DKIM is geslaagd voor jouw domein. Als die regel ontbreekt, behandel het bericht dan als niet-geverifieerd totdat je weet waarom.

Een checker van derden kan helpen, maar deze moet bevestigen wat de header je al vertelt. Gebruik het als een snelle gezondheidscheck, niet als de enige bron van waarheid. Het sterkste bewijs is nog steeds een daadwerkelijk extern bericht met geldige, door Gmail herkende headers.

Als de header dkim=pass zegt, werkt de handtekening. Als dat niet zo is, ligt het probleem meestal bij de plaatsing van het record, de propagatie of een mismatch tussen de selector en het live DNS-item.

Veel beheerders stoppen te vroeg en vertrouwen alleen op de status in de beheerdersconsole. Dat is nuttig, maar het vervangt niet het lezen van de berichtheader aan de ontvangende kant. De mailbox is waar Gmail zijn beslissing neemt, dus daar wil je het resultaat bevestigen.

Veelvoorkomende DKIM-fouten oplossen

De meeste DKIM-problemen vallen in een kleine set voorspelbare categorieën. Elk laat een ander spoor achter, dus je kunt het meestal achterhalen zonder te raden, zelfs als je verzendt vanuit een mail-merge-tool en controleert waarom de ene campagne anders landt dan de volgende.

Wanneer Google zegt dat authenticatie niet is geverifieerd

Als Google het domein nog steeds als niet-geverifieerd toont, begin dan bij propagatie. DNS-updates verschijnen niet altijd overal tegelijk, dus een vers DKIM-record kan correct lijken in je configuratiescherm terwijl Gmail nog steeds de oudere status ziet. Sommige installatiegidsen adviseren om te wachten voordat je op Start authenticatie klikt in Google Admin, wat vaak de veiligste zet is als de wijziging net is gepubliceerd.

Als de status daarna nog steeds niet verandert, inspecteer dan het TXT-record in je DNS-dashboard regel voor regel. Een ontbrekend teken, een verkeerde hostnaam of een record dat onder het verkeerde label is toegevoegd, kan verificatie blokkeren, zelfs als de interface er prima uitziet.

Wanneer de header-controle mislukt

Een mislukte header betekent meestal dat het bericht is verzonden, maar dat de handtekening niet overeenkwam met wat Gmail verwachtte. Dat gebeurt vaak wanneer de selector in de e-mail niet overeenkomt met de selector die je hebt gepubliceerd, of wanneer er meer dan één DKIM-record bestaat en het verzendsysteem de verkeerde kiest.

Voor verzenders die mail-merge- of outreach-tools gebruiken, verschijnt dit vaak als een bericht dat ergens in het pad is ondertekend, maar nog steeds niet standhoudt in de inbox van de ontvanger. Als je ook te maken hebt met plaatsingsproblemen, bekijk dan practical ways to prevent Gmail spam issues. DKIM helpt bij authenticatie, maar het lost niet elk filterprobleem op zichzelf op.

Wanneer het DNS-record er goed uitziet maar toch mislukt

Soms staat het record er en is het toch fout. De TXT-waarde moet exact overeenkomen met de door Google gegenereerde tekst, inclusief de DKIM-versietag en het sleutelmateriaal. Als je DNS-provider de waarde op een manier verpakt die de reeks wijzigt, voer deze dan opnieuw in zodat het volledige record intact blijft.

Als de provider het sleutelformaat dat je hebt gekozen niet aankan, is een andere DNS-instelling misschien makkelijker om mee te werken. In de praktijk veroorzaken fouten bij het kopiëren en plakken meer mislukkingen dan providerlimieten, dus begin met het controleren van het record tegen wat Google heeft gegenereerd.

Volgorde voor probleemoplossing: verifieer dat het record bestaat, bevestig dat de selector overeenkomt, wacht op propagatie en test vervolgens opnieuw de header.

Die volgorde voorkomt dat je te veel variabelen tegelijk wijzigt. Als je het record, de selector en de verzendtool allemaal tegelijk bewerkt, weet je niet welke wijziging het probleem heeft opgelost.

Als je team ook uitgaande e-mail uit de spam wil houden, geven these practical ways to prevent Gmail spam issues je een nuttige volgende controle nadat DKIM is ingesteld.

Geavanceerde tips voor mail-merge en onderhoud

Een DKIM-pass betekent niet automatisch dat elk bericht zich op dezelfde manier zal gedragen. De richtlijnen van Google wijzen naar DMARC-uitlijning, waarbij het DKIM-ondertekenende domein, de d= waarde, overeenkomt met het zichtbare Van-domein. Als die niet op één lijn liggen, kan een bericht in de ene zin nog steeds geauthenticeerd lijken terwijl het de uitlijningscontrole faalt die belangrijk is voor bezorging en vertrouwen (Google Workspace DKIM guidance).

Dat is erg belangrijk voor mail-merge-workflows, CRM-verzendingen en ondersteuningstools. Een campagne kan correct worden ondertekend door de verzendservice, maar er toch misplaatst uitzien vanuit het oogpunt van de ontvanger als de zichtbare afzender en het geauthenticeerde domein uit elkaar drijven. Voor teams die bredere outreach-tools evalueren, kunnen resources for small business digital marketing helpen om authenticatie te kaderen als onderdeel van de volledige stack, niet als een op zichzelf staande oplossing.

Als je een product gebruikt zoals Mail Merge for Gmail, is de belangrijkste vraag of de berichten worden verzonden vanuit het domein dat je al hebt geauthenticeerd en of het zichtbare Van-adres overeenkomt met dat domein. Dat is de praktische grens tussen een technisch ondertekend bericht en een bericht dat is ingesteld voor een schonere uitlijning in Gmail en andere inboxen.

Houd onderhoud simpel

Behandel DKIM als een doorlopend bezit, niet als een eenmalige taak. Controleer of de selector nog steeds overeenkomt met het live record na elke DNS-wijziging, domeinmigratie of platformwissel. Als je ooit sleutels roteert, update dan eerst het DNS-item en bevestig vervolgens de nieuwe handtekening voordat je de oude intrekt.

Houd ook de andere authenticatielagen in de gaten. SPF en DMARC zijn geen vervanging voor DKIM, maar ze maken de algehele installatie veel veerkrachtiger. In een omgeving met kleine bedrijven is die combinatie meestal makkelijker gezond te houden dan later inbox-problemen proberen te diagnosticeren.

Als je meerdere verzenders beheert, maak dan een korte inventaris van elk systeem dat e-mail verstuurt namens je bedrijf. Nieuwsbrief-tools, helpdesks, facturatieplatforms en handmatige Gmail-verzendingen kunnen zich allemaal anders gedragen. De mensen die de ergste bezorgbaarheidsproblemen vermijden, zijn degenen die precies weten welk systeem welk bericht ondertekent.

---

Als je dit instelt voor klantupdates, outreach of mail-merge-campagnes, voltooi het werk dan door zowel de Gmail-header als het zichtbare Van-domein te controleren, en houd SPF en DMARC vervolgens synchroon met dezelfde verzendidentiteit. Als je een op Gmail gebaseerde verzendworkflow wilt die dicht bij de inbox blijft terwijl je personalisatie beheert vanuit Sheets, bekijk dan Mail Merge for Gmail.