Leurs e-mails disparaissaient. Nous avons migré la messagerie vers Google Workspace, et les détails ont fait la différence

Le problème nous a été signalé comme souvent dans ce genre de situation : de façon assez vague. Certains clients ne recevaient jamais nos réponses. Avec les destinataires sur Gmail, tout allait bien. De temps en temps, un message revenait avec la mention non distribué. Et un fournisseur, un grossiste auprès duquel la boutique s'approvisionne, pouvait lui écrire sans problème, mais la boutique ne pouvait pas lui répondre.

Il s'agit d'un petit commerce spécialisé dont nous assurons le suivi. Une seule boîte mail professionnelle partagée, des années d'historique, quelques personnes qui la consultent sur ordinateur et sur téléphone, et une boutique en ligne qui envoie ses confirmations de commande depuis la même adresse. Personne dans cette équipe n'a envie de se préoccuper de la messagerie. Ils veulent que les e-mails arrivent.

Voici le récit anonymisé de notre intervention : les étapes suivies, les pièges évités et les vérifications que nous recommandons après toute migration de ce type. En quelques mots : nous avons transféré la boîte mail vers Google Workspace et conservé le site chez son hébergeur ; seuls ses paramètres de messagerie ont changé. Mais tout l'intérêt est dans les détails, car l'essentiel du travail a porté sur les points qui demandaient une attention particulière : la bascule DNS, des dizaines de milliers d'anciens messages, le dossier Messages envoyés (Sent) et les notifications de la boutique elle-même.

Tous les contrôles étaient au vert, et les e-mails disparaissaient toujours

Le premier réflexe est de vérifier l'authentification. Nous l'avons fait aussi. SPF était valide. DKIM était valide. DMARC était valide, avec la politique p=none, qui demande aux destinataires de ne prendre aucune mesure en cas d'échec DMARC. Sur le papier, le domaine était correctement configuré. Pourtant, les symptômes duraient depuis des mois malgré ces contrôles réussis.

L'explication se trouvait un cran plus loin. Tout ce qu'utilisait la boutique, les DNS du domaine, le site et la boîte mail, se trouvait chez un même hébergeur mutualisé. Les e-mails sortants ne partaient pas du propre serveur de la boutique. Ils passaient par le relais sortant mutualisé de l'hébergeur, les quelques serveurs qu'utilisent aussi de nombreux autres clients. Or, l'adresse du relais qui acheminait les messages de la boutique figurait sur une liste de blocage antispam publique.

Les problèmes de distribution correspondaient à cette inscription : les serveurs destinataires qui consultent ce type de liste rejettent les messages provenant d'une adresse répertoriée ou les classent en spam, quelle que soit la qualité de leur signature. Gmail, lui, s'appuie surtout sur ses propres données de réputation. Nous n'avons jamais vu le message de rejet du grossiste lui-même, mais de son côté, tout se passait exactement comme avec un filtre qui utilise cette liste.

L'authentification n'a jamais été le problème. C'était la réputation du relais mutualisé.

Pour effectuer le même diagnostic sur votre domaine, ces commandes couvrent l'essentiel. L'adresse IP se trouve dans la ligne Received: ajoutée par le serveur destinataire à un message que vous avez envoyé vers une adresse Gmail vous appartenant. Ouvrez-le, puis choisissez Afficher l'original (Show original).

# Who receives your mail, and what do SPF and DMARC say?
dig +short MX example-shop.com
dig +short TXT example-shop.com | grep -i spf
dig +short TXT _dmarc.example-shop.com

# Is the server that sent your message on a blocklist?
# Example only: reverse the real sending IP, 203.0.113.25 becomes 25.113.0.203
dig 25.113.0.203.bl.spamcop.net A +noall +comments +answer
# status NOERROR with 127.0.0.2 = listed; status NXDOMAIN = not listed right now;
# SERVFAIL, REFUSED or a timeout = no answer, try the list's own web lookup

Une précaution pratique : certaines listes de blocage, dont Spamhaus, refusent les requêtes passant par de grands résolveurs DNS publics et renvoient un code d'erreur à la place. Par ailleurs, une requête vérifie une seule liste à un instant donné, pas votre délivrabilité dans son ensemble.

Pourquoi nous avons déplacé la messagerie, et seulement la messagerie

La messagerie et l'hébergement web sont deux services distincts, simplement vendus ensemble. Déplacer un site est un projet avec un risque d'interruption, des caches à réchauffer et une douzaine de paramètres à coordonner. Déplacer la messagerie, c'est une modification DNS et un import. Le site de la boutique fonctionnait : nous l'avons donc laissé chez son hébergeur et avons résolu le problème qui la pénalisait réellement.

