Vous avez déplacé les boîtes de votre entreprise vers Google Workspace, depuis un hébergeur mutualisé comme OVHcloud. L’assistant d’installation vous propose d’importer vos anciens messages en deux clics. Vous cliquez, les messages arrivent. Quelques jours plus tard, les e-mails de vos collègues retombent en spam chez vos destinataires ou reviennent avec une erreur de livraison.
Le 23 septembre 2026, Google a annoncé la disponibilité générale d’un import IMAP intégré au parcours d’installation de Workspace. Le communiqué promet un transfert sans couture. Pour un postmaster, la copie des messages est la partie facile. La délivrabilité se joue dans les enregistrements SPF, DKIM et DMARC, que l’outil n’importe pas.
L’annonce ne met pas en avant le second chemin d’import, celui de la console d’administration. Elle n’insiste pas non plus sur l’étape d’authentification que Google place pourtant dans son parcours.
Ce que l’annonce du 23 septembre change
Le billet publié le 23 septembre 2026 sur le blog Google Workspace Updates acte la disponibilité générale de l’import IMAP pendant la configuration. La technique sous-jacente est connue depuis longtemps. La nouveauté réside dans l’endroit où Google la place : au moment où vous créez un nouveau tenant, avant même la fin de la mise en route.
Le flux se réduit à deux étapes. Vous connectez le serveur IMAP, puis vous saisissez l’adresse et le mot de passe de la boîte source. Google cite quatre fournisseurs à titre d’exemple : Hostinger, Zoho, Yahoo! et iCloud, suivis d’un « et bien d’autres ». La page d’aide associée en détaille 19, dont trois hébergeurs très présents en France : 1&1 IONOS, OVHcloud et Gandi.net.
Cet import d’installation reste taillé pour un seul utilisateur à la fois. Il ne s’ouvre qu’après la vérification du domaine et l’activation des e-mails. Pour déplacer plusieurs boîtes, la console d’administration propose l’outil Data Import, plus ancien et plus configurable : il accepte jusqu’à 100 utilisateurs IMAP par import, via un fichier CSV de moins de 128 Mo. Google n’a rien supprimé, il ajoute ce chemin simplifié en amont.
Ce que l’outil ne transfère pas : votre authentification
L’import IMAP copie les messages et leurs dossiers, mais ne touche pas aux enregistrements DNS qui conditionnent la remise de vos e-mails. SPF, DKIM et DMARC ne vivent pas chez votre fournisseur de messagerie : ils résident dans la zone DNS de votre domaine, hébergée chez votre registrar ou votre hébergeur DNS. Ils restent donc exactement où ils étaient.
Google le reconnaît dans son propre parcours. Après l’import, l’assistant propose une étape Authenticate qui demande de configurer DKIM afin de protéger votre domaine et de garantir l’envoi correct de vos messages. La page d’aide du setup le formule sans détour : l’authentification sert à ce que les messages partent correctement.
Sans DKIM personnalisé, vos messages ne partent pas sans signature. Google signe systématiquement chaque envoi avec sa clé par défaut, sous un domaine qui se termine en gappssmtp.com. La signature DKIM existe et passe les contrôles : elle n’est simplement pas alignée sur votre domaine d’expéditeur. Le champ d= de l’en-tête pointe vers gappssmtp.com, pas vers votredomaine.com.
Pour un domaine sans politique DMARC stricte, la différence passe inaperçue au quotidien. Pour un domaine sous politique p=quarantine ou p=reject, un double défaut d’alignement, SPF et DKIM ensemble, transforme la migration en panne immédiate.
La réputation ne suit pas davantage. Google Workspace est une messagerie d’entreprise collaborative : vos échanges sont des conversations individuelles et des transactions, plafonnées autour de 2 000 messages par jour et par utilisateur. Les adresses IP d’envoi appartiennent aux pools mutualisés de Google, leur réputation ne vous appartient pas. La seule réputation qui vous suit est votre sender reputation, construite à l’échelle du domaine, jamais de l’IP mutualisée.
Le scénario qui rejette vos premiers envois
Le cas concret qui parle à un postmaster est simple. Une entreprise dont le domaine applique déjà une politique DMARC stricte (p=reject), alignée sur son ancien hébergeur OVHcloud, importe ses boîtes IMAP vers Google Workspace puis bascule ses MX. Ses utilisateurs commencent à émettre depuis Gmail, mais deux éléments manquent : le SPF du domaine n’autorise encore que mx.ovh.com, et la clé DKIM personnalisée n’a pas été activée.
Côté serveur destinataire, les deux mécanismes d’alignement échouent en même temps :
- Le SPF ne passe pas : l’IP d’envoi de Google n’étant pas couverte par l’enregistrement du domaine, le contrôle renvoie un
softfail. - Le DKIM passe techniquement, mais porte la signature par défaut de Google (
d=...gappssmtp.com), non alignée avec le domaine de l’en-tête From.
Aucun des deux protocoles n’étant aligné sur votre domaine, DMARC échoue. Le serveur destinataire applique la politique de rejet et refuse l’e-mail. Côté expéditeur, le message revient immédiatement avec un rebond SMTP explicite :
550 5.7.26 Unauthenticated email from votredomaine.com is not accepted due to domain's DMARC policy.Côté serveur de réception (ou dans vos en-têtes lors d’un envoi de test en p=quarantine), l’analyse d’authentification détaille le double échec :
Authentication-Results: mx.google.com;
dkim=pass header.i=@votredomaine-com.20230601.gappssmtp.com header.s=20230601;
spf=softfail (google.com: domain of transitioning user@votredomaine.com does not designate 209.85.220.41 as permitted sender) smtp.mailfrom=user@votredomaine.com;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=votredomaine.comLa checklist d’une migration propre
Le pas-à-pas complet de la console d’administration dépasse le cadre de cet article : nous l’avons détaillé dans le guide Console admin Google Workspace : les réglages de délivrabilité que les administrateurs oublient. En voici la version synthétique, à exécuter dans l’ordre.
- Baissez préventivement le TTL de vos enregistrements MX à 300 secondes, 48 heures avant la bascule. Si la migration tourne mal, vous rebasculez vers l’ancien serveur en quelques minutes au lieu d’attendre la propagation.
- Couvrez la période de transition avec un double include SPF, pour laisser passer les envois résiduels de l’ancien serveur (formulaires de site, factures applicatives) :
v=spf1 include:_spf.google.com include:mx.ovh.com ~all - Générez une clé DKIM 2048 bits dans la console d’administration (Apps > Google Workspace > Gmail > Authenticate email), publiez l’enregistrement TXT sur le sélecteur
google._domainkey, puis attendez la propagation avant d’activer la signature. - Gérez la transition DMARC selon votre point de départ. Si vous partez de zéro, publiez un enregistrement en
p=nonepour observer vos flux (v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine.com). Si votre domaine applique déjàp=reject, mettez impérativement à jour votre SPF avec l’include Google avant de basculer les MX, ou repassez temporairement enp=nonele temps de valider l’alignement de la nouvelle infrastructure.
L’ordre compte. Posez le SPF avec les deux include, activez la clé DKIM personnalisée, puis basculez les MX. La checklist de diagnostic SPF permet de valider la syntaxe avant la bascule, et les rapports DMARC confirment l’alignement avant de durcir ou rétablir la politique vers p=reject.
