Configurer DKIM pour un domaine personnalisé

Une configuration DKIM correcte est essentielle pour authentifier les messages d’un domaine personnalisé et favoriser leur livraison. Une clé absente, endommagée ou tronquée, ou une signature utilisant le mauvais domaine, peut nuire au placement en boîte de réception. Ce guide présente la procédure opérationnelle : générer la clé, publier le registre DNS, le vérifier en ligne de commande et détecter les erreurs d’alignement qui peuvent encore faire échouer DMARC après un contrôle favorable dans le tableau de bord.

Pour une configuration complète avec MX, SPF, boîtes et clients de messagerie, commencez par créer une adresse e-mail avec votre domaine. Si vous choisissez d’abord une plateforme, la messagerie professionnelle présente la décision générale.

Le problème est simple. La plupart des échecs DKIM ne viennent pas de la cryptographie, mais d’erreurs de copie DNS, de panneaux ajoutant deux fois le domaine, de clés de 2048 bits mal copiées ou d’un prestataire d’envoi signant avec son domaine plutôt que le vôtre. Vous pouvez perdre des heures sur une fausse piste. Une procédure reproductible est la solution.

Ce que fait réellement DKIM

Configurer DKIM consiste à publier une clé publique dans le DNS et à permettre au serveur de signer chaque message avec la clé privée correspondante. Les destinataires vérifient la signature, établissent la responsabilité du domaine signataire et détectent les modifications des en-têtes signés ou du corps pendant le transport.

DKIM utilise la cryptographie asymétrique. Votre système d’envoi conserve la clé privée ; le DNS publie la clé publique. À la sortie du serveur, le message reçoit un en-tête DKIM-Signature avec un domaine signataire (d=) et un sélecteur (s=). Le destinataire recherche ce sélecteur dans le DNS et valide la signature par rapport au contenu. Ce mécanisme est défini dans le RFC 6376.

Depuis février 2024, Google a renforcé les exigences pour les expéditeurs en nombre. Il indique qu’ils doivent configurer SPF et DKIM, et qu’au moins l’un doit s’aligner sur le domaine From visible pour réussir l’alignement DMARC. Consultez le texte actuel dans la FAQ des consignes Google pour les expéditeurs.

Une signature techniquement valide n’est donc pas forcément utile à l’objectif visé. Une configuration DKIM incorrecte ou non alignée peut laisser des problèmes de spam, de DMARC, ou les deux.

Avant de modifier le DNS

Une bonne configuration commence par identifier qui signe réellement vos messages. Cela paraît évident, mais c’est souvent là que les migrations, changements de transfert ou de fournisseur perturbent les envois. Le bon endroit pour générer ou obtenir des enregistrements DKIM dépend entièrement du chemin d’envoi.

Première question : qui envoie les messages sortants de ce domaine ?

1. Si Google Workspace les envoie, générez la clé DKIM dans Google Admin.
2. Si Microsoft 365 les envoie, activez DKIM dans ce service.
3. Si SendGrid, Mailgun ou Amazon SES les envoie, authentifiez le domaine chez ce prestataire.
4. Si TrekMail Managed SMTP les envoie, utilisez les valeurs DKIM affichées par TrekMail.
5. Si TrekMail gère les boîtes mais que vous utilisez un SMTP externe, suivez les consignes de signature de ce fournisseur, puis configurez SMTP dans TrekMail si nécessaire.

TrekMail prévoit les deux chemins selon le forfait. Nano utilise BYO SMTP ; les forfaits payants peuvent utiliser le SMTP géré. La documentation Bring Your Own SMTP présente des exemples SES, SendGrid et Mailgun. Le dépannage de délivrabilité précise aussi que Managed SMTP signe avec la clé DKIM de votre domaine, ce qui peut aider DMARC lors des transferts et relais si la signature reste valide et alignée.

Exemple : votre boîte est dans TrekMail, mais les messages sortants passent par SendGrid. SendGrid doit signer. TrekMail peut héberger la boîte, mais ne configure pas automatiquement le DKIM de SendGrid à votre place.

Première règle : générez les clés dans le système qui signe le message. Ailleurs, un registre peut exister dans le DNS sans avoir le moindre effet.

Types de registre DKIM : TXT ou CNAME

La configuration consiste généralement à publier un TXT contenant la clé publique. Certains prestataires demandent plutôt un ou plusieurs CNAME pointant vers des clés qu’ils hébergent. Les deux méthodes fonctionnent. L’essentiel est d’utiliser exactement les valeurs fournies par l’expéditeur.