Nous avons étudié quatre possibilités :

Nous recommanderions l'un comme l'autre de ces deux grands services. Nous avons choisi Workspace pour une raison simple : les personnes qui utilisent la boîte connaissaient déjà Gmail. Moins une petite équipe a de choses à apprendre, plus vite elle adopte le changement.

Nous avons également conservé un utilisateur Workspace dédié à la boîte professionnelle, au lieu de la fusionner avec le compte personnel de quelqu'un. Une adresse professionnelle intégrée au Gmail privé d'une personne est difficile à transmettre, à auditer et à récupérer lors d'un départ. Si plusieurs personnes ont besoin de leur propre connexion plutôt que d'un accès partagé, la délégation Gmail permet à des comptes individuels de travailler dans la boîte partagée. Nous avons abordé cette question des accès dans notre article sur ce qui se passe lorsqu'un salarié part, mais que ses accès restent actifs.

Avant de toucher aux DNS : la préparation

La bascule elle-même prend quelques minutes. La préparation détermine si ces minutes se passent tranquillement ou dans l'urgence.

• Sauvegardez l'intégralité de la zone DNS. Exportez-la ou notez chaque enregistrement pour pouvoir rétablir exactement les anciens. Gardez à l'esprit qu'un retour arrière change uniquement la destination des nouveaux e-mails : ceux reçus entre-temps chez Google y restent.
• Recensez toutes les adresses qui reçoivent des e-mails. Boîtes mail, alias, redirections, groupes, règles catch-all. Dès que l'enregistrement MX pointe vers Google, chacune doit aussi y exister, sinon ses messages seront rejetés. Cette boutique n'avait qu'une seule boîte mail et rien d'autre, ce qui simplifiait l'inventaire.
• Recensez tout ce qui envoie des e-mails au nom de votre domaine. Clients de messagerie sur ordinateur et téléphone, boutique en ligne (confirmations de commande, formulaire de contact, réinitialisations de mot de passe), outils de facturation, comptes sur les places de marché. Tout doit continuer à fonctionner après la bascule.
• Abaissez le TTL de l'enregistrement MX à 300 secondes la veille. Le MX de la boutique avait un TTL de quatre heures : les autres serveurs de messagerie pouvaient donc conserver l'ancienne destination en mémoire pendant quatre heures après le changement.
• Ajoutez l'enregistrement TXT de validation Google et terminez l'activation de Gmail dans la console d'administration (Admin console). L'enregistrement de validation coexiste avec votre enregistrement SPF. Un domaine peut avoir plusieurs enregistrements TXT, mais un seul peut être un enregistrement SPF.
• Activez la validation en deux étapes pour l'administrateur Workspace et l'utilisateur de la boîte mail, et conservez les codes de secours en lieu sûr avant que les e-mails commencent à arriver.

La bascule, enregistrement par enregistrement

Voici les modifications effectuées, avec des valeurs fictives à la place des noms de la boutique.

Pour l'enregistrement SPF, conservez tous les mécanismes encore nécessaires à vos expéditeurs actifs et ajoutez l'include de Google à leurs côtés : un seul enregistrement SPF par nom et dix requêtes DNS au maximum au total, en comptant tous les includes.

Deux détails méritent qu'on s'y attarde. D'abord, la clé DKIM dépasse les 255 caractères que peut contenir une seule chaîne de texte DNS. Elle doit pourtant rester dans un seul enregistrement TXT : certains panneaux DNS la découpent automatiquement en plusieurs chaînes entre guillemets à l'intérieur de cet enregistrement, d'autres vous demandent de le faire. Comparez la valeur publiée à celle de la console d'administration, caractère par caractère, puis cliquez sur Démarrer l'authentification (Start authentication) dans Applications > Google Workspace > Gmail > Authentifier les e-mails (Apps > Google Workspace > Gmail > Authenticate email). Sur un compte Workspace tout neuf, Google peut imposer un délai d'un jour ou plus avant d'autoriser la génération de la clé.

Ensuite, ne vous fiez pas à votre seul résolveur pour confirmer la bascule. Interrogez directement chaque serveur de noms faisant autorité :

# Ask each of the domain's nameservers which MX it hands out right now
for ns in $(dig +short NS example-shop.com.); do
  printf '%s\n' "$ns"
  dig @"$ns" example-shop.com. MX +norecurse +noall +comments +answer
done
# Look for the "aa" flag (an authoritative answer) and the new MX in every block

