Enregistrement DKIM : sélecteurs, rotation et diagnostic

Si les ouvertures baissent, ne revoyez pas seulement les objets : vérifiez aussi le DNS et votre enregistrement DKIM. Le suivi des ouvertures est incomplet; une baisse ne prouve pas un défaut d'authentification.

SPF vérifie l'autorisation d'une IP pour une identité SMTP; DKIM, DomainKeys Identified Mail, permet de valider une signature sur certaines données du message. Il ne garantit ni l'identité humaine affichée ni l'absence de toute modification. Depuis 2024, Google et Yahoo exigent DKIM pour les envois en nombre concernés par leurs règles. Un échec peut contribuer au rejet ou au spam, sans déterminer seul le placement.

Pour un fondateur, DKIM peut sembler une tâche de dix minutes, mais le délai varie. Pour un prestataire avec 500 domaines, il faut gérer sélecteurs, rotations et syntaxe DNS, même lorsqu'un problème survient à 9 heures du soir un vendredi.

Ce guide opérationnel explique le fonctionnement DNS de l'enregistrement DKIM, la limite de 255 octets par chaîne TXT et le diagnostic lorsque le statut du tableau de bord ne correspond pas à un envoi réel.

Qu'est-ce qu'un enregistrement DKIM ?

Un enregistrement DKIM publie une clé publique dans un TXT DNS, directement ou par une délégation prise en charge. Le récepteur vérifie une signature associée au domaine signataire et l'intégrité des données couvertes selon leur canonicalisation. Cela ne prouve pas seul l'autorisation de l'auteur affiché ni l'absence de contenu malveillant.

La recherche utilise selector._domainkey.yourdomain.com, où selector identifie la clé. Cet exemple est abrégé et ne peut pas être publié comme clé valide :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 indique la version, k=rsa le type de clé et p= contient la clé publique en base64. La clé privée reste dans l'infrastructure de signature et ne doit pas figurer dans le DNS. Le guide de création DKIM explique les champs et le processus complet.

Ce que signe DKIM et pourquoi cela compte

DKIM n'est pas seulement une case à cocher. Il lie une signature au domaine signataire et permet de vérifier les données couvertes, sans garantir l'identité humaine de l'expéditeur ni protéger chaque partie du message.

Le serveur doit signer From et peut sélectionner d'autres en-têtes, généralement Subject, Date, To et Message-ID, ainsi que le corps couvert. Il applique la canonicalisation et un hachage, généralement SHA-256, puis signe avec la clé privée. La signature voyage dans l'en-tête DKIM-Signature.

Lorsque Gmail, Outlook ou un autre serveur reçoit le message :

1. Il lit DKIM-Signature pour obtenir sélecteur et domaine signataire.
2. Il recherche la clé publique à selector._domainkey.yourdomain.com avec les valeurs de la signature.
3. Il vérifie cryptographiquement la signature avec la clé publique, sans déchiffrer le contenu du message.
4. Il recalcule les empreintes des données reçues selon les paramètres de signature.
5. Il vérifie leur correspondance et les autres conditions, pour obtenir DKIM pass ou un résultat d'échec.

Deux propriétés de cette validation sont l'authenticité de la signature par rapport à la clé du domaine signataire et l'intégrité des données couvertes dans les limites de la canonicalisation. Chaque octet du message entier n'a pas nécessairement à rester identique. La bonne clé publique rend la vérification possible. La spécification figure dans la RFC 6376, utile pour examiner conformité et limites.

Transfert : quand DKIM peut rester valide

Un dirigeant envoie une facture à un contact qui la transfère par alias vers Gmail. Si l'expéditeur d'enveloppe original reste inchangé et que la nouvelle IP n'est pas autorisée, SPF peut échouer. DMARC échoue seulement sans autre voie valide et alignée, notamment DKIM. Le traitement relève de la politique du récepteur, pas d'un rejet inévitable.

DKIM peut survivre au transfert si les données couvertes restent compatibles et si clé et autres conditions demeurent valides. Le récepteur final consulte le DNS du signataire original. Les modifications par des listes ou passerelles peuvent toutefois invalider la signature.

Associez DKIM à une configuration SPF adaptée; le guide SPF pour la messagerie expose les bases. DMARC requiert SPF validé et aligné ou une signature DKIM valide et alignée, pas obligatoirement les deux.

