Générateur de clés DKIM : DNS, signature et vérification

Si vous cherchez un générateur de clés DKIM, votre domaine ne signe peut-être pas encore ses messages, ou ses signatures ne sont pas validées. Les messages non authentifiés risquent davantage d'être filtrés. Un échec DKIM peut affecter DMARC, mais un résultat SPF valide et aligné peut encore suffire. Les réinitialisations de mot de passe, factures et messages commerciaux peuvent alors arriver dans les indésirables ou en quarantaine.

La mise en place est souvent plus simple qu'il n'y paraît. Un générateur de clés DKIM crée une clé privée pour le système d'envoi et la clé publique correspondante, à publier dans le DNS. Le destinataire vérifie la signature du domaine signataire et l'intégrité des parties signées selon la canonicalisation utilisée. Cela ne prouve pas, à lui seul, l'identité de l'expéditeur affiché.

Pour préparer toute votre infrastructure, commencez par notre guide sur la messagerie professionnelle. Si vous utilisez déjà votre domaine, ce guide explique le résultat attendu d'un générateur de clés DKIM, la taille des clés, les sélecteurs et la publication DNS avec moins de risques de configuration.

Le rôle réel d'un générateur de clés DKIM

Un générateur de clés DKIM crée une paire de clés cryptographiques. La clé privée reste sur le système d'envoi et signe les messages sortants. La clé publique est publiée dans le DNS sous un sélecteur, afin que les destinataires puissent vérifier la signature DKIM des en-têtes.

Il ne s'agit pas d'une opération mystérieuse. Un bon générateur de clés DKIM remplit trois fonctions :

1. Créer une clé privée utilisable par le système d'envoi.
2. Extraire la clé publique correspondante.
3. Présenter cette clé publique sous forme d'enregistrement TXT à publier sous selector._domainkey.example.com.

La difficulté tient moins au calcul cryptographique qu'à la cohérence entre le sélecteur, le nom DNS, les retours à la ligne et la configuration d'envoi, pour que la signature soit validée en production.

La RFC 6376 prévoit des sélecteurs pour publier plusieurs clés et organiser leur rotation. Selon la RFC 8301, les signataires doivent utiliser des clés RSA d'au moins 1024 bits ; des clés de 2048 bits constituent généralement un choix plus approprié. Si un générateur de clés DKIM recommande encore 512 bits ou SHA-1, mieux vaut choisir un autre outil.

Le résultat attendu

Un générateur de clés DKIM doit fournir une clé privée pour signer et un enregistrement de clé publique compatible avec le DNS. Cet enregistrement se trouve sous le nom du sélecteur, pas à la racine du domaine, et contient la clé publique dans le champ p=.

Voici sa forme générale :

Host: tm2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Vous pouvez aussi créer la paire localement avec OpenSSL plutôt que confier une clé privée à un générateur de clés DKIM en ligne. Attention : la dernière commande affiche des éléments privés ; ne partagez pas sa sortie.

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
openssl rsa -in dkim-private.pem -text -noout

Convertissez ensuite la clé publique en une valeur sur une seule ligne, acceptée par la plupart des interfaces DNS :

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' dkim-public.pem \
| sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//g'

Le découpage d'une longue valeur TXT en segments entre guillemets peut être correct s'ils appartiennent au même enregistrement. Des espaces insérés au milieu de la clé peuvent, en revanche, l'invalider et ralentir le diagnostic.

Le sélecteur est l'étiquette de la clé, pas la clé elle-même. Avec s=tm2026 dans la signature, le destinataire interroge tm2026._domainkey.yourdomain.com. Si cet enregistrement n'existe pas, la signature DKIM ne peut pas être validée.

Choisir le sélecteur et la taille de clé

Choisissez un générateur de clés DKIM capable de produire une clé de 2048 bits et des sélecteurs adaptés à la rotation. Le système d'envoi doit être configuré pour signer avec RSA et SHA-256 ; la génération de la clé ne sélectionne pas automatiquement cet algorithme. Traitez les sélecteurs comme des étiquettes de version opérationnelles.