La configuration classique utilise un TXT à cette adresse :

selector._domainkey.example.com

Sa valeur ressemble à ceci :

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

Les services gérés utilisent souvent CNAME pour effectuer la rotation des clés sans vous demander de modifier le DNS. TXT donne un contrôle direct, mais vous impose aussi d’actualiser le registre lors d’une rotation.

Le piège est le champ du nom d’hôte. Si le domaine est example.com et le sélecteur k1, on saisit généralement :

k1._domainkey

Pas ceci :

k1._domainkey.example.com

Beaucoup de panneaux DNS ajoutent automatiquement le domaine racine. En saisissant le nom complet dans ce type de panneau, vous publiez k1._domainkey.example.com.example.com. Le registre ne se trouve alors pas à l’emplacement attendu par les destinataires.

Pour la couche DNS requise par TrekMail, consultez les enregistrements DNS requis. La documentation précise aussi que certains fournisseurs demandent de diviser les TXT DKIM en parties entre guillemets.

Configurer DKIM étape par étape dans le DNS

La procédure est courte : obtenir le sélecteur, publier le registre, attendre l’actualisation DNS, vérifier la réponse exacte, puis activer la signature si le fournisseur exige un dernier réglage. Sans vérification, vous ne faites qu’une supposition.

Suivez cette procédure.

1. Ouvrez le prestataire d’envoi et générez ou affichez le registre DKIM.
2. Copiez exactement le sélecteur. Ne le renommez que si le prestataire l’autorise.
3. Créez le registre DNS à selector._domainkey.
4. Collez le TXT complet ou la cible CNAME tels qu’ils sont fournis.
5. Réglez le TTL sur 3600, sauf raison particulière.
6. Attendez la propagation.
7. Vérifiez avec dig ou nslookup avant les envois en production.
8. Activez la signature chez le prestataire si un bouton final d’activation existe.

Exemple avec TXT :

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Exemple avec CNAME :

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

La propagation DNS peut être rapide, mais n’est pas instantanée. Le guide TrekMail indique que beaucoup de mises à jour apparaissent en environ 5 à 15 minutes ; le délai peut varier selon le TTL et les caches. Si le statut ne change pas, vérifiez le format, les doublons et le nom d’hôte, sans exclure un cache encore valide.

DKIM et le problème des clés de 2048 bits

Une configuration moderne devrait utiliser des clés RSA de 2048 bits quand le prestataire et l’hébergeur DNS les prennent en charge. Elles sont plus robustes, mais aussi plus longues, ce qui peut poser problème aux anciens panneaux. Une clé tronquée est trompeuse : elle paraît présente alors que la vérification échoue.

Google recommande les clés de 2048 bits lorsqu’elles sont prises en charge, avec 1024 bits comme solution de repli pour les hébergeurs ne gérant pas les longs registres. Le problème pratique vient souvent du panneau d’administration, pas du DNS lui-même.

Une configuration DKIM de 2048 bits défectueuse ressemble généralement à l’un de ces cas :

1. Le panneau tronque silencieusement la valeur.
2. Il exige des fragments entre guillemets sans l’expliquer.
3. Il insère des retours à la ligne dans la clé base64.
4. Il échappe les caractères d’une façon inattendue par le prestataire.

Si l’hébergeur exige des chaînes séparées, publiez ainsi :

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

Le destinataire concatène les parties entre guillemets. C’est normal. Ajouter des espaces dans la clé ne l’est pas : un caractère supplémentaire peut invalider la configuration.

Avec de nombreux domaines, le coût opérationnel apparaît ici. Un bureau d’enregistrement gère correctement les longs TXT ; un autre non ; un troisième les réécrit. Les agences finissent donc souvent par réduire le nombre de prestataires ou choisir des signatures CNAME hébergées par le fournisseur, lorsque c’est possible. Pour plusieurs clients, l’hébergement de messagerie multidomaine décrit le modèle global.

Vérifier que DKIM fonctionne réellement

Un tableau de bord affichant « actif » ne suffit pas. Une vraie vérification interroge directement le DNS public, examine le registre retourné, puis confirme dans les en-têtes de messages réels le domaine signataire et le sélecteur attendus. Le reste n’est qu’un contrôle partiel.

Commencez en ligne de commande.

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

Vous devez voir le registre v=DKIM1 complet ou les fragments entre guillemets formant la clé complète. Si le résultat est vide, vérifiez dans cet ordre :