Lors de notre vérification, un serveur de noms a renvoyé le MX de Google en quelques secondes. Les trois autres ont continué à renvoyer l'ancien MX pendant une vingtaine de minutes, avec le même numéro de série de zone. Nous n'avons jamais su pourquoi. Si nous n'avions vérifié que notre propre résolveur, nous aurions considéré la bascule comme terminée sans voir que des e-mails empruntaient encore l'ancien chemin pendant vingt minutes.

Un serveur de noms répondait avec Google en quelques secondes. Les trois autres ont mis environ vingt minutes.

Prévoyez aussi une période résiduelle. Les serveurs de messagerie qui ont consulté l'ancien MX avant le changement, ou qui ont des messages en attente de nouvelle tentative, peuvent continuer à livrer des e-mails à l'ancienne boîte pendant un certain temps. Gardez donc les deux boîtes opérationnelles pendant la transition, surveillez l'ancienne et relancez l'import jusqu'à ce qu'elle ne reçoive plus rien. Sur les panneaux d'hébergement comme cPanel, vérifiez aussi le paramètre de routage des e-mails du domaine : si le compte d'hébergement pense toujours gérer la messagerie du domaine, les messages envoyés par le site vers votre propre adresse peuvent être distribués localement dans l'ancienne boîte.

Transférer 40 000 messages sans en perdre un seul

L'ancienne boîte contenait 39 840 messages répartis dans 27 dossiers, soit environ 13 Go au total, avec des années d'historique : factures fournisseurs, commandes des places de marché, avis des transporteurs, échanges avec les clients. Il était hors de question d'en perdre une partie, ou de passer une semaine avec des dossiers à moitié importés.

L'import est la partie facile. C'est le rapprochement qui permet d'affirmer que rien n'a été perdu.

Nous avons commencé par l'outil de migration des données intégré à Google, qui se connecte à l'ancien serveur en IMAP et copie l'ensemble. Il fonctionne, mais sur cette boîte, il présentait trois problèmes :

• La vitesse. Environ 2 400 messages par heure, soit plus de seize heures pour cette boîte. D'après ce que nous avons pu observer, il récupérait un message par session IMAP, et l'outil ne propose aucun réglage de vitesse.
• Les omissions. Plusieurs dossiers signalaient un « crawl failure », avec une erreur interne de synchronisation. Le conseil donné était de relancer une migration plus tard.
• Les dates incorrectes. 925 messages provenaient d'un même expéditeur dont le système de messagerie produit un en-tête Date mal formé, avec des secondes sans zéro initial et sans fuseau horaire, comme 2 Apr 2024 18:36:4. Deux autres n'avaient aucun en-tête Date. La migration leur a attribué la date et l'heure de l'import : des messages vieux de plusieurs années apparaissaient donc en tête de la boîte de réception comme s'ils étaient arrivés le matin même.

Nous avons donc terminé le travail avec notre propre outil d'import, fondé sur l'API d'import de Gmail, que nous maîtrisions de bout en bout :

• Lecture seule à la source. L'ancienne boîte a été ouverte en lecture seule, et chaque message récupéré sans activer l'indicateur de lecture. Rien n'a changé sur l'ancien serveur, qui restait donc une solution de repli valable.
• Ignorer les messages déjà arrivés. Le Message-ID de chaque message a été comparé à ceux déjà présents dans Gmail pour éviter de recopier ce que la migration Google avait déjà transféré.
• Les dossiers deviennent des libellés. Un ancien dossier comme INBOX.Invoices est devenu le libellé Gmail Invoices : l'équipe retrouvait ainsi chaque chose à sa place.
• Reprise après interruption. Un fichier d'état enregistrait la progression. En cas d'interruption, l'import reprenait là où il s'était arrêté, sans repartir de zéro.
• La date du message lui-même. Les messages dotés d'un en-tête Date valide étaient placés dans la chronologie selon cette date, et non celle du jour de l'import.

Un autre détail se remarque dès le premier jour : les indicateurs de suivi. Les étoiles n'avaient pas été transférées lors de l'import, et une équipe qui s'en sert comme liste de tâches depuis des années le voit immédiatement. Nous avons retrouvé dans Gmail les copies des 530 messages marqués dans l'ancienne boîte et leur avons remis une étoile.

Le dossier Messages envoyés nécessitait un traitement à part

Après la distribution des e-mails elle-même, c'était le point qui comptait le plus pour le propriétaire de la boutique. Lors du passage à Gmail, trois problèmes distincts se sont posés avec les Messages envoyés.

1. Gmail décidait de ce qui comptait comme un message envoyé