SRS, selon la configuration de transfert TrekMail, réécrit l'identité d'enveloppe pour permettre SPF sur le domaine de l'intermédiaire; il ne restaure pas l'alignement SPF avec le From original. Vérifiez aussi quelles sorties sont signées par TrekMail ou votre SMTP externe, sans présumer une couverture universelle par défaut.

Sélecteurs et gestion de plusieurs clés DKIM

Le sélecteur DKIM indique la clé publique à rechercher. Une valeur incorrecte peut provoquer des échecs, sans que ce guide fournisse une proportion mesurée de toutes les causes.

SPF autorise une politique applicable par nom, pas un seul TXT de toute nature. DKIM permet plusieurs sélecteurs, comme selector._domainkey.yourdomain.com, selon les capacités DNS et du service. Vous pouvez avoir dix sélecteurs actifs si nécessaire, par exemple un par fournisseur.

Pourquoi plusieurs sélecteurs

Avec Google Workspace et Mailchimp, des clés distinctes par service sont généralement plus pratiques et réduisent l'étendue d'une exposition. Partager une clé privée augmente les risques et n'est pas pris en charge partout. Chaque fournisseur utilise son sélecteur :

• Google Workspace : Peut utiliser google à google._domainkey.yourdomain.com; confirmez la valeur attribuée.
• Mailchimp : Peut indiquer k1 ou k2, par exemple à k1._domainkey.yourdomain.com. Suivez les instructions actuelles.
• TrekMail : Peut fournir tm1 à tm1._domainkey.yourdomain.com, avec TXT ou CNAME selon la configuration indiquée.

Des clés distinctes permettent de révoquer k1 en cas d'exposition du service marketing sans révoquer nécessairement la clé professionnelle. Vérifiez néanmoins messages en transit, dépendances et conséquences : les sélecteurs ne garantissent ni continuité ni isolation absolue de réputation. Le guide des sélecteurs explique leur syntaxe et l'identification des valeurs attribuées.

Une erreur classique de publication

Certains panneaux ajoutent automatiquement le domaine : vous souhaitez google._domainkey.yourdomain.com, mais créez google._domainkey.yourdomain.com.yourdomain.com. La recherche du nom attendu peut renvoyer NXDOMAIN malgré l'autre enregistrement. Comparez panneau, DNS et signatures réelles. La vérification du statut DNS explique le diagnostic avec une requête dig.

Longueur des clés et rotation

La clé contribue à la sécurité DKIM. Une configuration d'il y a cinq ans mérite une revue, mais l'âge ne prouve pas seul faiblesse ou compromission. Vérifiez algorithme, longueur, protection et exigences actuelles.

Les clés de 2048 bits

Les clés RSA de 1024 bits ont longtemps été utilisées. Google conserve ce minimum et recommande 2048 bits lorsque possible; vérifiez séparément les exigences actuelles Yahoo. Une installation cPanel ou Postfix qui utilisait 1024 bits avant 2019 mérite une revue et un plan d'évolution, sans conclure à un échec sur la seule date.

Une clé de 512 bits est inadaptée. Avec dkim=perm_fail pour clé faible ou politique, vérifiez la cause exacte. Générez une clé de 2048 bits si nécessaire, publiez un nouveau sélecteur avant de signer et gardez l'ancienne clé publique tant que des messages en transit doivent être validés. Consultez les directives Google pour les expéditeurs.

Fréquence de rotation

Une rotation annuelle est une politique opérationnelle possible, pas une obligation universelle DKIM. Si la clé privée est exposée par intrusion, gestion incorrecte des secrets ou accès excessif, réagissez selon l'incident : elle pourrait permettre des signatures tant qu'elle reste acceptée. N'attendez pas la dégradation de la réputation du domaine email.

Traitez la clé privée comme un secret sensible. La conserver cinq ans demande une politique justifiée et réévaluée, sans signifier automatiquement compromission. Sa protection et la réponse aux incidents comptent autant que le calendrier.

La limite DNS de 255 octets et sa gestion

Avec des clés de 2048 bits, une valeur publique de 2048 bits en base64 peut avoisiner 400 caractères selon son encodage. Chaque chaîne TXT accepte 255 octets. Les interfaces peuvent découper, refuser ou traiter autrement les valeurs longues; la troncature silencieuse n'est pas universelle.