Utilisez des noms qui indiquent où et quand la clé sert. Par exemple :

• tm2026
• app1q1
• marketing2026

Noms moins pratiques :

• default conservé indéfiniment
• test en production
• dkim réutilisé pour tous les expéditeurs

La RFC 8301 impose au moins 1024 bits et recommande 2048 bits. Les consignes de Google pour les expéditeurs en masse demandent DKIM et SPF, avec au moins l'un des deux aligné sur le domaine From pour les messages directs vers des comptes Gmail personnels. Consultez la FAQ des consignes pour les expéditeurs pour connaître les exigences applicables.

Pour choisir un générateur de clés DKIM, vérifiez qu'il facilite les clés de 2048 bits, des noms de sélecteur explicites et la rotation. Ces critères comptent davantage que la simple capacité à créer une clé.

Publier l'enregistrement DNS en limitant les risques

Un générateur de clés DKIM ne fait qu'une partie du travail. Il faut publier le TXT au nom exact utilisé par l'expéditeur, tenir compte des caches DNS, puis activer la signature après avoir vérifié que la clé publique est accessible.

Les erreurs fréquentes sont les suivantes :

1. Publier le TXT sous @ au lieu de selector._domainkey.
2. Coller les délimitations PEM dans le DNS au lieu de la seule clé base64.
3. Activer la signature avant que le DNS réponde correctement.
4. Utiliser un autre sélecteur dans la plateforme de messagerie.

Pour un domaine TrekMail, suivez les enregistrements indiqués par le parcours DNS de votre mode d'envoi. La documentation Ajouter un domaine explique la valeur TXT DKIM. Avec votre propre SMTP, le sélecteur et la clé doivent provenir du prestataire qui envoie réellement. Après l'enregistrement, utilisez la vérification disponible ; en cas de problème, consultez le contrôle de l'état DNS.

Lors d'un transfert, un échec SPF n'empêche pas nécessairement DMARC de réussir si DKIM est valide et aligné. DKIM peut rester valide tant que les données signées ne sont pas modifiées. SPF peut échouer parce que le serveur d'envoi a changé. Le guide transférer les messages d'un domaine vers Gmail détaille ce cas.

Vérifier que la clé DKIM fonctionne réellement

Après avoir utilisé un générateur de clés DKIM et publié le TXT, examinez les en-têtes de vrais messages. Une réponse DNS correcte ne prouve pas que l'expéditeur signe. Recherchez dkim=pass et vérifiez l'alignement nécessaire à DMARC pour les messages effectivement envoyés.

Envoyez un message vers Gmail et affichez les en-têtes d'origine. Vous pourriez obtenir :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tm2026 header.b=...
       spf=pass smtp.mailfrom=example.com
       dmarc=pass header.from=example.com

En cas d'échec DKIM, procédez dans cet ordre :

1. Vérifiez le sélecteur s= dans l'en-tête DKIM-Signature.
2. Interrogez exactement ce nom DNS avec dig.
3. Vérifiez que la clé publique DNS correspond à la clé privée chargée sur l'expéditeur.
4. Vérifiez le domaine de signature configuré dans d=.
5. Cherchez si une liste de diffusion, un pied ajouté ou un relais a modifié les en-têtes ou le corps signés.

dig +short TXT tm2026._domainkey.example.com

Un générateur de clés DKIM qui omet le nom DNS, les contrôles ou l'alignement laisse une configuration incomplète. Même avec une clé publiée, DKIM n'apporte pas d'alignement DMARC si le domaine d= ne s'aligne pas sur le From visible : le mode souple accepte un domaine organisationnel commun, tandis que le mode strict exige une correspondance exacte.

Pour compléter votre diagnostic, consultez les guides créer une adresse avec son domaine, transfert de messages et la documentation TrekMail sur les messages classés comme indésirables.