Dans cette boîte, chaque message importé dont l'expéditeur était l'adresse de la boîte elle-même apparaissait dans les Messages envoyés. Nous avons ensuite observé la même chose avec les copies reçues via le relais. Après l'import, cela incluait des années de notifications automatiques de la boutique, puisque les confirmations de commande étaient toujours parties de l'adresse professionnelle. Les Messages envoyés contenaient soudain environ 1 950 messages que personne n'avait rédigés, mélangés aux vraies réponses de l'équipe.

Nous avons identifié les messages générés par la boutique grâce à leurs en-têtes de logiciel d'envoi, puis retiré les 1 959 messages des Messages envoyés pour les placer dans les libellés appropriés, avec la commande de déplacement IMAP. Dans cette boîte, déplacer un message hors du dossier Messages envoyés lui retirait ce libellé, exactement ce dont nous avions besoin. Nous l'avons d'abord testé sur un petit lot. Les Messages envoyés ne contenaient à nouveau que des e-mails rédigés par des personnes.

Gmail classait les notifications de la boutique dans Messages envoyés. Les déplacer a rendu ce dossier à nouveau utilisable par l'équipe.

2. Les nouveaux e-mails de la boutique allaient le remplir à nouveau

La façon la plus évidente de faire envoyer les e-mails d'une boutique via Google consiste à lui donner les identifiants de la boîte sur smtp.gmail.com. Cela fonctionne, et dès ce jour, chaque confirmation de commande se retrouve à nouveau dans les Messages envoyés. Nous avons plutôt configuré la boutique pour utiliser le service de relais SMTP de Google (smtp-relay.gmail.com), qu'un administrateur paramètre dans la console d'administration, sous Applications > Google Workspace > Gmail > Routage (Apps > Google Workspace > Gmail > Routing) :

• Expéditeurs autorisés (Allowed senders) : uniquement les adresses de mes domaines (only addresses in my domains)
• Exiger l'authentification SMTP (Require SMTP authentication)
• Exiger le chiffrement TLS (Require TLS encryption)

Le paramètre d'administration « Comprehensive mail storage », sous Gmail > Conformité (Compliance), était désactivé sur ce compte, et les messages relayés n'apparaissaient pas dans les Messages envoyés de l'expéditeur. Son activation conserve des copies des e-mails relayés dans les boîtes des utilisateurs. Si vous avez des obligations de conservation, ce paramètre et Google Vault sont les points à examiner.

3. Mais l'équipe veut toujours voir ce que la boutique a envoyé

Un dossier Messages envoyés bien rangé est appréciable, jusqu'au moment où un client appelle pour demander ce que disait sa confirmation. Grâce à un petit développement spécifique dans la boutique, chaque message envoyé avec succès déclenche désormais l'envoi d'une copie vers une adresse avec un suffixe « + » de la boîte principale (office+shop@). La copie provient d'une autre adresse du domaine (shop@), qui n'est pas une boîte mail. Son nom d'affichage indique les destinataires d'origine (« À : customer@... »), et son en-tête Reply-To pointe vers le client : une réponse part donc vers la bonne personne.

Un filtre Gmail sur deliveredto:office+shop@example-shop.com évite la boîte de réception, marque la copie comme lue et lui applique le libellé Messages envoyés - boutique. Pourquoi une autre adresse d'expéditeur ? À cause du premier point : dans cette boîte, les copies provenant de l'adresse de la boîte elle-même se retrouvaient dans les Messages envoyés, même lorsqu'elles arrivaient par le relais. Les notifications que la boutique envoie à sa propre équipe partent elles aussi de shop@. Elles arrivent ainsi dans la boîte de réception, où quelqu'un les lira vraiment.

Une limite à connaître : Gmail ne permet pas de placer un libellé à l'intérieur des Messages envoyés. Messages envoyés - boutique apparaît à côté dans la liste des libellés, ce que le propriétaire a accepté une fois la raison expliquée.

Les clients de messagerie sur ordinateur

Quelques réglages ont fait la différence entre « Thunderbird est lent depuis la migration » et un logiciel qui fonctionne correctement :

