DKIM : DomainKeys Identified Mail
Réseau
DKIM : DomainKeys Identified Mail, signature cryptographique des courriels par le domaine qui les envoie. « Le cachet de cire du courriel : il prouve d'où vient la lettre, jamais que son contenu soit honnête », par analogie avec le tampon de la mairie, qui authentifie avec la même conviction un acte de naissance et une convocation absurde.
Fonctionnement : Le serveur d'envoi signe certains en-têtes et le corps du message avec une clé privée, et ajoute un en-tête DKIM-Signature. Le destinataire récupère la clé publique dans un enregistrement DNS publié sous selecteur._domainkey.domaine et vérifie que rien n'a changé en route. La norme de référence est la RFC 6376, de 2011.
Algorithmes : Depuis la RFC 8301 (2018), la signature avec SHA-1 est interdite et les clés RSA doivent faire au moins 1024 bits, 2048 étant recommandés. La RFC 8463, la même année, a ajouté les signatures Ed25519.
Avec SPF et DMARC : SPF (Sender Policy Framework) liste les serveurs autorisés à envoyer pour un domaine, DKIM signe le message, et DMARC (Domain-based Message Authentication, Reporting and Conformance) exige qu'au moins l'un des deux réussisse en étant aligné sur l'adresse visible par le lecteur, puis indique quoi faire en cas d'échec. Pris isolément, chacun laisse une porte que l'autre ferme.
Limite : Un courriel piégé envoyé par l'application légitime elle-même, par exemple un lien de réinitialisation détourné par injection d'en-tête Host, est signé en bonne et due forme. DKIM certifie l'expéditeur ; il n'a jamais promis de relire.
Ce qui arrive si on s'en passe
Un domaine sans DKIM ni politique DMARC stricte peut être usurpé par n'importe qui pour envoyer de l'hameçonnage à ses clients, et ses messages légitimes finissent de plus en plus souvent dans les indésirables des grands fournisseurs de messagerie. Une clé DKIM trop courte, ou jamais renouvelée après une fuite, permet à quiconque la détient de signer au nom du domaine. Enfin, se fier au seul résultat « DKIM : pass » pour juger un message oublie qu'un serveur légitime signe aussi le contenu malveillant que lui fournit une application vulnérable.
Explication de la marmotte
Quand une entreprise envoie un courriel, son serveur peut y ajouter une signature invisible, fabriquée avec une clé secrète. Le destinataire vérifie cette signature grâce à une clé publique que l'entreprise publie sur internet. Si le message a été modifié ou s'il vient d'un imposteur, la signature ne correspond pas. Attention : la signature prouve seulement qui a envoyé le message, pas que son contenu est sans danger.
Où ce terme est utilisé
- Déployer DMARC de observation à reject (23 occurrences)
- Déployer SPF DKIM DMARC jusqu'à reject (18 occurrences)
- Détecter le contenu IA malveillant : limites (8 occurrences)
- Comment former contre le phishing sans culpabiliser (4 occurrences)
- Comment contrer le spear phishing et la fraude au président (2 occurrences)
- Fraude au président par voix clonée et visio truquée (2 occurrences)
- Mener une simulation de phishing interne éthique avec GoPhish (2 occurrences)
- Micro-formations de sensibilisation sécurité régulières (2 occurrences)
- Pourquoi le phishing fonctionne malgré la formation (2 occurrences)
- Quel rôle joue l’INCIBE espagnol en cybersécurité (2 occurrences)