Générateur DKIM

Il vous faut une paire de clés RSA. La moitié publique va dans le DNS en TXT sur selector._domainkey.votredomaine.com, la moitié privée dans le système qui envoie vos e-mails, qui s’en sert pour signer chaque message sortant. Le générateur ci-dessus crée la paire avec le Web Crypto intégré à votre navigateur : la clé privée est créée sur votre machine et n’est envoyée nulle part. L’alternative classique est openssl en ligne de commande, qui produit la même chose en plus d’étapes.

Non, et c’est l’heure perdue la plus courante de la mise en place DKIM. Google Workspace génère lui-même la clé DKIM dans la console d’administration et vous donne l’enregistrement public à publier. Microsoft 365 génère deux paires de clés quand vous activez DKIM pour un domaine personnalisé, garde les clés privées inaccessibles et vous fait publier des CNAME vers ses propres sélecteurs, pas un TXT que vous contrôlez. Aucun des deux n’accepte une clé importée. Une clé de ce générateur sert à un serveur ou une plateforme qui vous en demande une : Postfix avec OpenDKIM, une appliance ou votre propre application.

2048 bits. C’est la clé la plus robuste, celle que Google dit préférable quand le fournisseur DNS la prend en charge. 1024 bits sert de repli pour les panneaux qui ne peuvent pas stocker la valeur plus longue, et Microsoft 365 utilise encore 1024 par défaut, avec 2048 disponible à la rotation. Si vous devez commencer à 1024 à cause d’une limite DNS, voyez-le comme temporaire et passez à 2048 dès que le fournisseur accepte la valeur longue.

Un libellé qui permet à un domaine d’avoir plusieurs clés DKIM en même temps. Le sélecteur figure dans le nom d’hôte DNS (selector._domainkey.votredomaine.com) et dans la balise s= de chaque signature envoyée : les destinataires savent ainsi quelle clé publiée vérifier. Comme il fait partie de la requête, vous pouvez publier une nouvelle clé sous un nouveau sélecteur, y basculer votre système de signature et retirer l’ancienne sans trou dans les e-mails signés. C’est ce qui rend la rotation possible. Chaque service a en général son propre sélecteur.

La clé est produite par l’API Web Crypto, la même implémentation cryptographique que le navigateur utilise pour TLS, et ne passe jamais par le réseau : aucun appel d’API derrière cette page, rien n’est stocké. Elle n’est enregistrée nulle part non plus : fermer l’onglet la détruit. Ce que vous maîtrisez, c’est la suite. Placez la clé directement dans le coffre de secrets de votre serveur mail, et ne la collez jamais dans un ticket de support, un chat ou un document partagé. Si votre organisation exige des clés générées sur une machine durcie selon sa propre politique, utilisez openssl sur cette machine.

Une clé publique de 2048 bits s’encode en 400 caractères environ, et une chaîne DNS est limitée à 255. L’enregistrement n’a rien d’anormal ; il doit juste être stocké en plusieurs chaînes entre guillemets que le serveur DNS rassemble. La plupart des panneaux le font seuls quand vous collez la valeur entière. Quelques-uns vous demandent de la découper. Si un test DKIM signale la clé comme tronquée ou invalide après publication, ce découpage en est presque toujours la cause.

Faites-les tourner à un rythme que votre équipe tiendra vraiment, et tout de suite si une clé privée est exposée. Le mécanisme, c’est le sélecteur : publiez la nouvelle clé publique sous un nouveau sélecteur, attendez la propagation DNS, basculez la signature sur ce sélecteur, puis retirez l’ancien enregistrement quand plus rien n’est signé avec. Microsoft fait tourner ses propres clés quand DKIM est activé sur un domaine personnalisé. Pour vos propres clés, la rotation est manuelle, sauf si un outil l’automatise.

v=DKIM1 déclare la version. k=rsa nomme le type de clé. p= porte la clé publique elle-même, encodée en base64. Ces trois-là suffisent à un enregistrement qui marche. Deux balises facultatives se voient parfois : t=y marque la clé comme en test, ce qui demande aux destinataires de ne pas traiter durement les échecs, et h= limite les algorithmes de hachage utilisables avec la clé. Laissez-les de côté sauf raison précise.

Non. DKIM prouve qu’un message a été signé par une clé publiée pour un domaine et n’a pas été modifié en route. Il ne dit pas quoi faire en cas d’échec, et n’exige pas que le domaine signataire corresponde à l’adresse From affichée. DMARC ajoute les deux : l’alignement entre domaine signataire et domaine From visible, et une politique que les destinataires appliquent. Publiez DKIM, ajoutez SPF, puis fixez une politique DMARC.