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 authenticatietegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem e-mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, enz.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht daadwerkelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of ten minste nauw verwant, is er met DKIM geen vereiste dat dit het geval is.
Mijn doelen voor jou met dit bericht zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "content-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit bevestigt zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader worden 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 door de verzendende server is overgedragen.
Validatiefouten kunnen moeilijk te troubleshooten zijn.
In tegenstelling tot zijn authenticatietegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem e-mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, enz.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht daadwerkelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of ten minste nauw verwant, is er met DKIM geen vereiste dat dit het geval is.
Mijn doelen voor jou met dit bericht zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "content-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit bevestigt zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader worden 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 door de verzendende server is overgedragen.
Validatiefouten kunnen moeilijk te troubleshooten zijn.
In tegenstelling tot zijn authenticatietegenhanger SPF, dat een manier biedt voor een domein om een host te autoriseren om namens hem e-mail te verzenden, biedt DKIM een manier voor een entiteit (domein, organisatie, persoon, enz.) om verantwoordelijkheid te nemen voor een bericht, onafhankelijk van de entiteit die het bericht daadwerkelijk heeft verzonden. Hoewel in veel gevallen de verantwoordelijke entiteit en de verzendende entiteit hetzelfde zullen zijn, of ten minste nauw verwant, is er met DKIM geen vereiste dat dit het geval is.
Mijn doelen voor jou met dit bericht zijn dat je de volgende concepten over DKIM leert en begrijpt:
DKIM is een "content-gebaseerde" authenticatie, in tegenstelling tot de "pad-gebaseerde" SPF.
De verantwoordelijke entiteit bevestigt zijn verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtheader worden 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 door de verzendende server is overgedragen.
Validatiefouten kunnen moeilijk te troubleshooten zijn.
“Content-Based” Authenticatie
DKIM wordt aangeduid als "op inhoud gebaseerde" authenticatie, in plaats van "op pad gebaseerde", omdat of een bericht DKIM-validatie doorstaat, uitsluitend gebaseerd is op de vraag of de inhoud is veranderd tussen het moment van ondertekening en het moment dat de validatie werd gepoogd.
DKIM wordt aangeduid als "op inhoud gebaseerde" authenticatie, in plaats van "op pad gebaseerde", omdat of een bericht DKIM-validatie doorstaat, uitsluitend gebaseerd is op de vraag of de inhoud is veranderd tussen het moment van ondertekening en het moment dat de validatie werd gepoogd.
DKIM wordt aangeduid als "op inhoud gebaseerde" authenticatie, in plaats van "op pad gebaseerde", omdat of een bericht DKIM-validatie doorstaat, uitsluitend gebaseerd is op de vraag of de inhoud is veranderd tussen het moment van ondertekening en het moment dat de validatie werd gepoogd.
DKIM Ondertekening en Validatie
Organisaties die mail willen ondertekenen met DKIM, zullen eerst twee cryptografische sleutels genereren. Eén van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van mail, en de andere moet openbaar worden gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren en installeren van deze sleutels zijn platformafhankelijk en vallen buiten de scope van dit bericht, hoewel ik later het publiceren van de openbare DKIM-sleutel in DNS zal beschrijven.
Organisaties die mail willen ondertekenen met DKIM, zullen eerst twee cryptografische sleutels genereren. Eén van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van mail, en de andere moet openbaar worden gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren en installeren van deze sleutels zijn platformafhankelijk en vallen buiten de scope van dit bericht, hoewel ik later het publiceren van de openbare DKIM-sleutel in DNS zal beschrijven.
Organisaties die mail willen ondertekenen met DKIM, zullen eerst twee cryptografische sleutels genereren. Eén van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van mail, en de andere moet openbaar worden gemaakt in DNS voor gebruik door ontvangende domeinen bij pogingen om de handtekening te valideren. De methoden voor het genereren en installeren van deze sleutels zijn platformafhankelijk en vallen buiten de scope van dit bericht, hoewel ik later het publiceren van de openbare DKIM-sleutel in DNS zal beschrijven.
De DKIM-Signature Header
Om te beginnen met ons begrip van DKIM, 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 sleutel-waarde paren, sommige interessanter voor de lezer dan andere, maar ik zal ze hier allemaal beschrijven.
Eerst kijken we naar de onderdelen die vooral van voorbijgaande interesse zijn voor de lezer:
v=1; – Geeft de DKIM-versie aan (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat wordt gebruikt om de cryptografische hashes te construeren
c=relaxed/relaxed; – Er zijn twee sets regels met betrekking tot het verwijderen van witruimte in de headers en body die kunnen worden toegepast bij het maken van hashes in een DKIM-handtekening; deze regels worden 'canonieke regels' genoemd (vandaar de sleutel c) en de regelsets zijn ofwel 'relaxed' of 'strict'.
t=1454417737; – Het tijdstempel van wanneer de handtekening is gemaakt.
Deze drie headeronderdelen bevatten de daadwerkelijke handtekeninginformatie:
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 zijn gebruikt om de handtekeninggegevens hieronder te maken.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit zijn de daadwerkelijke DKIM-handtekeninggegevens
Deze drie onderdelen zijn het meest interessant voor de ontvangende server die de handtekening 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 zij 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 van, het domein in het d= gedeelte van de handtekening.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie leveren die nodig is om de ontvanger te helpen de handtekeningen te valideren.
Om te beginnen met ons begrip van DKIM, 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 sleutel-waarde paren, sommige interessanter voor de lezer dan andere, maar ik zal ze hier allemaal beschrijven.
Eerst kijken we naar de onderdelen die vooral van voorbijgaande interesse zijn voor de lezer:
v=1; – Geeft de DKIM-versie aan (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat wordt gebruikt om de cryptografische hashes te construeren
c=relaxed/relaxed; – Er zijn twee sets regels met betrekking tot het verwijderen van witruimte in de headers en body die kunnen worden toegepast bij het maken van hashes in een DKIM-handtekening; deze regels worden 'canonieke regels' genoemd (vandaar de sleutel c) en de regelsets zijn ofwel 'relaxed' of 'strict'.
t=1454417737; – Het tijdstempel van wanneer de handtekening is gemaakt.
Deze drie headeronderdelen bevatten de daadwerkelijke handtekeninginformatie:
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 zijn gebruikt om de handtekeninggegevens hieronder te maken.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit zijn de daadwerkelijke DKIM-handtekeninggegevens
Deze drie onderdelen zijn het meest interessant voor de ontvangende server die de handtekening 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 zij 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 van, het domein in het d= gedeelte van de handtekening.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie leveren die nodig is om de ontvanger te helpen de handtekeningen te valideren.
Om te beginnen met ons begrip van DKIM, 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 sleutel-waarde paren, sommige interessanter voor de lezer dan andere, maar ik zal ze hier allemaal beschrijven.
Eerst kijken we naar de onderdelen die vooral van voorbijgaande interesse zijn voor de lezer:
v=1; – Geeft de DKIM-versie aan (1 is de enige geldige waarde)
a=rsa-sha256; – Het algoritme dat wordt gebruikt om de cryptografische hashes te construeren
c=relaxed/relaxed; – Er zijn twee sets regels met betrekking tot het verwijderen van witruimte in de headers en body die kunnen worden toegepast bij het maken van hashes in een DKIM-handtekening; deze regels worden 'canonieke regels' genoemd (vandaar de sleutel c) en de regelsets zijn ofwel 'relaxed' of 'strict'.
t=1454417737; – Het tijdstempel van wanneer de handtekening is gemaakt.
Deze drie headeronderdelen bevatten de daadwerkelijke handtekeninginformatie:
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 zijn gebruikt om de handtekeninggegevens hieronder te maken.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dit zijn de daadwerkelijke DKIM-handtekeninggegevens
Deze drie onderdelen zijn het meest interessant voor de ontvangende server die de handtekening 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 zij 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 van, het domein in het d= gedeelte van de handtekening.
De reden dat deze onderdelen interessant zijn voor de ontvangende server is dat ze de informatie leveren die nodig is om de ontvanger te helpen de handtekeningen te valideren.
DKIM Validatie
Naast de vereiste die vermeldt dat het i= domein hetzelfde moet zijn als of een subdomein van het d= domein, worden de d= en s= bits gebruikt door de validator om de openbare DKIM-sleutel van de ondertekenaar op te zoeken in DNS. De sleutel is een TXT-record in DNS, en deze wordt altijd gevonden op de locatie selector._domainkey.domain. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de openbare DKIM-sleutel in DNS worden gevonden op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uitzien:
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 reeks hashes van het bericht te maken; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en dus kan het bericht bijdragen aan en mogelijk profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Naast de vereiste die vermeldt dat het i= domein hetzelfde moet zijn als of een subdomein van het d= domein, worden de d= en s= bits gebruikt door de validator om de openbare DKIM-sleutel van de ondertekenaar op te zoeken in DNS. De sleutel is een TXT-record in DNS, en deze wordt altijd gevonden op de locatie selector._domainkey.domain. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de openbare DKIM-sleutel in DNS worden gevonden op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uitzien:
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 reeks hashes van het bericht te maken; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en dus kan het bericht bijdragen aan en mogelijk profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Naast de vereiste die vermeldt dat het i= domein hetzelfde moet zijn als of een subdomein van het d= domein, worden de d= en s= bits gebruikt door de validator om de openbare DKIM-sleutel van de ondertekenaar op te zoeken in DNS. De sleutel is een TXT-record in DNS, en deze wordt altijd gevonden op de locatie selector._domainkey.domain. Dus, in ons voorbeeld hier, met s=notices en d=welcome.foo.com, zou de openbare DKIM-sleutel in DNS worden gevonden op notices._domainkey.welcome.foo.com, en het zou er ongeveer zo uitzien:
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 reeks hashes van het bericht te maken; als die hashes overeenkomen, is het bericht niet gewijzigd tijdens het transport, en dus kan het bericht bijdragen aan en mogelijk profiteren van, welke reputatie er ook is voor de ondertekenaar van het bericht.
Validatie Fout en Problemen oplossen
Ik heb hierboven vermeld dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben voor de hand liggende oorzaken, zoals dat het bericht niet is ondertekend, of dat de publieke sleutel van het ondertekeningsdomein niet is gevonden in DNS of niet syntactisch correct is, of misschien is het bericht duidelijk 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 degenen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht is ondertekend, de publieke sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator rapporteert dat de handtekening niet gevalideerd kon worden.
De reden dat deze moeilijk op te lossen zijn, is omdat er geen echte manier is voor beide partijen om de omstandigheden te reproduceren waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in de DKIM-Signature-header de hashes die door de ondertekenaar zijn gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan dus de handtekening niet onder dezelfde omstandigheden proberen te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en dus geen manier om het bericht op dezelfde manier te valideren zoals de validator dat deed.
Dergelijke fouten zoals ik hier beschrijf zijn zeldzame voorvallen, en DKIM-validatiefouten hebben op zichzelf meestal geen invloed op de plaatsing van levering. Terwijl DKIM berichtauthenticatie afhandelt, het implementeren van uitgebreide e-mailvalidatietechnieken 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 enig ander soort DKIM-probleem.
Ik heb hierboven vermeld dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben voor de hand liggende oorzaken, zoals dat het bericht niet is ondertekend, of dat de publieke sleutel van het ondertekeningsdomein niet is gevonden in DNS of niet syntactisch correct is, of misschien is het bericht duidelijk 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 degenen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht is ondertekend, de publieke sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator rapporteert dat de handtekening niet gevalideerd kon worden.
De reden dat deze moeilijk op te lossen zijn, is omdat er geen echte manier is voor beide partijen om de omstandigheden te reproduceren waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in de DKIM-Signature-header de hashes die door de ondertekenaar zijn gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan dus de handtekening niet onder dezelfde omstandigheden proberen te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en dus geen manier om het bericht op dezelfde manier te valideren zoals de validator dat deed.
Dergelijke fouten zoals ik hier beschrijf zijn zeldzame voorvallen, en DKIM-validatiefouten hebben op zichzelf meestal geen invloed op de plaatsing van levering. Terwijl DKIM berichtauthenticatie afhandelt, het implementeren van uitgebreide e-mailvalidatietechnieken 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 enig ander soort DKIM-probleem.
Ik heb hierboven vermeld dat DKIM-fouten moeilijk kunnen zijn om op te lossen, en ik zal hier uitleggen waarom dat zo is.
Sommige DKIM-validatiefouten hebben voor de hand liggende oorzaken, zoals dat het bericht niet is ondertekend, of dat de publieke sleutel van het ondertekeningsdomein niet is gevonden in DNS of niet syntactisch correct is, of misschien is het bericht duidelijk 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 degenen die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht is ondertekend, de publieke sleutel bestaat in DNS, en het bericht niet duidelijk is gewijzigd, maar de validator rapporteert dat de handtekening niet gevalideerd kon worden.
De reden dat deze moeilijk op te lossen zijn, is omdat er geen echte manier is voor beide partijen om de omstandigheden te reproduceren waaronder het bericht werd ondertekend en gevalideerd. Het bericht heeft in de DKIM-Signature-header de hashes die door de ondertekenaar zijn gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan dus de handtekening niet onder dezelfde omstandigheden proberen te reproduceren. Evenzo heeft de ondertekenaar waarschijnlijk geen toegang tot de infrastructuur van de validator en dus geen manier om het bericht op dezelfde manier te valideren zoals de validator dat deed.
Dergelijke fouten zoals ik hier beschrijf zijn zeldzame voorvallen, en DKIM-validatiefouten hebben op zichzelf meestal geen invloed op de plaatsing van levering. Terwijl DKIM berichtauthenticatie afhandelt, het implementeren van uitgebreide e-mailvalidatietechnieken 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 enig ander soort DKIM-probleem.
