DKIM-validatie: een beste praktijk voor e-mailauthenticatie
·
8 apr 2017
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:
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.
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.
“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 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.
De DKIM-Signature Header
DKIM Validation
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.
