DKIM-validatie: een beste praktijk voor e-mailauthenticatie
Bird
8 apr 2017
1 min read
Belangrijkste punten
DKIM (DomainKeys Identified Mail) is een inhoudsgebaseerde e-mailauthenticatiemethode die verifieert of een bericht is gewijzigd nadat het is ondertekend.
In tegenstelling tot SPF, dat het verzendpad valideert, valideert DKIM de berichtinhoud zelf met behulp van cryptografische handtekeningen.
DKIM gebruikt twee sleutels: een privésleutel om uitgaande berichten te ondertekenen en een publieke sleutel die in DNS is gepubliceerd voor ontvangers om handtekeningen te valideren.
Een DKIM-handtekening bevat hashes van zowel de headers als de body, selectors, tijdstempels en identiteitsvelden - die allemaal door de ontvanger moeten worden gereproduceerd en geverifieerd.
DKIM-validatie is afhankelijk van het eerst ontvangen van het volledige bericht, wat betekent dat fouten laat in het proces kunnen optreden.
Het oplossen van mislukte DKIM-validaties is vaak moeilijk omdat verzenders en ontvangers elkaars onderteken/verificatieomgevingen niet kunnen reproduceren.
Zelfs wanneer DKIM faalt, veroorzaakt het doorgaans niet direct inboxingsproblemen op zichzelf, tenzij het gecombineerd is met andere negatieve reputatiesignalen.
Q&A Hoogtepunten
Wat doet DKIM eigenlijk?
DKIM voegt een cryptografische handtekening toe aan een e-mail, waardoor de ontvangende server kan bevestigen of de berichtinhoud is gewijzigd nadat deze is verzonden.
Hoe verschilt DKIM van SPF?
SPF valideert wie toegestaan is om e-mail te verzenden voor een domein (padgebaseerd).
DKIM valideert of de inhoud intact is (inhoudgebaseerd).
Beide hebben verschillende doeleinden en vullen elkaar aan.
Wat zit er in een DKIM-Signature header?
Belangrijke velden zijn onder andere:
v= versie
a= algoritme
c= canoniseringsregels
d= ondertekeningsdomein
s= selector
h= headers opgenomen in de handtekening
bh= body hash
b= daadwerkelijke handtekeninggegevens
Elk deel draagt bij aan hoe de handtekening wordt gevalideerd.
Hoe valideert een ontvangende server DKIM?
Extraheert de d= en s= waarden.
Zoekt de openbare sleutel op bij:
selector._domainkey.domain
Genereert de header- en body-hashes opnieuw.
Vergelijkt ze met de bh= en b= waarden in de e-mail.
Als ze overeenkomen, slaagt het bericht voor DKIM.
Wat veroorzaakt DKIM om te falen?
Bericht gewijzigd tijdens verzending (zelfs witruimte wijzigingen als strikte kanonisering wordt gebruikt)
Verkeerde of ontbrekende openbare sleutel in DNS
Fouten in DNS-opmaak
Selector verkeerd verwijderd of gedraaid
Ongelijksoortige identiteiten (i= moet hetzelfde domein of subdomein van d= zijn)
Waarom kunnen DKIM failures moeilijk te troubleshooten zijn?
Omdat de ondertekenaar en validator in totaal verschillende omgevingen opereren — kan geen van beide partijen de hashvoorwaarden of handtekeningstatus van de ander reconstrueren.
Dit maakt ondoorzichtige "hash mismatch" fouten het meest frustrerend om te diagnosticeren.
Betekent een DKIM failure dat de email in spam zal belanden?
Niet noodzakelijk.
DKIM is slechts één signaal. Als het domein een sterke reputatie heeft en andere controles doorstaat (SPF, DMARC-uitlijning, lage klachtenpercentages), hebben geïsoleerde DKIM-fouten meestal geen invloed op de inboxing op zichzelf.
Waarom DKIM überhaupt gebruiken?
Beschermt de integriteit van berichten
Bouwt domeinreputatie op
Stelt DMARC-uitlijning in staat
Helpt mailboxproviders om legitieme afzenders van spooffers te onderscheiden
DKIM wordt beschouwd als een beste praktijk voor alle serieuze e-mailafzenders.
Wanneer we spreken over "Email Authentication", verwijzen we naar een techniek die de ontvanger van een bericht een zekere mate van zekerheid biedt dat het bericht daadwerkelijk afkomstig is van de vermeende bron van het bericht. Het idee achter dergelijke technieken is om een bepaald niveau van bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, mail die het vertrouwen van een ontvanger in het ontvangen van e-mail kan ondermijnen. Dat gezegd hebbende, het versturen van geauthenticeerde e-mail betekent niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt in beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee vormen van e-mailauthenticatie in gebruik:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
In de post van vandaag bespreek ik wat DKIM is en hoe het werkt.
Wanneer we spreken over "Email Authentication", verwijzen we naar een techniek die de ontvanger van een bericht een zekere mate van zekerheid biedt dat het bericht daadwerkelijk afkomstig is van de vermeende bron van het bericht. Het idee achter dergelijke technieken is om een bepaald niveau van bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, mail die het vertrouwen van een ontvanger in het ontvangen van e-mail kan ondermijnen. Dat gezegd hebbende, het versturen van geauthenticeerde e-mail betekent niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt in beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee vormen van e-mailauthenticatie in gebruik:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
In de post van vandaag bespreek ik wat DKIM is en hoe het werkt.
Wanneer we spreken over "Email Authentication", verwijzen we naar een techniek die de ontvanger van een bericht een zekere mate van zekerheid biedt dat het bericht daadwerkelijk afkomstig is van de vermeende bron van het bericht. Het idee achter dergelijke technieken is om een bepaald niveau van bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, mail die het vertrouwen van een ontvanger in het ontvangen van e-mail kan ondermijnen. Dat gezegd hebbende, het versturen van geauthenticeerde e-mail betekent niet dat de e-mail goed of gewenst is; het betekent alleen dat de mail zodanig is dat een reputatie voor de geauthenticeerde partij betrouwbaar kan worden vastgesteld en gebruikt in beslissingen over e-mailacceptatie en -plaatsing.
Er zijn tegenwoordig twee vormen van e-mailauthenticatie in gebruik:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
In de post van vandaag bespreek ik wat DKIM is en hoe het werkt.
DKIM Overzicht
In tegenstelling tot zijn verificatie-tegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, etc.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht feitelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of op zijn minst nauw verwant, is er met DKIM geen vereiste dat dit zo moet zijn.
Mijn doelen voor jou met deze post zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "inhoud-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit verklaart zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader zijn ingevoegd.
DKIM-validatie wordt uitgevoerd door het ontvangende domein dat probeert dezelfde twee hashes te genereren.
DKIM-validatie kan in veel gevallen niet worden voltooid totdat het volledige bericht is verzonden door de verzendende server.
Validatiefouten kunnen moeilijk op te lossen zijn.
In tegenstelling tot zijn verificatie-tegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, etc.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht feitelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of op zijn minst nauw verwant, is er met DKIM geen vereiste dat dit zo moet zijn.
Mijn doelen voor jou met deze post zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "inhoud-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit verklaart zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader zijn ingevoegd.
DKIM-validatie wordt uitgevoerd door het ontvangende domein dat probeert dezelfde twee hashes te genereren.
DKIM-validatie kan in veel gevallen niet worden voltooid totdat het volledige bericht is verzonden door de verzendende server.
Validatiefouten kunnen moeilijk op te lossen zijn.
In tegenstelling tot zijn verificatie-tegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, etc.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht feitelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of op zijn minst nauw verwant, is er met DKIM geen vereiste dat dit zo moet zijn.
Mijn doelen voor jou met deze post zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "inhoud-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit verklaart zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader zijn ingevoegd.
DKIM-validatie wordt uitgevoerd door het ontvangende domein dat probeert dezelfde twee hashes te genereren.
DKIM-validatie kan in veel gevallen niet worden voltooid totdat het volledige bericht is verzonden door de verzendende server.
Validatiefouten kunnen moeilijk op te lossen zijn.
“Content-Based” Authenticatie
DKIM wordt aangeduid als "inhoud-gebaseerde" authenticatie, in plaats van "pad-gebaseerde", omdat het al dan niet slagen van een bericht voor DKIM-validatie uitsluitend gebaseerd is op of de inhoud is veranderd tussen het moment dat het werd ondertekend en het moment dat validatie werd geprobeerd.
DKIM wordt aangeduid als "inhoud-gebaseerde" authenticatie, in plaats van "pad-gebaseerde", omdat het al dan niet slagen van een bericht voor DKIM-validatie uitsluitend gebaseerd is op of de inhoud is veranderd tussen het moment dat het werd ondertekend en het moment dat validatie werd geprobeerd.
DKIM wordt aangeduid als "inhoud-gebaseerde" authenticatie, in plaats van "pad-gebaseerde", omdat het al dan niet slagen van een bericht voor DKIM-validatie uitsluitend gebaseerd is op of de inhoud is veranderd tussen het moment dat het werd ondertekend en het moment dat validatie werd geprobeerd.
DKIM Ondertekening en Validatie
Organisaties die DKIM willen gebruiken voor het ondertekenen van e-mails, zullen eerst twee cryptografische sleutels genereren. Een van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van e-mails, en de andere wordt openbaar gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren van deze sleutels en het installeren ervan zijn platformafhankelijk en vallen buiten de scope van deze post, hoewel ik later het publiceren in DNS van de publieke DKIM-sleutel zal beschrijven.
Organisaties die DKIM willen gebruiken voor het ondertekenen van e-mails, zullen eerst twee cryptografische sleutels genereren. Een van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van e-mails, en de andere wordt openbaar gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren van deze sleutels en het installeren ervan zijn platformafhankelijk en vallen buiten de scope van deze post, hoewel ik later het publiceren in DNS van de publieke DKIM-sleutel zal beschrijven.
Organisaties die DKIM willen gebruiken voor het ondertekenen van e-mails, zullen eerst twee cryptografische sleutels genereren. Een van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van e-mails, en de andere wordt openbaar gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren van deze sleutels en het installeren ervan zijn platformafhankelijk en vallen buiten de scope van deze post, hoewel ik later het publiceren in DNS van de publieke DKIM-sleutel zal beschrijven.
De DKIM-Signature Header
Om onze begrip van DKIM te beginnen, laten we eerst kijken naar een DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
De DKIM-Signature header is een reeks van sleutel-waardeparen, sommige zijn interessanter voor de lezer dan anderen, maar ik zal ze allemaal hier beschrijven.
Eerst kijken we naar degenen die vooral in het voorbijgaan interesseren voor de lezer:
v=1; – Specificeert de DKIM-versie (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat gebruikt wordt om de cryptografische hashes te maken
c=relaxed/relaxed; – Er zijn twee sets van regels omtrent de verwijdering van witruimtes in de headers en body die kunnen worden toegepast bij het creëren van de hashes in een DKIM-signatuur; deze regels worden “kanonieke regels” genoemd (vandaar de sleutel c) en de regels zijn ofwel “relaxed” of “strict”.
t=1454417737; – Het tijdstempel van wanneer de signatuur werd gecreëerd.
Deze drie header-onderdelen bevatten de eigenlijke signatuurinformatie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dit is de hash van de body van het bericht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dit is een lijst van de headers die werden gebruikt om de signatuurdata te maken die hieronder wordt weergegeven.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit is de eigenlijke DKIM-signatuurdata
Deze drie delen zijn van het grootste belang voor de ontvangende server die de signatuur zal valideren:
d=welcome.foo.com; – Dit identificeert het domein dat het bericht heeft ondertekend
s=notices; – De selector; domeinen kunnen meerdere selectors hebben die ze gebruiken bij het ondertekenen van berichten.
i=@welcome.foo.com; – Dit is de identiteit namens wie het bericht is ondertekend. Syntactisch zal dit eruitzien als een e-mailadres, en kan zelfs een e-mailadres zijn; het lokale deel van het e-mailadres kan leeg zijn, zoals in dit voorbeeld, en het domeindeel moet hetzelfde zijn als, of een subdomein zijn van, het domein in het d= deel van de signatuur.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie bieden die nodig is om de ontvanger te helpen de handtekeningen te valideren.
Veld | Betekenis | Hoe Ontvangers Het Gebruiken |
|---|---|---|
v= | DKIM-versie (altijd 1) | Bevestigt het formaat van de signatuur |
a= | Hashing + ondertekening algoritme (bijv. rsa-sha256) | Verzekert dat de validator de signatuur correct reproduceert |
c= | Kanonieke regels (header/body) | Normaliseert witruimtes voordat er wordt gehased |
t= | Tijdstempel van signatuurcreatie | Wordt gebruikt voor versheidscontroles en replaypreventie |
bh= | Body-hash | Ontvanger regenereert dit om de integriteit van het bericht body te bevestigen |
h= | Lijst van ondertekende header velden | Verzekert dat headers gebruikt bij ondertekening beschikbaar en ongewijzigd zijn |
b= | Eigenlijke DKIM signatuur | Ontvanger verifieert deze signatuur tegen de publieke sleutel |
d= | Ondertekenend domein | Wordt gebruikt om de DNS publieke sleutel van de ondertekenaar te lokaliseren |
s= | Selector | Gecombineerd met domein om te vormen: selector._domainkey.domain |
i= | Ondertekenende identiteit | Moet hetzelfde zijn als of subdomein van d=, identificeert ondertekenende entiteit |
Om onze begrip van DKIM te beginnen, laten we eerst kijken naar een DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
De DKIM-Signature header is een reeks van sleutel-waardeparen, sommige zijn interessanter voor de lezer dan anderen, maar ik zal ze allemaal hier beschrijven.
Eerst kijken we naar degenen die vooral in het voorbijgaan interesseren voor de lezer:
v=1; – Specificeert de DKIM-versie (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat gebruikt wordt om de cryptografische hashes te maken
c=relaxed/relaxed; – Er zijn twee sets van regels omtrent de verwijdering van witruimtes in de headers en body die kunnen worden toegepast bij het creëren van de hashes in een DKIM-signatuur; deze regels worden “kanonieke regels” genoemd (vandaar de sleutel c) en de regels zijn ofwel “relaxed” of “strict”.
t=1454417737; – Het tijdstempel van wanneer de signatuur werd gecreëerd.
Deze drie header-onderdelen bevatten de eigenlijke signatuurinformatie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dit is de hash van de body van het bericht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dit is een lijst van de headers die werden gebruikt om de signatuurdata te maken die hieronder wordt weergegeven.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit is de eigenlijke DKIM-signatuurdata
Deze drie delen zijn van het grootste belang voor de ontvangende server die de signatuur zal valideren:
d=welcome.foo.com; – Dit identificeert het domein dat het bericht heeft ondertekend
s=notices; – De selector; domeinen kunnen meerdere selectors hebben die ze gebruiken bij het ondertekenen van berichten.
i=@welcome.foo.com; – Dit is de identiteit namens wie het bericht is ondertekend. Syntactisch zal dit eruitzien als een e-mailadres, en kan zelfs een e-mailadres zijn; het lokale deel van het e-mailadres kan leeg zijn, zoals in dit voorbeeld, en het domeindeel moet hetzelfde zijn als, of een subdomein zijn van, het domein in het d= deel van de signatuur.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie bieden die nodig is om de ontvanger te helpen de handtekeningen te valideren.
Veld | Betekenis | Hoe Ontvangers Het Gebruiken |
|---|---|---|
v= | DKIM-versie (altijd 1) | Bevestigt het formaat van de signatuur |
a= | Hashing + ondertekening algoritme (bijv. rsa-sha256) | Verzekert dat de validator de signatuur correct reproduceert |
c= | Kanonieke regels (header/body) | Normaliseert witruimtes voordat er wordt gehased |
t= | Tijdstempel van signatuurcreatie | Wordt gebruikt voor versheidscontroles en replaypreventie |
bh= | Body-hash | Ontvanger regenereert dit om de integriteit van het bericht body te bevestigen |
h= | Lijst van ondertekende header velden | Verzekert dat headers gebruikt bij ondertekening beschikbaar en ongewijzigd zijn |
b= | Eigenlijke DKIM signatuur | Ontvanger verifieert deze signatuur tegen de publieke sleutel |
d= | Ondertekenend domein | Wordt gebruikt om de DNS publieke sleutel van de ondertekenaar te lokaliseren |
s= | Selector | Gecombineerd met domein om te vormen: selector._domainkey.domain |
i= | Ondertekenende identiteit | Moet hetzelfde zijn als of subdomein van d=, identificeert ondertekenende entiteit |
Om onze begrip van DKIM te beginnen, laten we eerst kijken naar een DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
De DKIM-Signature header is een reeks van sleutel-waardeparen, sommige zijn interessanter voor de lezer dan anderen, maar ik zal ze allemaal hier beschrijven.
Eerst kijken we naar degenen die vooral in het voorbijgaan interesseren voor de lezer:
v=1; – Specificeert de DKIM-versie (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat gebruikt wordt om de cryptografische hashes te maken
c=relaxed/relaxed; – Er zijn twee sets van regels omtrent de verwijdering van witruimtes in de headers en body die kunnen worden toegepast bij het creëren van de hashes in een DKIM-signatuur; deze regels worden “kanonieke regels” genoemd (vandaar de sleutel c) en de regels zijn ofwel “relaxed” of “strict”.
t=1454417737; – Het tijdstempel van wanneer de signatuur werd gecreëerd.
Deze drie header-onderdelen bevatten de eigenlijke signatuurinformatie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dit is de hash van de body van het bericht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dit is een lijst van de headers die werden gebruikt om de signatuurdata te maken die hieronder wordt weergegeven.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit is de eigenlijke DKIM-signatuurdata
Deze drie delen zijn van het grootste belang voor de ontvangende server die de signatuur zal valideren:
d=welcome.foo.com; – Dit identificeert het domein dat het bericht heeft ondertekend
s=notices; – De selector; domeinen kunnen meerdere selectors hebben die ze gebruiken bij het ondertekenen van berichten.
i=@welcome.foo.com; – Dit is de identiteit namens wie het bericht is ondertekend. Syntactisch zal dit eruitzien als een e-mailadres, en kan zelfs een e-mailadres zijn; het lokale deel van het e-mailadres kan leeg zijn, zoals in dit voorbeeld, en het domeindeel moet hetzelfde zijn als, of een subdomein zijn van, het domein in het d= deel van de signatuur.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie bieden die nodig is om de ontvanger te helpen de handtekeningen te valideren.
Veld | Betekenis | Hoe Ontvangers Het Gebruiken |
|---|---|---|
v= | DKIM-versie (altijd 1) | Bevestigt het formaat van de signatuur |
a= | Hashing + ondertekening algoritme (bijv. rsa-sha256) | Verzekert dat de validator de signatuur correct reproduceert |
c= | Kanonieke regels (header/body) | Normaliseert witruimtes voordat er wordt gehased |
t= | Tijdstempel van signatuurcreatie | Wordt gebruikt voor versheidscontroles en replaypreventie |
bh= | Body-hash | Ontvanger regenereert dit om de integriteit van het bericht body te bevestigen |
h= | Lijst van ondertekende header velden | Verzekert dat headers gebruikt bij ondertekening beschikbaar en ongewijzigd zijn |
b= | Eigenlijke DKIM signatuur | Ontvanger verifieert deze signatuur tegen de publieke sleutel |
d= | Ondertekenend domein | Wordt gebruikt om de DNS publieke sleutel van de ondertekenaar te lokaliseren |
s= | Selector | Gecombineerd met domein om te vormen: selector._domainkey.domain |
i= | Ondertekenende identiteit | Moet hetzelfde zijn als of subdomein van d=, identificeert ondertekenende entiteit |
DKIM Validation
Naast de eis die vermeld is dat het i= domein hetzelfde moet zijn als of een subdomein moet zijn van het d= domein, worden de d= en s= bits gebruikt door de validator om de publieke DKIM-sleutel van de ondertekenaar in DNS op te zoeken. De sleutel is een TXT-record in DNS en wordt altijd gevonden op de locatie selector._domeinsleutel.domein. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de publieke DKIM-sleutel in DNS te vinden zijn op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uit kunnen zien:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
De validator gebruikt die sleutel (de p= bits) om zijn eigen set hashes van het bericht te produceren; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en kan het bericht bijdragen aan, en misschien profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Naast de eis die vermeld is dat het i= domein hetzelfde moet zijn als of een subdomein moet zijn van het d= domein, worden de d= en s= bits gebruikt door de validator om de publieke DKIM-sleutel van de ondertekenaar in DNS op te zoeken. De sleutel is een TXT-record in DNS en wordt altijd gevonden op de locatie selector._domeinsleutel.domein. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de publieke DKIM-sleutel in DNS te vinden zijn op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uit kunnen zien:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
De validator gebruikt die sleutel (de p= bits) om zijn eigen set hashes van het bericht te produceren; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en kan het bericht bijdragen aan, en misschien profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Naast de eis die vermeld is dat het i= domein hetzelfde moet zijn als of een subdomein moet zijn van het d= domein, worden de d= en s= bits gebruikt door de validator om de publieke DKIM-sleutel van de ondertekenaar in DNS op te zoeken. De sleutel is een TXT-record in DNS en wordt altijd gevonden op de locatie selector._domeinsleutel.domein. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de publieke DKIM-sleutel in DNS te vinden zijn op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uit kunnen zien:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
De validator gebruikt die sleutel (de p= bits) om zijn eigen set hashes van het bericht te produceren; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en kan het bericht bijdragen aan, en misschien profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Validatiefout en Problemen oplossen
Ik noemde hierboven dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben duidelijke oorzaken, zoals dat het bericht niet is ondertekend, of dat de openbare sleutel van het ondertekende domein niet is gevonden in DNS of niet syntactisch correct is, of misschien dat het bericht duidelijk is gewijzigd tijdens het transport. Wanneer die soorten fouten optreden, is het gemakkelijk om het probleem te achterhalen en een oplossing aan te bevelen. De moeilijke gevallen, echter, en de gevallen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht wel is ondertekend, de openbare sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator meldt dat de handtekening niet kon worden gevalideerd.
De reden dat deze moeilijk zijn om op te lossen, is omdat er geen werkelijke manier is voor beide zijden om de omstandigheden na te bootsen waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in zijn DKIM-Signature-header de hashes die door de ondertekenaar werden gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan daarom niet proberen de handtekening onder de omstandigheden van de ondertekenaar te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en heeft dus geen manier om te proberen het bericht op dezelfde manier te valideren als de validator deed.
Fouten zoals ik hier beschrijf zijn zeldzame gevallen, en DKIM-validatiefouten op zich hebben meestal geen invloed op de afleveringsplaatsing. Terwijl DKIM berichtenauthenticatie afhandelt, het implementeren van uitgebreide emailvalidatietechnieken zorgt ervoor dat je naar legitieme adressen stuurt die je berichten daadwerkelijk kunnen ontvangen en authenticeren. Het is mijn ervaring dat dergelijke fouten meer supporttickets veroorzaken dan enige andere soort DKIM-kwestie.
Ik noemde hierboven dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben duidelijke oorzaken, zoals dat het bericht niet is ondertekend, of dat de openbare sleutel van het ondertekende domein niet is gevonden in DNS of niet syntactisch correct is, of misschien dat het bericht duidelijk is gewijzigd tijdens het transport. Wanneer die soorten fouten optreden, is het gemakkelijk om het probleem te achterhalen en een oplossing aan te bevelen. De moeilijke gevallen, echter, en de gevallen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht wel is ondertekend, de openbare sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator meldt dat de handtekening niet kon worden gevalideerd.
De reden dat deze moeilijk zijn om op te lossen, is omdat er geen werkelijke manier is voor beide zijden om de omstandigheden na te bootsen waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in zijn DKIM-Signature-header de hashes die door de ondertekenaar werden gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan daarom niet proberen de handtekening onder de omstandigheden van de ondertekenaar te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en heeft dus geen manier om te proberen het bericht op dezelfde manier te valideren als de validator deed.
Fouten zoals ik hier beschrijf zijn zeldzame gevallen, en DKIM-validatiefouten op zich hebben meestal geen invloed op de afleveringsplaatsing. Terwijl DKIM berichtenauthenticatie afhandelt, het implementeren van uitgebreide emailvalidatietechnieken zorgt ervoor dat je naar legitieme adressen stuurt die je berichten daadwerkelijk kunnen ontvangen en authenticeren. Het is mijn ervaring dat dergelijke fouten meer supporttickets veroorzaken dan enige andere soort DKIM-kwestie.
Ik noemde hierboven dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben duidelijke oorzaken, zoals dat het bericht niet is ondertekend, of dat de openbare sleutel van het ondertekende domein niet is gevonden in DNS of niet syntactisch correct is, of misschien dat het bericht duidelijk is gewijzigd tijdens het transport. Wanneer die soorten fouten optreden, is het gemakkelijk om het probleem te achterhalen en een oplossing aan te bevelen. De moeilijke gevallen, echter, en de gevallen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht wel is ondertekend, de openbare sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator meldt dat de handtekening niet kon worden gevalideerd.
De reden dat deze moeilijk zijn om op te lossen, is omdat er geen werkelijke manier is voor beide zijden om de omstandigheden na te bootsen waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in zijn DKIM-Signature-header de hashes die door de ondertekenaar werden gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan daarom niet proberen de handtekening onder de omstandigheden van de ondertekenaar te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en heeft dus geen manier om te proberen het bericht op dezelfde manier te valideren als de validator deed.
Fouten zoals ik hier beschrijf zijn zeldzame gevallen, en DKIM-validatiefouten op zich hebben meestal geen invloed op de afleveringsplaatsing. Terwijl DKIM berichtenauthenticatie afhandelt, het implementeren van uitgebreide emailvalidatietechnieken zorgt ervoor dat je naar legitieme adressen stuurt die je berichten daadwerkelijk kunnen ontvangen en authenticeren. Het is mijn ervaring dat dergelijke fouten meer supporttickets veroorzaken dan enige andere soort DKIM-kwestie.
