Activer DKIM sur Google Workspace : le guide pas à pas

Générer la clé : 2048 bits, sauf contrainte DNS

Le choix présélectionné est 2048 bits, et c'est le bon. Une clé RSA de 1024 bits est considérée comme trop courte depuis des années par les référentiels cryptographiques ; les grands fournisseurs acceptent encore les signatures 1024, mais rien ne justifie de créer une clé faible en 2026. Google lui-même propose 2048 par défaut.

La seule vraie raison de rétrograder est matérielle : la clé publique 2048 bits produit une valeur d'environ 400 caractères, au-delà de la limite de 255 caractères par chaîne d'un enregistrement TXT. Le standard DNS règle le problème — un TXT accepte plusieurs chaînes concaténées — et la plupart des interfaces modernes découpent la valeur automatiquement. Mais certains panneaux anciens refusent la saisie longue. Dans ce cas, deux issues : découper la valeur à la main en deux chaînes entre guillemets, ou, en dernier recours, régénérer une clé 1024. L'arbitrage complet — solidité, compatibilité, rotation — est posé dans le comparatif des clés de 1024 et 2048 bits. Le réflexe sain : tenter 2048 d'abord, et ne rétrograder qu'après un refus avéré de la zone.

Publier le TXT google._domainkey et lancer l'authentification

La fenêtre de génération affiche deux valeurs à reporter dans la zone DNS : le nom d'hôte, google._domainkey, et la valeur TXT, qui commence par v=DKIM1; k=rsa; p=. Publié, l'enregistrement ressemble à ceci :

google._domainkey.exemple.fr.  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" )

Deux précautions de saisie. D'abord le nom d'hôte : selon l'interface DNS, le champ attend google._domainkey seul (l'interface complète avec le domaine) ou le nom entier google._domainkey.exemple.fr — l'erreur classique produit google._domainkey.exemple.fr.exemple.fr, que personne n'interrogera jamais. Ensuite la valeur : la clé doit être copiée intégralement, sans espace parasite ni troncature ; une clé amputée d'un seul caractère produit des signatures invérifiables, pire qu'aucune signature. Un rapide dig TXT google._domainkey.exemple.fr confirme ce que le monde voit réellement.

L'enregistrement publié, retour dans la console : le bouton « Lancer l'authentification » demande à Google de vérifier la présence de la clé, puis bascule la signature des messages sortants sur d=exemple.fr, sélecteur google. Si la vérification échoue, c'est presque toujours une question de propagation : selon les TTL et les résolveurs, la clé met de quelques minutes à 48 heures pour devenir visible partout. L'erreur n'a rien de définitif — le bouton se retente plus tard. Une fois l'authentification démarrée, les messages suivants sont signés immédiatement ; ceux déjà partis conservent évidemment l'ancienne signature.

Vérifier : DKIM-Signature et s=google

La preuve se lit dans les en-têtes. Le test le plus simple : envoyer un message depuis le domaine vers une boîte externe — une adresse Gmail personnelle convient — puis ouvrir « Afficher l'original » dans Gmail. La page résume les trois verdicts (SPF, DKIM, DMARC) et donne l'en-tête complet.

Deux lignes comptent. La première, DKIM-Signature, doit porter le bon couple domaine-sélecteur :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=exemple.fr; s=google; h=from:to:subject:date; …

d=exemple.fr et s=google : la signature engage désormais le domaine lui-même. La seconde, Authentication-Results, doit afficher dkim=pass header.i=@exemple.fr. Si le d= mentionne encore gappssmtp.com, l'authentification n'a pas réellement démarré — ou le message est parti avant la bascule.

À l'échelle, la confirmation vient des rapports agrégés DMARC : en quelques jours, les volumes émis par les IP de Google doivent apparaître alignés côté DKIM. Nuance importante : dkim=pass seul ne dit rien de l'alignement — une signature gappssmtp.com intacte affiche aussi pass. C'est la correspondance entre le d= et le From qui fait la différence, et c'est précisément elle que les rapports mesurent.

Ce que l'activation change pour l'alignement DMARC