• Synchronisez moins de données. Gmail présente chaque libellé comme un dossier IMAP : un même message peut donc être téléchargé plusieurs fois. Dans les paramètres Gmail, sous Libellés (Labels), décochez « Afficher en IMAP (Show in IMAP) » pour les dossiers que l'équipe n'utilise pas sur ordinateur, comme Important. Attention à Tous les messages (All Mail) : les messages archivés ne se trouvent que là. Si l'équipe archive dans Gmail, gardez donc Tous les messages visible et limitez plutôt le téléchargement hors connexion dans le client.
• Ne laissez pas le client enregistrer une deuxième copie des e-mails envoyés. Pour les comptes qui envoient via Gmail, Gmail conserve déjà chaque message envoyé. Vérifiez qu'un message de test apparaît dans les Messages envoyés, puis désactivez la copie enregistrée par le client, qui sinon téléverse chaque message une deuxième fois.
• Retirez l'ancien compte du client. Supprimez-le après le dernier passage de l'import, ou renommez-le au minimum pour que personne ne réponde depuis l'ancien serveur par habitude.

Les e-mails de la boutique, côté PrestaShop

Quelle que soit la solution utilisée par votre boutique, les paramètres du relais ont le même sens. Dans PrestaShop 1.7 et 8, vous les renseignez sous Paramètres avancés > E-mail (Advanced Parameters > E-mail). Le libellé peut varier légèrement selon la version :

L'adresse e-mail de la boutique elle-même, définie sous Paramètres de la boutique (Shop Parameters), doit appartenir à votre domaine, sinon le relais la refusera. Envoyez l'e-mail de test depuis cette même page de paramètres, ouvrez-le dans Gmail, choisissez Afficher l'original et vérifiez trois validations : SPF, DKIM signé par votre propre domaine et DMARC. La copie d'archivage décrite plus haut ne fait pas partie de ces réglages : elle a nécessité un développement spécifique sur cette boutique, et PrestaShop ne le propose pas d'origine. Pour une vue plus complète des réglages de messagerie de PrestaShop, consultez notre guide sur la configuration des e-mails dans PrestaShop : SMTP, Gmail et e-mails transactionnels.

Après la bascule : fermer les anciens accès

Une migration est terminée lorsque plus rien ne dépend de l'ancien système et que personne ne peut l'utiliser par erreur. Voici la liste de vérifications que nous suivons après ce type de transfert :

• Resserrez la configuration SPF dès que quelques jours sans activité confirment que plus rien n'envoie par l'ancien serveur : retirez l'include de l'ancien hébergeur.
• Conservez un export indépendant de l'ancienne boîte avant de résilier l'ancien service et attribuez-lui un long mot de passe aléatoire pour que personne ne continue à l'utiliser par habitude.
• Révoquez tous les identifiants temporaires utilisés pour la migration : mots de passe d'application pour l'import, clients API, jetons d'hébergement.
• Vérifiez que les rapports DMARC arrivent réellement (l'enregistrement doit contenir une adresse de réception des rapports), lisez-les pendant quelques semaines, puis passez la politique de p=none à quarantine.
• Envisagez Google Postmaster Tools pour suivre les taux de spam et la réputation auprès de Gmail. Un petit expéditeur peut y voir peu de données : continuez donc à surveiller les retours d'erreur et les remarques des destinataires.
• Documentez où se trouve chaque élément : DNS, administration Workspace, paramètres du relais, filtres. La prochaine personne qui interviendra vous en sera reconnaissante, même si c'est vous dans deux ans.

Le résultat

Les e-mails de la boutique partent désormais par l'infrastructure de Google, signés avec le propre domaine de la boutique. SPF, DKIM et DMARC sont valides, le grossiste reçoit à nouveau les réponses et les signalements de messages « non distribués » ont cessé. Le seul retour d'erreur dans les premiers jours après la bascule concernait un e-mail de confirmation de compte envoyé à une fausse adresse saisie par un bot dans le formulaire d'inscription. Un rejet tout à fait souhaitable.

La boîte de réception de l'équipe ressemble à celle qu'elle a toujours connue, avec tous les anciens messages à leur place. Les Messages envoyés contiennent ce que les personnes ont rédigé. Les notifications de la boutique ont leur propre libellé, à un clic lorsqu'un client appelle.

Et un dernier détail, en toute transparence : le premier jour, nos propres messages de test vers la nouvelle boîte ont atterri dans le Spam. Ils provenaient d'un de nos petits serveurs, avec une authentification irréprochable et très peu d'historique d'envoi. Nous ne connaissons pas les raisons de Gmail, mais ce faible historique est l'explication la plus probable. C'est la même leçon que dans toute cette histoire : réussir les contrôles d'authentification ne suffit pas à inspirer confiance.

Questions fréquentes

Sources

• Google : configurer les MX pour Google Workspace
• Google : acheminer les e-mails sortants du relais SMTP via Google
• Google : limites d'envoi Gmail dans Google Workspace
• Google : activer DKIM
• Google : stockage complet des e-mails
• API Gmail : importer des messages