AWS WorkMail EOL — calendrier et ce que ça implique
AWS a publié l'avis de fin de support sur la page officielle de la documentation WorkMail. Les deux dates à retenir sont irrévocables : 30 avril 2026 — arrêt des inscriptions pour les nouveaux clients ; 31 mars 2027 — suppression de tous les comptes, boîtes mail, calendriers et contacts, sans possibilité de récupération après cette date.
Concrètement, cela signifie que les ressources WorkMail deviennent inaccessibles le 1ᵉʳ avril 2027 : la console AWS, les API, les clients IMAP et les connecteurs Exchange ActiveSync cessent de répondre simultanément. AWS ne prévoit ni prolongation ni mode lecture seule post-date. Tout ce qui n'est pas exporté avant le 31 mars 2027 est perdu définitivement.
L'urgence dépend de votre volume de messagerie : une boîte de 10 Go peut prendre plusieurs heures à exporter vers S3, et la migration IMAP avec imapsync dure proportionnellement au nombre de messages. Commencer la migration trois mois avant l'échéance est un minimum raisonnable. Idéalement, la coupure DNS doit être faite avant fin janvier 2027, laissant suffisamment de temps pour surveiller la délivrabilité et corriger d'éventuels problèmes avant la suppression définitive.
Pourquoi Mailcow plutôt que Stalwart ou une autre alternative
AWS lui-même cite Kopano Cloud, Zoho Mail et Zoom Mail comme alternatives recommandées. Ces solutions restent du SaaS — vous changez de fournisseur sans regagner de contrôle.
Si vous souhaitez une infrastructure email que vous maîtrisez entièrement, Mailcow est l'option la plus éprouvée pour une migration depuis une messagerie hébergée. Sa stack Docker Compose combine Postfix, Dovecot, Rspamd et SOGo dans une interface d'administration unifiée. La migration IMAP est bien documentée, la communauté est active, et le support IMAP entrant est natif — ce qui facilite considérablement l'import avec imapsync.
Stalwart est une alternative sérieuse (voir l'article dédié), mais son architecture binaire unique convient mieux à une installation from scratch qu'à une migration depuis WorkMail — le support de l'import de boîtes IMAP existantes est moins mature à la date de cet article. Pour une migration WorkMail, Mailcow est le choix pragmatique.
Prérequis avant de commencer
Trois ressources sont nécessaires avant de lancer la migration :
VPS avec au moins 6 Go de RAM. La stack Mailcow (Postfix, Dovecot, Rspamd, MariaDB, Redis, ClamAV, SOGo et le proxy nginx) consomme environ 3 à 4 Go en charge normale. Avec 6 Go, vous disposez d'une marge confortable pour imapsync et les pics de charge pendant la migration.
Accès administrateur à la console AWS WorkMail. L'export des boîtes passe par l'API AWS — vous avez besoin des droits IAM suffisants pour créer un rôle d'export, accéder à S3 et déclencher les jobs d'export via la CLI.
Un nom de domaine avec accès DNS. La coupure DNS (enregistrements MX, SPF, DKIM, DMARC) est l'étape finale — sans accès à votre zone DNS, vous ne pouvez pas rediriger le courrier entrant vers Mailcow.
Liste des prérequis détaillée
- VPS Linux 64 bits (Debian 12 ou Ubuntu 22.04 recommandés), minimum 6 Go RAM / 2 vCPU / 40 Go de stockage.
- IP dédiée avec PTR (enregistrement DNS inverse) configuré sur le hostname du serveur mail.
- Port 25 sortant débloqué par l'hébergeur — vérifier avant commande.
- Ports 25, 465, 587, 993 et 143 ouverts dans le pare-feu du VPS.
- Accès IAM AWS avec droits
workmail:StartMailboxExportJob,s3:PutObjectetkms:GenerateDataKey. - Un bucket S3 privé dans la même région AWS que votre organisation WorkMail.
- Une clé KMS symétrique dans la même région (requise par l'API d'export WorkMail).
- Accès DNS au domaine pour modifier MX, SPF, DKIM et DMARC.
- Docker et Docker Compose installés sur le VPS cible.
Exporter vos données AWS WorkMail
Créer le rôle IAM et les politiques d'export
L'export WorkMail nécessite un rôle IAM dédié avec deux politiques : une trust policy pour
export.workmail.amazonaws.comet une policy d'accès S3/KMS. Créer le rôle via AWS CLI :aws iam create-role --role-name WorkmailMailboxExportRole --assume-role-policy-document file://mailbox-export-trust-policy.jsonaws iam put-role-policy --role-name WorkmailMailboxExportRole --policy-name MailboxExport --policy-document file://mailbox-export-policy.jsonLa structure complète des politiques JSON est disponible dans la documentation officielle AWS WorkMail.
Récupérer les identifiants de l'organisation et des utilisateurs
L'API d'export requiert l'
OrganizationIdet l'UserId(entity ID) de chaque boîte. Les récupérer via CLI :aws workmail list-organizationsaws workmail list-users --organization-id m-XXXXXXXXXXXXLancer le job d'export vers S3
Déclencher un job d'export par boîte mail :
aws workmail start-mailbox-export-job --organization-id m-XXXXXXXXXXXX --entity-id S-1-1-11-XXXXXXXXXX --kms-key-arn arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID --role-arn arn:aws:iam::ACCOUNT:role/WorkmailMailboxExportRole --s3-bucket-name votre-bucket --s3-prefix exports/user1/L'API accepte jusqu'à 10 jobs simultanés par organisation.
Surveiller et télécharger
Suivre l'état avec
aws workmail list-mailbox-export-jobs --organization-id m-XXXXXXXXXXXX. Quand l'état passe àCOMPLETED, télécharger depuis S3 :aws s3 sync s3://votre-bucket/exports/ ./workmail-exports/Le log de sortie indique
totalMessages,totalBytesetsha384Hashpour vérification d'intégrité.Télécharger et vérifier les fichiers exportés
Téléchargez les archives depuis S3 :
aws s3 sync s3://votre-bucket/exports/ ./workmail-exports/ --region eu-west-1Vérifiez qu'aucune archive n'est corrompue et que le total des fichiers correspond au nombre de boîtes exportées. Chaque archive
.zipcontient les.emlde la boîte mail.Note sur les archives S3 et imapsync
imapsync travaille en IMAP-to-IMAP et ne lit pas directement les
.zipdepuis le disque. L'approche recommandée est de migrer via IMAP pendant que WorkMail est encore actif. Les archives S3 servent de sauvegarde de sécurité en cas de perte d'accès avant la migration.
Installer Mailcow sur VPS
Préparer le VPS et configurer le hostname
Définir un hostname FQDN cohérent avec le futur enregistrement PTR :
hostnamectl set-hostname mail.votredomaine.comVérifier que
hostname -fretourne le FQDN complet. Configurer le PTR sur l'IP du VPS depuis le panneau de votre hébergeur — ce PTR doit correspondre exactement au hostname.Cloner Mailcow et lancer l'installation
Consulter l'article détaillé Héberger un serveur email sur VPS avec Mailcow pour l'installation complète. En résumé :
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow-dockerizedcd /opt/mailcow-dockerized && ./generate_config.shdocker compose pull && docker compose up -dL'interface d'administration est accessible sur
https://mail.votredomaine.comaprès propagation DNS.Créer les domaines et comptes dans Mailcow
Dans l'interface Mailcow (Configuration → Mail Setup), ajouter le domaine et créer un compte pour chaque utilisateur WorkMail à migrer. Les adresses doivent être identiques à celles de WorkMail pour que imapsync puisse faire correspondre les boîtes.
Ne pas encore modifier les enregistrements MX — Mailcow peut recevoir des connexions IMAP sans être le MX actif, ce qui permet la migration avant la coupure DNS.
Migrer les emails avec imapsync
Installer imapsync sur le VPS Mailcow
Sur Debian/Ubuntu :
apt-get install -y imapsyncOu depuis le dépôt officiel pour la dernière version :
curl -L https://imapsync.lamiral.info/INSTALL.d/INSTALL.Debian.txt | bashVérifier l'installation :
imapsync --versionMigrer une boîte WorkMail vers Mailcow
Le serveur IMAP AWS WorkMail en us-east-1 est
imap.mail.us-east-1.awsapps.com(port 993, SSL). Adapter la région si votre organisation est dans eu-west-1 (imap.mail.eu-west-1.awsapps.com) ou us-west-2.`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'MotDePasseWorkMail' \
--host2 mail.votredomaine.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MotDePasseMailcow' \
--automap --skipcrossduplicates --useuid`L'option
--automapmappe automatiquement les dossiers système (Sent, Drafts, Trash) entre les deux serveurs.--skipcrossduplicatesévite les doublons si vous relancez la migration.--useuidutilise les UID IMAP pour un suivi précis de la progression.Migrer toutes les boîtes en parallèle
Pour les organisations avec plusieurs utilisateurs, lancer les migrations en parallèle avec un script :
`while IFS=: read -r user pass_wm pass_mc; do
imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 "$user" --password1 "$pass_wm" \
--host2 mail.votredomaine.com --ssl2 --port2 993 \
--user2 "$user" --password2 "$pass_mc" \
--automap --skipcrossduplicates --useuid \
--logfile "/var/log/imapsync-$user.log" &
done < users.csv`Limiter à 4 à 6 migrations simultanées pour ne pas saturer la bande passante. Surveiller les logs dans
/var/log/imapsync-*.log.Exécuter une passe de synchronisation finale
Pendant que les utilisateurs continuent d'utiliser WorkMail, relancer imapsync une dernière fois juste avant la coupure DNS pour synchroniser les emails arrivés depuis la première migration :
`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'MotDePasseWorkMail' \
--host2 mail.votredomaine.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MotDePasseMailcow' \
--automap --skipcrossduplicates --useuid --delete2duplicates`Grâce à
--useuid, imapsync ne re-transfère que les messages absents de Mailcow.
DNS cutover — MX, SPF, DKIM, DMARC
Une fois la migration IMAP terminée et vérifiée, la coupure DNS redirige le courrier entrant vers Mailcow. Ne pas couper avant d'avoir vérifié la délivrabilité (voir la section suivante).
MX — Remplacer l'entrée WorkMail (inbound-smtp.us-east-1.amazonaws.com) par Mailcow : votredomaine.com. MX 10 mail.votredomaine.com. Vérifier avec dig MX votredomaine.com +short.
SPF — Supprimer include:amazonses.com et autoriser votre VPS : votredomaine.com. TXT "v=spf1 mx a:mail.votredomaine.com -all"
DKIM — Mailcow génère les clés depuis Configuration → ARC/DKIM Keys. Copier l'enregistrement TXT dans votre DNS. Vérifier avec nslookup -type=TXT dkim._domainkey.votredomaine.com.
DMARC — Mettre à jour rua et conserver la politique existante : _dmarc.votredomaine.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
Réduire le TTL à 300 secondes une heure avant la coupure pour accélérer la propagation.
Tester la délivrabilité avant de couper AWS
Avant de modifier le MX, envoyer un email depuis Mailcow (via webmail SOGo ou un client configuré sur le port 587) et vérifier le score sur mail-tester.com — un score de 9/10 ou plus est le seuil acceptable pour une mise en production.
Vérifier également avec swaks depuis le VPS lui-même :
swaks --to [email protected] --from [email protected] --server mail.votredomaine.com --port 587 --auth LOGIN --auth-user [email protected] --tls
Inspecter les en-têtes du message reçu — l'en-tête Authentication-Results doit afficher spf=pass, dkim=pass et dmarc=pass. Si l'un des trois est absent ou en échec, ne pas couper le MX — corriger d'abord l'enregistrement DNS défaillant.
Vérifier aussi que l'IP du VPS n'est pas listée dans une base de réputation avec dig +short TXT <ip-inversée>.zen.spamhaus.org (une réponse vide signifie IP propre).
Dépannage — erreurs courantes imapsync et Mailcow
535 5.7.3 Authentication unsuccessful — Vérifier que le mot de passe est le mot de passe applicatif généré dans la console WorkMail, pas le mot de passe SSO/fédéré. Les organisations avec Active Directory doivent configurer les credentials IMAP séparément.
SSL connect attempt failed error:14090086 — Ajouter --ssl1 --tls1 pour forcer TLS 1.2. Vérifier le certificat Mailcow avec openssl s_client -connect mail.votredomaine.com:993.
Connection refused on port 993 — Mailcow n'écoute pas encore sur IMAPS. Vérifier avec docker compose -f /opt/mailcow-dockerized/docker-compose.yml ps que le conteneur dovecot-mailcow est Up.
Quota exceeded on host2 — Augmenter le quota dans Mailcow (Configuration → Mail Setup → Mailboxes) avant de relancer imapsync.
Migration lente ou déconnexions — Ajouter --maxbytespersecond 500000 pour limiter le débit. Lancer imapsync dans un screen ou tmux pour survivre aux interruptions SSH : screen -S migration imapsync ...
Conclusion — agir avant le 31 mars 2027
La fermeture d'AWS WorkMail est une décision définitive. La fenêtre de migration est courte : entre la propagation DNS, la vérification de la délivrabilité et la migration IMAP des boîtes volumineuses, comptez une à deux semaines de travail pour une organisation de taille modeste.
Le chemin le plus sûr reste celui décrit ici : exporter d'abord les données vers S3 (sauvegarde irréversible avant toute manipulation), migrer les emails via imapsync pendant que WorkMail est encore actif, valider la délivrabilité sur Mailcow avant de couper, puis basculer le MX et désactiver les comptes WorkMail.
Pour les grandes organisations avec des dizaines de boîtes et des volumes importants, prévoir une période de co-existence de deux à quatre semaines où les deux systèmes sont actifs, avec redirection automatique des messages WorkMail vers Mailcow via une règle de transfert, avant la coupure DNS définitive.