Une clé longue peut occuper plusieurs chaînes entre guillemets dans un seul TXT. La RFC 6376 prévoit leur concaténation sans ajout d'espace avant l'interprétation de la clé.

Exemple abrégé d'une chaîne longue, non publiable comme clé complète :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

Exemple de structure avec deux chaînes concaténées; remplacez le contenu abrégé :

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

La saisie dépend du DNS. Certains acceptent la notation de fichier de zone avec parenthèses; d'autres gèrent les chaînes dans le panneau. Ne créez pas plusieurs TXT indépendants. Consultez la configuration DNS chez les fournisseurs courants pour Cloudflare, Route 53, GoDaddy et autres.

Une délégation CNAME prise en charge par TrekMail peut éviter la gestion locale du TXT long : vous publiez l'alias court, inférieur à 255 caractères dans cet exemple, et le fournisseur gère la cible. Vérifiez valeurs exactes, clés par domaine et stratégie des sélecteurs. Un CNAME ne coexiste pas avec un TXT au même nom; un alias stable ne garantit pas une rotation transparente.

Vérification de la configuration

Ne vous fiez pas uniquement à « Vérifié ». Un tableau de bord peut présenter des données d'il y a des heures ou des jours. Combinez DNS faisant autorité, résolveurs pertinents et essais de signature; une seule requête ne confirme pas tout le processus.

Étape 1 : vérifier le nom DNS

Sur Linux ou macOS, utilisez le terminal. Sur Windows, ouvrez la console et utilisez nslookup :

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Remplacez selector par celui de l'envoi et yourdomain.com par votre domaine.

v=DKIM1 peut indiquer la version, mais son absence n'invalide pas automatiquement la clé si la valeur par défaut s'applique. NXDOMAIN n'est pas attendu : NXDOMAIN signifie que le nom n'existe pas dans cette réponse. Vérifiez nom, publication et caches. Attendre 30 minutes est une suggestion indicative, pas un délai de propagation garanti.

Étape 2 : valider le contenu de la clé

Si le nom existe mais les échecs persistent, examinez la valeur :

dig txt selector._domainkey.yourdomain.com +short

Vérifiez deux points :

• Troncature : Une chaîne base64 de moins de 200 caractères pour une clé RSA attendue de 2048 bits peut indiquer une valeur incomplète. La longueur est un indice, pas une preuve; concaténez les chaînes et validez la clé.
• Caractères modifiés : Examinez la chaîne base64, retours, espaces et échappements selon le format TXT et l'interprétation DKIM. Certains espaces permis ne changent pas la clé, tandis que d'autres erreurs invalident l'encodage. Comparez la valeur interprétée à la clé publique fournie.

Étape 3 : envoyer et lire les en-têtes

Envoyez vers un Gmail que vous contrôlez, ouvrez le menu à trois points puis « Afficher l'original ». Cherchez Authentication-Results ajouté par le serveur récepteur de confiance, pas par un expéditeur arbitraire :

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass confirme cette vérification. Si vous attendiez une signature valide et voyez fail, neutral, perm_fail ou temperror, examinez le motif complet; les noms peuvent dépendre de l'implémentation et neutral n'est pas toujours une erreur. Le guide de configuration DKIM décrit le processus; la liste de première configuration complète les étapes d'authentification.

Échecs DKIM : trois scénarios

La bonne clé peut exister dans le DNS sans que la signature soit validée. Vérifiez signature, données reçues et parcours entier; « cela devrait marcher » ne suffit pas.

Le guide de diagnostic DKIM détaille les résultats et motifs. Ces trois scénarios sont des exemples pratiques, pas un classement mesuré des causes les plus fréquentes.

Scénario 1 : empreinte du corps non validée

Un échec d'empreinte du corps peut affecter la délivrabilité email. Le résumé calculé ne correspond pas à celui déclaré, du fait de changements incompatibles des données couvertes ou d'autres problèmes de traitement. Cela ne prouve pas que la signature des en-têtes soit cryptographiquement valide.

Causes possibles :

