Wat is DKIM? Het e-mailauthenticatieprotocol uitgelegd

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 <selector>._domainkey.<domein>, 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.

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 <selector>._domainkey.<jouwdomein.com>. 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.

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 <selector>._domainkey.<domein> 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.