DKIM G Suite : configurer Google Workspace

Qu'est-ce que le DKIM de G Suite et où l'activer ?

Le DKIM de G Suite, c'est la signature DomainKeys Identified Mail intégrée à la messagerie professionnelle de Google, rebaptisée depuis Google Workspace. Les serveurs sortants de Google signent chaque message avec une clé privée, et les serveurs destinataires récupèrent la clé publique correspondante dans votre DNS pour vérifier la signature. Si vous ne configurez rien, Google signe quand même vos e-mails, mais d'après l'aide Google Workspace pour les administrateurs (« Configurer DKIM »), il le fait avec une clé par défaut sur un domaine gappssmtp.com appartenant à Google, et non sur le vôtre. Cette signature passe le contrôle DKIM, mais elle n'est pas alignée sur votre domaine d'expéditeur (From) : elle n'apporte donc rien à DMARC. Pour utiliser votre propre domaine, un super-administrateur ouvre la console d'administration et va dans Applications > Google Workspace > Gmail > Authentifier les e-mails. Sélectionnez le domaine, cliquez sur Générer un nouvel enregistrement, choisissez une longueur de clé : Google vous affiche alors le nom d'hôte et la valeur TXT à publier. La signature ne démarre qu'une fois revenu sur ce même écran, en cliquant sur Démarrer l'authentification. Cette étape est souvent oubliée, parce que publier l'enregistrement DNS donne l'impression d'avoir terminé.

Comment configurer le DKIM dans G Suite, étape par étape ?

La configuration du DKIM dans G Suite se fait à deux endroits : la console d'administration Google et votre hébergeur DNS. Il vous faut les droits de super-administrateur dans Workspace et un accès en écriture à la zone DNS qui sert réellement votre domaine. Si les serveurs de noms de votre domaine pointent ailleurs que chez votre registrar, modifiez les enregistrements là-bas, pas chez le registrar. L'ensemble des enregistrements attendus par Workspace (MX, SPF et DKIM) doit être en place sur cette même zone.

1. 1 Connectez-vous à admin.google.com avec un compte super-administrateur.
2. 2 Allez dans Applications > Google Workspace > Gmail > Authentifier les e-mails et choisissez le domaine dans la liste déroulante si vous en gérez plusieurs.
3. 3 Cliquez sur Générer un nouvel enregistrement. Google propose deux longueurs de clé ; prenez la plus longue si votre hébergeur DNS peut la stocker, et gardez le préfixe par défaut google sauf si vous faites une rotation de clés.
4. 4 Copiez les deux valeurs affichées par Google : le nom d'hôte google._domainkey et la valeur TXT, qui commence par une balise de version DKIM, puis k=rsa, puis p= suivi d'une longue clé publique encodée.
5. 5 Dans votre interface DNS, créez un seul enregistrement TXT avec l'hôte google._domainkey et collez la valeur complète. N'ajoutez pas un deuxième enregistrement pour le même hôte.
6. 6 Attendez que l'enregistrement se résolve. Les modifications DNS ne se propagent pas instantanément ; vérifiez avec dig TXT google._domainkey.votredomaine.com et ne poursuivez que lorsque la commande renvoie la valeur complète.
7. 7 Revenez dans Authentifier les e-mails et cliquez sur Démarrer l'authentification. Envoyez ensuite un message de test vers une adresse Gmail, ouvrez Afficher l'original et vérifiez DKIM: PASS avec d=votredomaine.com dans l'en-tête DKIM-Signature.

À quoi ressemble un enregistrement DKIM Google Workspace ?

Un enregistrement DKIM G Suite est un enregistrement TXT dans le DNS de votre domaine. Selon la spécification DKIM, l'hôte se compose du sélecteur suivi du libellé fixe _domainkey. Le sélecteur par défaut de Google est google, le nom complet est donc google._domainkey.votredomaine.com. Vous pouvez choisir un autre préfixe au moment de générer la clé, ce qui est utile si vous faites tourner vos clés ou si vous gérez plusieurs domaines Workspace. La valeur est une liste de balises : une balise de version, puis k=rsa pour le type de clé, puis p= et la clé publique encodée. Copiez la valeur exactement telle que Google l'affiche. Un caractère manquant ou un espace parasite dans la chaîne p= suffit à casser la signature de chaque message.