• Avis d'expéditeur externe : Une passerelle ajoute « EMAIL EXTERNE - ATTENTION » avant de vérifier DKIM. Cela peut invalider le corps signé. Examinez ordre de vérification et modification, notamment dans Microsoft 365 avec règles de flux.
• Mentions légales : Une passerelle ajoute un pied de page de 15 lignes après signature, ce qui peut changer l'empreinte. Signez la version finale sous votre contrôle, après examen de la couverture.
• Réécriture des URL : Mimecast, Proofpoint ou Defender for Office 365 peuvent transformer google.com en protect.mimecast.com/s/.... Les changements incompatibles avec canonicalisation et couverture peuvent invalider l'empreinte; toute modification d'octets n'a pas nécessairement cet effet.

À la sortie, signez après vos dernières modifications. À la réception, vérifiez avant de modifier et préservez les résultats fiables. Signer en fin de passerelle n'empêche pas les changements ultérieurs chez d'autres acteurs. Confirmez les parcours et l'ordre applicables dans TrekMail; consultez le diagnostic des erreurs d'envoi.

Scénario 2 : défaut d'alignement

Vous pouvez trouver ce résultat dans les en-têtes :

dkim=pass (signature was valid)

DKIM passe, mais DMARC peut échouer faute d'alignement DKIM, sans autre voie valide et alignée. Le placement dépend ensuite du récepteur.

DMARC compare le domaine d= d'une signature valide au Header From. Le mode strict exige l'identité exacte; le mode relâché permet le même domaine organisationnel. Toute signature valide et alignée peut fournir cette voie.

Exemple illustratif :

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

La signature est valide pour sendgrid.net. La politique DMARC du domaine de l'auteur s'évalue par rapport à yourcompany.com : sendgrid.net != yourcompany.com. Cette signature n'est pas alignée, mais SPF validé et aligné ou une autre signature DKIM alignée peut encore faire passer DMARC.

Le fournisseur peut proposer authentification de domaine ou signature personnalisée. Configurez une clé DKIM pour votre domaine selon ses instructions, afin que d= utilise yourcompany.com plutôt que sendgrid.net lorsque pertinent. Prise en charge et publication TXT ou CNAME varient. Comprenez l'alignement DMARC avant de modifier les flux de production.

Scénario 3 : clés faibles ou refusées

dkim=perm_fail pour politique ou clé faible demande d'examiner la clé réelle. Les clés de 512 ou 768 bits sont inadaptées aux exigences actuelles pertinentes, mais le motif ne prouve pas seul cette longueur. Un échec permanent d'authentification ne signifie pas que le message entier soit irrécupérable ou qu'aucune autre signature ne soit valide.

Préparez une nouvelle paire de 2048 bits avec un autre sélecteur : publiez, vérifiez, changez la signature et conservez l'ancienne clé publique tant que nécessaire. En cas de compromission, adaptez la révocation à l'incident. Ne supprimez pas d'abord l'unique clé active. Consultez les conseils de génération locale et le guide des générateurs DKIM.

Générateurs de clés et précautions

Il faut une paire de clés pour DKIM. Si un générateur web affiche la clé privée, examinez où elle est créée et qui peut y accéder avant toute utilisation en production.

L'affichage dans un navigateur ne prouve pas par définition une compromission : la génération peut être locale. Mais un service distant ou du code non fiable peut connaître ou exposer la clé. Une personne qui l'obtient pourrait signer tant qu'elle reste acceptée, pas nécessairement pour toujours. Préférez un environnement local contrôlé ou un fournisseur de confiance.

Comparer les méthodes

Pour votre propre serveur, vous pouvez générer localement avec OpenSSL après protection des accès et permissions :

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

La clé privée ne doit pas être transmise sans besoin autorisé et canal sécurisé. Le DNS reçoit la clé publique au format adapté : cat affiche seulement le PEM, sans supprimer ses en-têtes ni convertir automatiquement la valeur pour DNS. Refusez une demande d'envoi de la clé privée par email pour « vérification ».

Fondateurs et agences peuvent déléguer la génération à un fournisseur fiable si le service la propose. Confirmez protection, rotation, révocation et périmètre plutôt que supposer des contrôles identiques chez tous.

Gestion manuelle ou automatisée

La rotation révèle le travail opérationnel de DKIM. Revoyez régulièrement chaque clé et ses dépendances. Cet exemple annuel compare les processus, sans imposer un calendrier universel.

Exemple de rotation manuelle annuelle par domaine