DMARC valide un message si l'un au moins de ses deux mécanismes passe et s'aligne : SPF avec le domaine du Return-Path, DKIM avec le domaine du d=. Sur un domaine Google Workspace, SPF est généralement déjà en place et aligné pour les envois directs. L'activation de DKIM n'est donc pas redondante : elle ajoute la jambe qui survit là où SPF tombe.

Le cas décisif est la redirection. Un message transféré automatiquement — boîte de transfert, adresse d'un ancien collaborateur, liste interne — arrive chez le destinataire final depuis l'IP du serveur qui transfère, pas depuis Google : SPF échoue. La signature DKIM, elle, voyage dans le message et reste vérifiable tant que le contenu signé n'est pas altéré. Avec DKIM aligné, ces flux transférés continuent de passer DMARC ; sans lui, ils deviennent des faux positifs dès que la politique se durcit.

C'est pourquoi l'activation de DKIM est un prérequis de fait au passage à p=quarantine puis p=reject : elle transforme des rapports pleins d'échecs ambigus en une base saine où les seuls échecs restants sont les suspects. Les paliers de politique et leur syntaxe exacte — p=, rua=, alignement strict ou souple via adkim= — sont déroulés dans les exemples commentés d'enregistrements DMARC, le point d'étape naturel une fois la signature en place.

Les pièges : domaine récent, alias et multi-domaines

Le domaine ajouté récemment. Sur un domaine qui vient d'être raccordé à Google Workspace, la génération de clé peut rester indisponible plusieurs heures, et le lancement de l'authentification échouer alors que le TXT est correctement publié. La documentation de Google évoque un délai pouvant atteindre 72 heures après l'activation de Gmail sur le domaine. Le symptôme — bouton inopérant, erreur persistante — se traite par la patience, pas par la régénération frénétique de clés.

Les alias de domaine. Chaque alias envoie du courrier sous son propre nom, et l'alignement DKIM se juge alias par alias. La clé du domaine principal ne couvre pas un alias : il faut le sélectionner dans le menu déroulant, générer sa propre clé, la publier dans sa zone DNS et lancer son authentification. Un alias oublié continue de signer en gappssmtp.com — et ses messages échoueront à l'alignement le jour du durcissement.

Le multi-domaines. Même logique : la procédure se répète domaine par domaine. Le sélecteur google peut être réutilisé dans chaque zone sans conflit — un sélecteur est local à sa zone. Les rapports agrégés restent le meilleur détecteur de domaine oublié.

Les expéditeurs tiers. La clé générée dans la console ne signe que ce qui part de Gmail. Une plateforme d'e-mailing — Mailchimp, Brevo, SendGrid — signe avec ses propres clés, à configurer chez elle. Et côté Microsoft, la mécanique diffère sensiblement (deux enregistrements CNAME, sélecteurs selector1/selector2) : le guide équivalent pour Microsoft 365 en fait le tour.

La rotation de clé. Une rotation ultérieure suit la même séquence — générer, publier, relancer — en laissant l'ancienne clé publique publiée quelques jours, le temps que les messages encore en transit restent vérifiables.

En résumé

Par défaut, Google Workspace signe DKIM avec un domaine technique gappssmtp.com qui ne sert à rien pour DMARC. L'activation sur le domaine personnalisé suit un parcours court : console d'administration (Applications → Google Workspace → Gmail → Authentifier l'e-mail), génération d'une clé 2048 bits, publication du TXT google._domainkey, lancement de l'authentification, vérification dans les en-têtes (d= du domaine, s=google). L'opération se répète pour chaque domaine et chaque alias, et ne couvre que les envois Gmail — les plateformes tierces signent séparément. Le gain est net : une jambe d'authentification qui survit aux redirections et rend le passage à p=reject réaliste.

Reste à mesurer l'état réel : une analyse DMARC gratuite du domaine montre en quelques secondes si les envois Google Workspace sortent alignés — et ce qui manque encore. Pour suivre la progression dans les rapports et durcir la politique au bon rythme, l'ouverture d'un compte prend quelques minutes ; la signature, elle, est déjà en place.