DKIM-richtlijnen

DKIM (DomainKeys Identified Mail) is een gratis techniek die een e-mail cryptografisch koppelt aan het domein dat hem heeft verstuurd. De verzendende server ondertekent het bericht met een private key; de ontvangende server controleert die handtekening tegen een public key die in DNS gepubliceerd staat.

Waarom dit belangrijk is

DKIM bewijst twee dingen tegelijk: dat een bericht daadwerkelijk van het domein komt dat het beweert, en dat de inhoud onderweg niet is aangepast. In tegenstelling tot SPF overleeft een DKIM-handtekening doorsturen (forwarding) — ze reist mee met het bericht zelf in plaats van af te hangen van welke server het doorstuurde — wat het een robuuster authenticatiesignaal maakt, en de andere helft van wat DMARC controleert.

Hoe het werkt

Wanneer een bericht wordt verstuurd, ondertekent de uitgaande mailserver het met een private key die alleen dat domein bezit. De ontvangende server zoekt de bijbehorende public key op in een DNS TXT-record (gepubliceerd onder een “selector”, zodat een domein meerdere sleutelparen kan hebben voor verschillende diensten) en controleert de handtekening. Is er iets in de ondertekende inhoud gewijzigd na het ondertekenen, dan slaagt de verificatie niet.

Ik wil meer weten

De uitleg hierboven dekt wat de meeste mensen nodig hebben. De rest van dit artikel is de gedetailleerde naslag: systeemparameters, welke headers ondertekend moeten worden, sleutelrotatie, en het uitbesteden van DKIM aan externe leveranciers.

Algemeen

• DKIM public key-records worden gepubliceerd als DNS TXT-records, beperkt tot 255 tekens per string (multi-string TXT-records kunnen er meerdere aan elkaar koppelen).
• De syntaxis van het DKIM-record moet vóór publicatie worden gevalideerd — controleer met tooling, en let op coderingsfouten door copy-pasten.
• DKIM public key-records zijn hoofdlettergevoelig.
• DKIM-ondertekening zou moeten gebeuren op de laatste mailserver (MTA) voordat een bericht je infrastructuur verlaat.
• Met DKIM-selectors kun je verschillende sleutelparen koppelen aan verschillende diensten of leveranciers die namens jou versturen.
• DNS CNAME-records kunnen het beheer van DKIM public keys centraliseren, en laten je DKIM public keys delegeren aan externe verzenders (zie “Externe leveranciers” hieronder).

Configuratie

• Algoritme: rsa-sha256, conform RFC 6376.
• Canonicalization: headers relaxed, body simple.
• Neem altijd de DKIM-tijdstempel op (t= in de DKIM-header), die vastlegt wanneer de handtekening is gemaakt.
• De sleutelgrootte moet minimaal 1024 bits zijn; 2048 bits wordt aanbevolen. Een 1024-bit sleutel past in één DNS TXT-record; een 2048-bit sleutel heeft een multi-string TXT-record nodig.
• Stel de l= parameter (body length count) niet in — die kan berichten kwetsbaar maken voor wijziging na ondertekening.
• Definieer altijd de DKIM-versie, v=DKIM1 (RFC-aanbevolen), en je sleuteltype, k=rsa (RFC-optioneel, maar het beïnvloedt hoe de p= public-key-data gelezen wordt).
• Gebruik de n= note-parameter om extra context over de sleutel vast te leggen, zoals de grootte en activatiedatum, bijv. n=2048,201709-1519.
• Zet de DKIM-testvlag (t=y;) niet op een public key die daadwerkelijk in productie wordt gebruikt.

Welke headers moeten worden ondertekend

Onderteken minimaal: From, To, Reply-To, Subject, Date, Message-ID, List-Unsubscribe, MIME-Version en Content-Type.

Onderteken niet: Return-Path, Received, of vrije-tekstvelden zoals Keywords/Comments, omdat deze onderweg legitiem kunnen wijzigen.

Beveiliging

• Overweeg From, To en Subject dubbel te ondertekenen, om manipulatie van juist deze velden lastiger te maken (bijv. h=From:From:To:To:Reply-To:Subject:Subject:Date:Message-ID:List-Unsubscribe:MIME-Version:Content-Type;).
• Gebruik unieke sleutelparen per domein, en bij voorkeur per verzender, zodat één sleutel kan worden ingetrokken zonder andere mailstromen te raken.
• Roteer sleutels regelmatig. Naarmate hardware sneller wordt, wordt het reverse-engineeren van een oudere private key na verloop van tijd haalbaarder. Roteer minimaal twee keer per jaar, met een overlapperiode van twee weken tot 30 dagen waarin zowel de oude als de nieuwe sleutel geldig zijn, en trek daarna de oude sleutel in. Voor mailstromen met een hoger belang (inclusief derde partijen die namens jou versturen) heeft vier keer per jaar de voorkeur.
• Domeinen die geen e-mail versturen, of dat niet zouden moeten doen, hoeven helemaal geen DKIM public keys te publiceren.

Externe leveranciers

Als een leverancier namens jou een DKIM-ondertekeningsgateway draait, maar geen directe controle heeft over jouw DNS-zone, gebruik dan een DKIM CNAME zodat jij de controle over de public key behoudt — bij voorkeur wijzend naar een DNS-zone die de gateway-operator wél direct beheert.

Voorbeeld: een gateway-operator (example.net) ondertekent mail voor een klantdomein (sample.com). De handtekening toont d=sample.com, maar de public keys staan onder een subdomein van example.net. Er worden twee selectors ingericht zodat sleutelrotatie kan plaatsvinden zonder downtime:

• In de DNS van sample.com: <vendor>-selector1._domainkey.sample.com (CNAME) → sample-com-selector1.dkim.example.net
• In de DNS van sample.com: <vendor>-selector2._domainkey.sample.com (CNAME) → sample-com-selector2.dkim.example.net
• In de DNS van example.net: sample-com-selector1.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<sleutelgrootte>,<datum>
• In de DNS van example.net: sample-com-selector2.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<sleutelgrootte>,<datum>

Hiermee beheert de gateway-operator het DKIM-sleutelbeheer volledig zelf, inclusief rotatie, zonder dat jij verdere DNS-wijzigingen hoeft door te voeren.

Bronnen & verder lezen

• RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376, aangevuld met RFC 8301 (eisen aan sleutelgrootte en algoritme) en RFC 8463 (Ed25519-handtekeningen).
• M3AAWG DKIM Key Rotation Best Common Practices, en de M3AAWG best practices voor het implementeren van DKIM ter voorkoming van kwetsbaarheden door sleutellengte.