1. Le sélecteur est correct.
2. Le domaine n’est pas doublé dans le nom d’hôte.
3. Le type de registre correspond à la demande du fournisseur.
4. La valeur est complète et non tronquée.
5. L’ancien registre n’est plus en cache.

Envoyez ensuite un test vers Gmail ou une autre boîte permettant d’inspecter les en-têtes. Recherchez les résultats d’authentification et la ligne de signature DKIM.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

Si le DNS semble correct mais que les messages arrivent encore dans les indésirables, examinez les autres facteurs. Le guide TrekMail sur les messages classés en spam souligne le DNS, la montée en charge du domaine, la qualité de la liste et le contenu. DKIM corrige une partie de l’authentification, mais ne crée pas à lui seul une réputation.

Pensez aussi au transfert. SPF échoue souvent lors d’un transfert. DKIM peut maintenir DMARC valide dans de nombreux cas si la signature reste intacte et alignée. Si vous transférez des messages, lisez le transfert d’e-mails pour ne pas confondre un échec SPF lié au transfert avec un échec complet d’authentification.

Le piège de l’alignement DKIM

L’alignement est le point où beaucoup de configurations « fonctionnelles » n’atteignent pas leur objectif. La signature peut être valide sans contribuer à la réussite DMARC si son domaine ne s’aligne pas sur le From visible. Ce n’est un problème DNS que dans certains cas ; c’est souvent un réglage du prestataire.

Échec courant :

From: ceo@example.com
Signataire DKIM : d=sendgrid.net
Résultat : DKIM peut réussir, mais l’alignement DMARC peut échouer, car le domaine signataire ne s’aligne pas sur example.com.

Google indique que, pour les expéditeurs en nombre, le domaine From visible doit s’aligner avec SPF ou DKIM au niveau du domaine organisationnel. Si le prestataire signe avec son propre domaine, la signature peut être valide sans apporter l’alignement DKIM nécessaire.

La correction peut s’appeler authentification de domaine, marque blanche ou configuration d’un return-path personnalisé selon le fournisseur. Pour DKIM, il faut aligner le domaine de signature ; modifier uniquement le return-path concerne SPF. La signature finale devrait ressembler à ceci :

DKIM-Signature: ... d=example.com; s=s1; ...

Cette configuration peut contribuer à DMARC et au placement en boîte de réception. Une signature non alignée ne termine pas cette partie du travail.

Ancienne et nouvelle approche de DKIM

L’ancienne approche est manuelle et fragile : chaque domaine, fournisseur, sélecteur et particularité DNS est traité séparément. La nouvelle standardise : choisir un modèle d’envoi reproductible, centraliser les contrôles DNS et éviter de reconstruire la même correction pour chaque domaine.

TrekMail peut s’inscrire dans ce modèle. Selon le forfait actuel, vous pouvez gérer plusieurs domaines personnalisés depuis un tableau de bord, utiliser du stockage mutualisé sans facturation par boîte, migrer les boîtes via IMAP et choisir BYO SMTP ou SMTP inclus. Les forfaits payants décrits commencent à $3.50/mois ; vérifiez les tarifs actuels. La plateforme vise équipes, PME, agences et MSP souhaitant réduire la gestion quotidienne de l’infrastructure de messagerie.

Si le problème principal concerne le processus plutôt que le DNS, lisez la gestion des e-mails clients. En environnement multidomaine, les responsabilités mal définies peuvent expliquer des problèmes de délivrabilité, au-delà des registres.

Liste finale de configuration DKIM

Une configuration solide utilise le bon système signataire, le bon nom DNS, une clé complète, la vérification du DNS public et une signature alignée pour DMARC. Une erreur dans l’un de ces éléments fragilise l’ensemble.

1. Confirmez quel système signe les messages sortants.
2. Publiez exactement le sélecteur et le type de registre du fournisseur.
3. Utilisez selector._domainkey dans le champ d’hôte sauf demande explicite du nom complet.
4. Gardez les clés de 2048 bits intactes. Séparez les chaînes entre guillemets uniquement si le panneau l’exige.
5. Vérifiez avec dig ou nslookup.
6. Envoyez un test et recherchez dkim=pass et un header.d aligné dans les en-têtes.
7. Vérifiez DMARC après la mise en production.

C’est tout. Une bonne configuration DKIM n’est pas compliquée, mais précise. Pour réduire les dépendances, standardisez domaines et chemin d’envoi dans TrekMail lorsque cela répond à vos besoins, gardez une vue centralisée du DNS et évitez de répéter des tâches manuelles coûteuses.