DKIM stelt een domein in staat om uitgaande e-mailberichten met een persoonlijke sleutel te ondertekenen, waardoor ontvangende servers de handtekening kunnen verifiëren met behulp van de openbare sleutel van de afzender die in DNS is gepubliceerd. Dit bewijst dat het bericht werkelijk afkomstig is van dat domein en niet is gemanipuleerd.
Hoe het werkt:
De verzendende mailserver ondertekent geselecteerde e-mailheaders en de berichtinhoud, waarbij een DKIM-Signature:-headerveld in het bericht wordt ingevoegd. De openbare sleutel wordt als TXT-record in DNS gepubliceerd op selector._domainkey.domain.com. Wanneer de ontvangende server het e-mailbericht ontvangt, extraheert het de selector en het domein uit de handtekeningheader, zoekt de openbare sleutel op via DNS en verifieert of de cryptografische handtekening overeenkomt met de berichtinhoud.
De handtekening dekking een gesleuteliseerde (vereenvoudigde) vorm van headers zoals From, Subject en Date, plus de berichttekst. De DKIM-Signature-header bevat tags zoals:
d=— het ondertekeningsdomeins=— de selectornaama=— het algoritme (bijv.rsa-sha256,ed25519-sha256)b=— de werkelijke handtekeningswaarde
Voorbeeld DNS-record:
selector1._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
DKIM werkt samen met SPF en DMARC als onderdeel van een gelaagde e-mailauthenticatiestrategie. In tegenstelling tot SPF verifieert DKIM het envelope-from-adres niet—het bewijst alleen dat het ondertekeningsdomein het bericht heeft geautoriseerd. Dit is waarom DMARC-uitlijningsbeleidsregels DKIM of SPF aan het zichtbare From-adres koppelen.
WarningE-mailforwarding en mailinglijsten die headers wijzigen of voetteksten toevoegen, verbreken DKIM-handtekeningen, omdat de ondertekende inhoud niet meer overeenkomt. Dit is een veelvoorkomende oorzaak van verificatiefouten in doorgestuurde berichten.