1. Générez une paire RSA avec un nouveau sélecteur, par exemple s2026.
2. Publiez la clé publique à s2026._domainkey.yourdomain.com.
3. L'exemple réserve 48 heures; vérifiez publication et caches sans supposer un délai universel.
4. Après validation seulement, configurez la sortie avec la nouvelle clé privée.
5. L'exemple garde les deux clés publiques 7 jours; adaptez le chevauchement aux files et messages encore vérifiables.
6. Retirez l'ancien sélecteur lorsqu'il n'est plus nécessaire, selon la politique d'incident.
7. Détruisez la clé privée retirée lorsqu'elle ne doit plus être conservée, avec les copies concernées.

Cela représente 7 étapes par domaine : avec 50 domaines, 350 opérations avant tests supplémentaires. Omettre l'étape 5 peut affecter des messages en transit; oublier la 6 peut maintenir une clé publique inutile. Publier la clé publique n'expose pas en soi la clé privée. Le processus peut être automatisé avec des contrôles.

Pour un seul domaine, le travail manuel peut rester raisonnable. Avec 50, automatisation et journal des changements aident à éviter les oublis, sans garantir l'absence d'un diagnostic un vendredi.

Le rôle de TrekMail dans la gestion DKIM

TrekMail s'adresse à la gestion multidomaine, d'un fondateur avec cinq projets à un prestataire avec 800 domaines clients. Vérifiez que l'implémentation disponible couvre vos parcours et besoins.

Délégation CNAME et rotation

L'assistant peut indiquer un CNAME lors de l'ajout d'un domaine. Cet exemple du texte n'est pas une cible à réutiliser sans validation :

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Une délégation stable permet au fournisseur de gérer le TXT cible. Remplacer une clé sous le même sélecteur peut invalider des signatures anciennes ou en transit et implique les caches. Confirmez une rotation coordonnée avec chevauchement et nouveaux sélecteurs lorsque nécessaire, sans présumer l'absence d'interruption. Un portefeuille de 80 domaines demande encore des contrôles même si les éditions DNS diminuent.

L'exemple de Pro à $8 par mois pour 100 domaines estime 700 opérations manuelles évitées par an. C'est une comparaison illustrative, pas un prix actuel vérifié ni une économie garantie; tests et contrôles demeurent nécessaires.

Assistant DNS

L'assistant TrekMail peut réunir recommandations MX, SPF, DKIM et DMARC et vérifications disponibles. Tout résolveur peut avoir un cache : confirmez résultats, inventaire et envois réels avant de vous fier à un statut vérifié. Consultez les enregistrements DNS requis.

Modèle sans tarif par utilisateur

Le modèle décrit facture la plateforme dans les limites des plans. Le texte cite Starter à $3.50 par mois avec 50 domaines et 100 utilisateurs par domaine, Pro à $8 par mois avec 100 domaines et 300 utilisateurs par domaine, puis Agency à 1,000+ domaines. Vérifiez prix, stockage mutualisé, signature DKIM et limites actuelles; ajouter des comptes ne garantit pas un coût indéfiniment inchangé.

La configuration DNS et DKIM dépend des parcours et fonctions du plan. Vérifiez disponibilité et responsabilités, sans supposer toute authentification gérée par défaut quel que soit le transport.

Comparaison de gestion DKIM

Conclusion

Un enregistrement DKIM correct est important pour l'authentification en 2025 et après, notamment pour les envois soumis aux exigences des fournisseurs. Son absence ne provoque pas toujours un échec DMARC, car SPF valide et aligné peut offrir une autre voie, mais réduit la vérification des signatures et peut affecter le traitement.

Commencez par une clé RSA de 2048 bits lorsque approprié, le bon sélecteur, un TXT correctement concaténé et l'alignement sur From. Définissez ensuite rotation, révocation et politique DMARC avec inventaire et tests, complétés par Google Postmaster Tools lorsque des données sont disponibles.

La comparaison SPF, DKIM et DMARC explique leurs relations et l'ordre de préparation. En cas de problème de placement, le guide pour éviter les emails dans le spam aide à prioriser selon les preuves.

Avec plusieurs domaines, documentez et automatisez lorsque utile : une clé incomplète ou une signature non alignée peut affecter les flux concernés. La délégation CNAME TrekMail peut réduire le travail, pas supprimer toutes les causes d'échec. Consultez les plans et vérifiez l'offre gratuite décrite pour 10 domaines sans carte bancaire et ses conditions actuelles.