La plupart des interfaces DNS attendent l'hôte sans le domaine : simplement google._domainkey. Si vous saisissez le nom complet, beaucoup de fournisseurs ajoutent quand même la zone, et vous vous retrouvez avec google._domainkey.votredomaine.com.votredomaine.com. C'est le même problème d'hôte dédoublé que l'on rencontre chez GoDaddy en configurant le DKIM de Brevo. Pour vérifier ce qui est réellement publié, lancez dig TXT google._domainkey.votredomaine.com et comparez la valeur p= caractère par caractère avec celle de la console d'administration.

Quelle longueur de clé DKIM choisir dans Google Workspace ?

Prenez la plus longue des deux clés proposées par Google, sauf si votre hébergeur DNS ne peut pas la stocker ; la clé courte sert de solution de repli. Une clé plus longue est plus difficile à casser. Le piège, c'est une limite de format du DNS : la norme DNS plafonne la longueur d'une chaîne de caractères unique dans un enregistrement TXT, et la clé longue de Google, une fois encodée, dépasse ce plafond. La plupart des interfaces DNS récentes découpent automatiquement la valeur en plusieurs chaînes entre guillemets, et la spécification DKIM demande aux destinataires de recoller ces chaînes avant de vérifier la clé. Certaines interfaces plus anciennes refusent purement et simplement la valeur, ou la tronquent sans prévenir. Une clé tronquée a l'air correcte dans l'interface, mais échoue sur tous les serveurs destinataires.

1. 1 Générez la clé longue dans Authentifier les e-mails et copiez la valeur TXT complète.
2. 2 Collez-la dans votre interface DNS sous forme d'un seul enregistrement TXT sur google._domainkey.
3. 3 Si l'interface la refuse, découpez la valeur p= en morceaux qui restent chacun sous la limite par chaîne, chacun entre ses propres guillemets, le tout dans un seul enregistrement.
4. 4 Interrogez l'enregistrement avec dig et vérifiez que les chaînes recollées correspondent exactement à la valeur de Google.
5. 5 Si votre fournisseur ne gère pas du tout les TXT multi-chaînes, générez plutôt la clé courte. Elle est moins robuste, mais une clé qui fonctionne vaut mieux qu'une clé cassée.

Pourquoi le DKIM échoue-t-il encore après publication de l'enregistrement Google ?

Publier l'enregistrement, ce n'est que la moitié du travail. Tant que l'enregistrement ne se résout pas dans le DNS, le bouton Démarrer l'authentification échoue ou affiche une erreur : attendez donc que dig renvoie la valeur complète. Si les e-mails échouent encore après cela, la cause est presque toujours l'un des cinq points ci-dessous. Vérifiez-les dans Gmail en ouvrant un message de test reçu, en choisissant Afficher l'original, puis en lisant la ligne DKIM ainsi que le domaine d= dans l'en-tête DKIM-Signature.

• Démarrer l'authentification jamais cliqué : l'enregistrement existe, mais Google continue de signer avec son domaine par défaut gappssmtp.com, donc la valeur d= n'est pas la vôtre.
• Nom d'hôte dédoublé : l'interface a ajouté la zone à un hôte déjà complet, et l'enregistrement se trouve sous le mauvais nom.
• Clé tronquée : une valeur plus longue que la limite par chaîne TXT a été coupée par une interface qui ne découpe pas les chaînes.
• Mauvais serveurs de noms : l'enregistrement a été ajouté chez le registrar alors que le DNS est en réalité servi ailleurs.
• Corps modifié en transit : une liste de diffusion ou une passerelle de sécurité réécrit le message après la signature, ce qui casse le hachage du corps porté par la balise bh= de la signature.

Le DKIM de G Suite couvre-t-il les e-mails envoyés via Brevo ?

Non. Une signature DKIM est ajoutée par le serveur qui envoie le message, et la clé de Google ne signe que les e-mails qui quittent les propres serveurs de Google. Quand EmailFlow OS envoie votre prospection, les messages partent de votre propre adresse de boîte mail, mais via votre propre compte Brevo et votre propre domaine d'envoi. Ils ne passent jamais par un expéditeur partagé de la plateforme. C'est Brevo qui effectue l'envoi, c'est donc Brevo qui doit signer, et Brevo vous fournit pour cela son propre enregistrement DKIM à publier sur votre domaine.