Outils dispersés ou parcours coordonné

Associer un générateur de clés DKIM isolé, un panneau DNS, un prestataire SMTP pour les applications et un autre pour les newsletters demande de la coordination. Une politique DMARC incomplète peut laisser des problèmes inaperçus jusqu'à un changement de prestataire, une rotation ratée ou un transfert révélant une mauvaise authentification.

Un parcours coordonné permet de gérer le domaine, les boîtes, les contrôles DNS et les réglages d'envoi dans une même plateforme, tout en tenant compte des services externes.

Selon l'offre et la configuration de TrekMail, cela peut inclure :

• Domaines personnalisés et boîtes IMAP dans une interface.
• Votre propre SMTP avec Nano, ou un SMTP géré dans les offres payantes qui le prévoient.
• Importation des anciens messages par IMAP lorsque la source est compatible.
• Catch-all, transfert des boîtes et accès API selon l'offre.
• Un parcours DNS et d'authentification pour SPF, DKIM et DMARC.

Cette coordination compte particulièrement pour plusieurs domaines. Une authentification mal réglée alourdit le travail, en plus des licences par utilisateur. À titre indicatif, Starter est annoncé à partir de $3.50 par mois et l'offre gratuite à $0 prévoit jusqu'à 10 domaines et 5GB avec votre propre SMTP, selon les conditions en vigueur. Les offres payantes peuvent proposer un essai de 14 jours nécessitant une carte bancaire ; Nano est proposé sans cette exigence. Vérifiez les conditions avant de souscrire.

Pour déplacer les anciens messages pendant la remise en état de l'authentification, le parcours de migration IMAP peut importer depuis Gmail, Microsoft 365 ou un autre service IMAP compatible vers TrekMail, selon les autorisations et la configuration de la source.

Rotation, révocation et entretien

Un générateur de clés DKIM sert aussi à l'entretien de la configuration. Planifiez les rotations, retirez les anciens sélecteurs avec précaution et séparez ceux des différents expéditeurs lorsque cela facilite le diagnostic et réduit l'impact d'une exposition.

Voici une démarche pratique :

1. Générer une nouvelle clé de 2048 bits avec un nouveau sélecteur.
2. Publier la nouvelle clé publique dans le DNS.
3. Configurer l'expéditeur pour signer avec ce sélecteur.
4. Vérifier que les nouveaux messages affichent dkim=pass.
5. Conserver l'ancien sélecteur tant que des messages en file d'attente peuvent encore nécessiter une validation.
6. Retirer l'ancienne clé publique après une période de transition adaptée.

Si une clé privée est exposée, remplacez-la et examinez la révocation nécessaire. Des sélecteurs versionnés facilitent cette intervention, contrairement à default conservé indéfiniment.

Un générateur de clés DKIM ne corrige pas de mauvaises pratiques d'envoi. L'authentification est importante, mais la réputation compte aussi. Les consignes Google pour les expéditeurs en masse prévoient le contrôle des signalements de spam, SPF, DKIM et DMARC. TrekMail recommande notamment de vérifier le DNS, d'augmenter progressivement les volumes lorsque c'est pertinent et d'éviter les campagnes massives non sollicitées.

Conclusion : la clé n'est que le point de départ

Un générateur de clés DKIM lance le processus. L'objectif est un sélecteur correct, une clé publique publiée, la clé privée correspondante chez l'expéditeur et de vrais messages avec dkim=pass et alignement DMARC.

Créez une clé de 2048 bits, choisissez un sélecteur versionné, publiez correctement le TXT et vérifiez de vrais en-têtes. Si vous gérez plusieurs domaines et prestataires, un parcours coordonné peut simplifier l'exploitation. Selon l'offre, TrekMail propose domaines personnalisés, boîtes IMAP, stockage mutualisé, migration IMAP et configuration DNS d'authentification sans facturation par utilisateur. Consultez l'offre gratuite sur trekmail.net ou comparez les conditions sur trekmail.net/pricing.