AWS WorkMail EOL — calendario y qué implica
AWS publicó el aviso de fin de soporte en la página oficial de documentación de WorkMail. Dos fechas son irrevocables: 30 de abril de 2026 — cese de inscripciones para nuevos clientes; 31 de marzo de 2027 — eliminación de todas las cuentas, buzones, calendarios y contactos, sin posibilidad de recuperación tras esa fecha.
En la práctica, los recursos de WorkMail quedarán inaccesibles el 1 de abril de 2027: la consola AWS, las APIs, los clientes IMAP y los conectores Exchange ActiveSync dejan de responder simultáneamente. AWS no ha anunciado ninguna prórroga ni modo de solo lectura posterior. Todo lo que no se exporte antes del 31 de marzo de 2027 se pierde definitivamente.
La urgencia depende del volumen de tu buzón: un buzón de 10 GB puede tardar varias horas en exportarse a S3, y la migración IMAP con imapsync dura proporcionalmente al número de mensajes. Comenzar la migración tres meses antes del plazo es un mínimo razonable. Lo ideal es que el cambio de DNS se realice antes de finales de enero de 2027, dejando suficiente tiempo para supervisar la entregabilidad y corregir posibles problemas antes de la eliminación definitiva.
Por qué Mailcow y no Stalwart u otra alternativa
AWS recomienda Kopano Cloud, Zoho Mail y Zoom Mail como alternativas. Estas soluciones siguen siendo SaaS — cambias de proveedor sin recuperar el control.
Si quieres una infraestructura de correo que controles completamente, Mailcow es la opción más probada para migrar desde un servicio de correo alojado. Su stack Docker Compose combina Postfix, Dovecot, Rspamd y SOGo en una interfaz de administración unificada. La migración IMAP está bien documentada, la comunidad es activa y el soporte IMAP entrante nativo facilita la importación con imapsync.
Stalwart es una alternativa seria (ver el artículo dedicado), pero su arquitectura de binario único es más adecuada para una instalación desde cero que para una migración desde WorkMail. Para una migración WorkMail, Mailcow es la elección pragmática.
Requisitos previos antes de empezar
Tres recursos son necesarios antes de iniciar la migración:
VPS con al menos 6 GB de RAM. El stack Mailcow (Postfix, Dovecot, Rspamd, MariaDB, Redis, ClamAV, SOGo y el proxy nginx) consume entre 3 y 4 GB bajo carga normal. Con 6 GB, dispones de margen cómodo para imapsync y los picos de carga durante la migración.
Acceso administrador a la consola AWS WorkMail. La exportación de buzones pasa por la API de AWS — necesitas permisos IAM suficientes para crear un rol de exportación, acceder a S3 y lanzar los trabajos de exportación via CLI.
Un nombre de dominio con acceso DNS. El corte DNS (registros MX, SPF, DKIM, DMARC) es el paso final — sin acceso a tu zona DNS, no puedes redirigir el correo entrante a Mailcow.
Lista detallada de requisitos previos
- VPS Linux 64 bits (Debian 12 o Ubuntu 22.04 recomendados), mínimo 6 GB RAM / 2 vCPU / 40 GB de almacenamiento.
- IP dedicada con PTR (DNS inverso) configurado con el nombre de host del servidor de correo.
- Puerto 25 saliente desbloqueado por el proveedor de alojamiento — verificar antes de contratar.
- Puertos 25, 465, 587, 993 y 143 abiertos en el firewall del VPS.
- Acceso AWS IAM con permisos
workmail:StartMailboxExportJob,s3:PutObjectykms:GenerateDataKey. - Un bucket S3 privado en la misma región AWS que tu organización WorkMail.
- Una clave KMS simétrica en la misma región (requerida por la API de exportación de WorkMail).
- Acceso DNS al dominio para modificar MX, SPF, DKIM y DMARC.
- Docker y Docker Compose instalados en el VPS de destino.
Exportar tus datos de AWS WorkMail
Crear el rol IAM y las políticas de exportación
La exportación de WorkMail requiere un rol IAM dedicado. Crea dos archivos JSON locales:
mailbox-export-trust-policy.json(política de confianza para WorkMail):{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": { "Service": "export.workmail.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "YOUR-ACCOUNT-ID" } } }] }Crea el rol 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.jsonObtener los identificadores de la organización y los usuarios
La API de exportación requiere el ID de la organización WorkMail y el ID de entidad de cada usuario. Obtenerlos desde la consola AWS WorkMail o via CLI:
aws workmail list-organizationsaws workmail list-users --organization-id m-XXXXXXXXXXXXAnota el
OrganizationId(formatom-xxxxx) y elUserIdde cada buzón a exportar.Lanzar el trabajo de exportación a S3
Lanza un trabajo de exportación por buzón:
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 your-bucket --s3-prefix exports/user1/La API admite hasta 10 trabajos de exportación simultáneos por organización.
Supervisar el estado de los trabajos de exportación
Comprueba el progreso con:
aws workmail list-mailbox-export-jobs --organization-id m-XXXXXXXXXXXXCuando el estado cambie a
COMPLETED, el archivo.zipestará disponible en S3. El log de salida indicatotalMessages,totalBytesysha384Hashpara verificación de integridad.Descargar y verificar los archivos exportados
Descarga los archivos desde S3:
aws s3 sync s3://your-bucket/exports/ ./workmail-exports/Verifica el recuento de mensajes en el archivo:
unzip -l workmail-exports/user1/*.zip | tail -1Extraer archivos .eml para imapsync
imapsync trabaja en modo IMAP-to-IMAP — no importa directamente archivos
.zipni.emldel disco. El enfoque recomendado es configurar imapsync para leer directamente desde el servidor IMAP de WorkMail antes de cortar el acceso. Los archivos S3 sirven como copia de seguridad de seguridad.
Instalar Mailcow en VPS
Preparar el VPS y configurar el hostname
Define un hostname FQDN coherente con el futuro registro PTR:
hostnamectl set-hostname mail.tudominio.comVerifica que
hostname -fdevuelva el FQDN completo. Configura el PTR para la IP del VPS desde el panel de tu proveedor de alojamiento.Clonar Mailcow y ejecutar el instalador
Consulta el artículo dedicado Alojar un servidor de correo en VPS con Mailcow para la instalación completa. En resumen:
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow-dockerizedcd /opt/mailcow-dockerized && ./generate_config.shdocker compose pull && docker compose up -dCrear dominios y cuentas en Mailcow
En la interfaz Mailcow (Configuration → Mail Setup), añade el dominio y crea una cuenta para cada usuario WorkMail a migrar. Las direcciones deben ser idénticas a las de WorkMail para que imapsync pueda emparejar los buzones.
No cambies los registros MX todavía — Mailcow puede aceptar conexiones IMAP sin ser el MX activo.
Migrar los correos con imapsync
Instalar imapsync en el VPS
En Debian/Ubuntu:
apt-get install -y imapsyncVerifica la instalación:
imapsync --versionMigrar un buzón WorkMail a Mailcow
El servidor IMAP de AWS WorkMail en us-east-1 es
imap.mail.us-east-1.awsapps.com(puerto 993, SSL). Ajusta la región si es necesario.`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'ContrasenaWorkMail' \
--host2 mail.tudominio.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'ContrasenaMailcow' \
--automap --skipcrossduplicates --useuid`Migrar todos los buzones en paralelo
Para organizaciones con múltiples usuarios, ejecuta las migraciones en paralelo con un script. Limita a 4-6 migraciones simultáneas para no saturar el ancho de banda. Monitorea los logs en
/var/log/imapsync-*.log.Ejecutar una pasada de sincronización final
Vuelve a ejecutar imapsync justo antes del corte DNS para sincronizar los correos recibidos desde la primera migración:
`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'ContrasenaWorkMail' \
--host2 mail.tudominio.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'ContrasenaMailcow' \
--automap --skipcrossduplicates --useuid --delete2duplicates`
DNS cutover — MX, SPF, DKIM, DMARC
Una vez completada y verificada la migración IMAP, el corte DNS redirige el correo entrante a Mailcow. No cortes antes de verificar la entregabilidad (ver la sección siguiente).
Paso 1 — Registro MX. Reemplaza la entrada MX existente (que apunta a WorkMail) con tu servidor Mailcow:tudominio.com. MX 10 mail.tudominio.com.
Verifica la propagación: dig MX tudominio.com +short
Paso 2 — SPF. Elimina la autorización de WorkMail y autoriza tu VPS:tudominio.com. TXT "v=spf1 mx a:mail.tudominio.com -all"
Paso 3 — DKIM. Mailcow genera las claves DKIM desde la interfaz (Configuration → ARC/DKIM Keys). Copia el registro TXT generado en tu DNS.
Paso 4 — DMARC. Actualiza la política DMARC:_dmarc.tudominio.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
Reduce el TTL de todos estos registros a 300 segundos una hora antes del corte para acelerar la propagación.
Prueba la entregabilidad antes de cortar AWS
Antes de modificar el MX, envía un correo desde Mailcow y comprueba la puntuación en mail-tester.com — una puntuación de 9/10 o superior es el umbral aceptable para producción.
Verifica también con swaks desde el propio VPS:swaks --to [email protected] --from [email protected] --server mail.tudominio.com --port 587 --auth LOGIN --auth-user [email protected] --tls
Inspecciona las cabeceras del mensaje recibido — la cabecera Authentication-Results debe mostrar spf=pass, dkim=pass y dmarc=pass. Si alguno falla, no cambies el MX — corrige primero el registro DNS defectuoso.
Resolución de problemas — errores comunes de imapsync y Mailcow
IMAP Command 'LOGIN' failed: 535 5.7.3 Authentication unsuccessful — Las credenciales de WorkMail son rechazadas. Verifica que la contraseña sea la contraseña de aplicación generada en la consola WorkMail.
SSL connect attempt failed error:14090086 — Versión TLS incompatible o certificado caducado. Añade --ssl1 --tls1 para forzar TLS 1.2. Verifica el certificado Mailcow con openssl s_client -connect mail.tudominio.com:993.
Can't login to host2... Connection refused on port 993 — Mailcow aún no escucha en el puerto IMAPS. Verifica que todos los contenedores estén activos con docker compose -f /opt/mailcow-dockerized/docker-compose.yml ps.
Quota exceeded on host2 — El buzón destino ha alcanzado su límite de cuota en Mailcow. Aumenta la cuota desde la interfaz Mailcow antes de relanzar imapsync.
Migración muy lenta o desconexiones aleatorias — Añade --maxbytespersecond 500000 para limitar el throughput. Ejecuta imapsync dentro de una sesión screen o tmux para evitar interrupciones:screen -S migration imapsync ...
Conclusión — actúa antes del 31 de marzo de 2027
El cierre de AWS WorkMail es una decisión definitiva. La ventana de migración es corta: entre la propagación DNS, la verificación de entregabilidad y la migración IMAP de buzones voluminosos, cuenta con una a dos semanas de trabajo para una organización mediana.
El camino más seguro es el descrito aquí: primero exporta datos a S3 (copia de seguridad irreversible antes de cualquier manipulación), migra los correos via imapsync mientras WorkMail sigue activo, valida la entregabilidad en Mailcow antes de cortar, y luego cambia el MX y desactiva las cuentas WorkMail.
Para grandes organizaciones con decenas de buzones y volúmenes elevados, planifica un período de coexistencia de dos a cuatro semanas donde ambos sistemas estén activos, con reenvío automático de mensajes WorkMail a Mailcow, antes del corte DNS definitivo.