Voici comment cela fonctionne dans EmailFlow OS. Vous enregistrez une seule vidéo et vous la téléversez, vous connectez votre compte Brevo et votre domaine d'envoi, puis vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS crée ensuite, à partir de cet unique enregistrement, une version personnalisée pour chaque destinataire, et envoie chacune d'elles via Brevo. Comme les clés Google et Brevo utilisent des sélecteurs différents, les deux enregistrements DKIM peuvent coexister sur le même domaine sans conflit. Mettre les deux en place avant d'augmenter les volumes fait partie du warm-up de domaine pour la prospection à froid, au même titre que la montée en charge progressive de vos envois de cold emailing avec EmailFlow OS.

Comment SPF et DMARC s'articulent-ils avec Google et Brevo sur un même domaine ?

Le DKIM n'est qu'un des trois enregistrements examinés par les fournisseurs de messagerie. Les consignes de Google pour les expéditeurs d'e-mails demandent à tout expéditeur écrivant à des comptes Gmail d'avoir SPF ou DKIM, et les expéditeurs en masse doivent avoir SPF, DKIM et DMARC ensemble. Lorsque Workspace et Brevo envoient tous deux pour le même domaine, voici les points qui posent le plus souvent problème :

• Un seul enregistrement SPF : la spécification SPF n'autorise qu'un seul enregistrement TXT SPF par domaine, et en publier deux provoque une permerror. Fusionnez l'include:_spf.google.com de Google et l'include de Brevo dans cet unique enregistrement au lieu d'en publier deux.
• Plafond de requêtes : la spécification SPF limite le nombre de mécanismes déclenchant une requête DNS lors d'une vérification ; au-delà, l'évaluation échoue en permerror, et chaque include compte dans ce total.
• Alignement DMARC : le domaine d= d'au moins une signature DKIM valide, ou le domaine SPF, doit correspondre à votre domaine From. En alignement relâché (relaxed), un sous-domaine est accepté.
• Commencer par p=none : publiez _dmarc avec p=none et une adresse rua, lisez les rapports agrégés pour les deux expéditeurs, et seulement ensuite passez à quarantine ou reject.

Le passage progressif de p=none à une politique appliquée se fait par étapes, en s'appuyant sur les rapports DMARC de Google Workspace et de Brevo, et c'est l'interaction des trois contrôles, DKIM, DMARC et SPF, qui détermine le sort de vos envois de cold emailing. Les exigences d'en-têtes et de structure des messages eux-mêmes relèvent, elles, du format de votre cold email : structure, en-têtes et vidéo.

Questions fréquentes

? Le DKIM de G Suite est-il le même que celui de Google Workspace ?

Oui. G Suite est l'ancien nom de Google Workspace, et la fonction DKIM fonctionne de la même manière. Vous générez toujours la clé dans Applications > Google Workspace > Gmail > Authentifier les e-mails, vous la publiez en TXT sur google._domainkey par défaut, et vous activez la signature avec Démarrer l'authentification.

? Combien de temps faut-il pour que le DKIM Google fonctionne ?

Cela dépend de la vitesse de propagation de votre modification DNS. Dès que dig renvoie la valeur TXT complète sur google._domainkey, vous pouvez cliquer sur Démarrer l'authentification, et la signature s'applique aux nouveaux e-mails sortants. Les messages envoyés avant ce moment conservent la signature par défaut de Google sur un domaine gappssmtp.com, qui n'est pas alignée sur votre adresse From.

? Peut-on avoir deux enregistrements DKIM sur un même domaine ?

Oui. Chaque enregistrement DKIM se trouve sous son propre sélecteur, par exemple google._domainkey pour Workspace et un sélecteur distinct pour Brevo. Les destinataires lisent la balise s= dans l'en-tête DKIM-Signature de chaque message pour savoir quelle clé récupérer : plusieurs clés ne se gênent donc pas. Le SPF, lui, est différent : la spécification SPF n'autorise qu'un seul enregistrement par domaine.

? Que se passe-t-il si je ne configure pas le DKIM de mon propre domaine dans Workspace ?

Google signe quand même vos e-mails, mais avec une clé par défaut sur un domaine gappssmtp.com appartenant à Google. Le DKIM passe, mais il n'est pas aligné sur votre domaine From, si bien que DMARC ne peut passer que via SPF. Vos e-mails restent alors exposés dès qu'un transfert casse le SPF, car le serveur qui transfère ne figure pas dans votre enregistrement SPF.