Migrar cuentas de correo: varios buzones y cambio MX

Migrar cuentas de correo de una empresa no es lo mismo que copiar una bandeja personal. Siguen llegando mensajes, los usuarios responden y los alias distribuyen correo; un registro DNS omitido puede repartir entregas entre dos sistemas. Inventaría primero, prepara la copia después y cambia la recepción al final. Para el contexto empresarial, consulta esta guía de correo para empresas antes de tocar DNS.

El problema es conocido: alguien exporta PST, otro arrastra carpetas en Outlook y se supone que todas las direcciones son buzones. El lunes sales@ deja de recibir, un buzón grande sigue copiándose y nadie sabe qué servidor tiene los datos completos. Trata la migración como infraestructura activa, no como una copia de archivos.

Esta guía explica cómo migrar cuentas de correo con un proceso operativo controlado. Incluye la vía manual IMAP, el orden del cambio, los fallos importantes y la opción integrada de TrekMail para equipos, agencias y proveedores de servicios que prefieren reducir el mantenimiento de scripts.

Qué significa migrar cuentas de correo

Copias el contenido entre servidores IMAP, reconstruyes alias y reenvíos y, si trasladas la recepción de un dominio propio, cambias DNS cuando el destino está listo. La copia no transfiere automáticamente la dirección de una cuenta personal ni garantiza ausencia de pérdidas.

La distinción importa porque IMAP copia carpetas y estados compatibles, no todo lo que rodea al buzón. El RFC 3501 describe acceso y manipulación de mensajes, no exportación completa de la identidad empresarial.

En realidad, son tres tareas:

1. Copiar mensajes y estructura de carpetas.
2. Reconstruir alias, listas de distribución y reenvíos con sus permisos.
3. Cambiar DNS en el momento adecuado si se traslada la recepción de un dominio bajo tu control.

Omitir una tarea necesaria deja la migración incompleta y puede generar incidencias de soporte.

Qué copia IMAP y qué queda fuera

IMAP permite copiar mensajes, carpetas y normalmente el estado de lectura si el origen y la herramienta lo admiten. No copia calendarios, contactos, tareas, firmas locales ni reglas de clientes o servidores; prepara un proceso separado antes de que los usuarios esperen encontrarlos.

Define el alcance por escrito. La migración de TrekMail es IMAP; no equivale a clonar una plataforma colaborativa. Sus instrucciones se centran en servidor, puerto, usuario, contraseña y buzón de destino, no en calendarios o planificación compartida.

Usa esta referencia al migrar cuentas:

La última fila suele pasarse por alto. Revisa esta guía de alias y buzones para distinguir direcciones de distribución de buzones reales y reducir correcciones posteriores.

Inventario antes de migrar

Antes de sincronizar, inventaría buzones, alias, grupos, reglas de reenvío, cuotas y cuentas grandes. Asigna a cada objeto su destino y su tanda de migración.

Exportar usuarios no basta: también necesitas los objetos menos visibles.

Como mínimo, revisa:

1. Buzones principales: cuentas activas, compartidas y de función.
2. Alias: direcciones alternativas que entregan en otro buzón.
3. Listas o grupos: objetos de distribución que no son buzones IMAP normales.
4. Reenvíos: reglas del servidor como info@ hacia owner@, con permisos y restricciones.
5. Dirección comodín: decide si conservarla, restringirla o retirarla.
6. Buzones grandes: dales margen y una preparación temprana.

Los buzones grandes condicionan el calendario. El proveedor puede limitar IMAP y una copia puede durar días en lugar de horas. No prometas terminar un fin de semana si hay años de adjuntos sin política de archivo.

Ejemplo ilustrativo: programas el cambio el viernes para 60 usuarios. Un directivo tiene 48 GB. El domingo han terminado 59 usuarios y ese buzón sigue sincronizando. El tamaño y los límites debían incorporarse al plan, no tratarse como un plazo garantizado.

Si también normalizas la creación de cuentas, utiliza un inventario de aprovisionamiento como esta guía de creación masiva de cuentas. Los errores pueden empezar en esa preparación, no solo en DNS.

Plan por tandas para varios buzones

Usa tandas en vez de un cambio único. La prueba piloto valida credenciales, carpetas y acceso; la preparación copia el histórico; la tanda final coordina cambios y transición de recepción.

Esta es la secuencia práctica:

Tanda 1: prueba piloto

Empieza con una muestra pequeña: personal técnico, cuentas de prueba y un usuario con un buzón representativo. Comprueba TLS, cadena de certificados y nombre del servidor en 993, credenciales y correspondencias de enviados, borradores, archivo y carpetas propias.

Tanda 2: copia previa

Empieza antes del fin de semana previsto. Copiar el histórico con antelación evita depender de años de correo mientras el nuevo MX ya está activo.

Tanda 3: cambios y transición

Verifica la copia previa y el destino antes de cambiar MX para tu propio dominio. Sincroniza los cambios y repite las pasadas después: incluye llegadas tardías con fecha antigua, movimientos e indicadores. Mantén recepción y acceso administrativo al origen mientras cachés y reintentos SMTP puedan llevarle mensajes.

Así reduces dependencia de límites del proveedor, trabajo apresurado y sorpresas para los usuarios, sin garantizar una transición sin incidencias.

La vía manual con imapsync

Para control directo, puedes usar una herramienta IMAP a IMAP como imapsync. Sus opciones de reintentos, carpetas e indicadores permiten un proceso más reproducible, pero dependen de la versión y de una configuración comprobada.

Arrastrar mensajes, exportar PST o improvisar comandos puede producir resultados difíciles de auditar. Si usas un cliente, copia sin eliminar el origen y verifica el resultado.

Una ejecución por lotes con registro por buzón y pasadas de cambios definidas facilita el seguimiento. TrekMail ofrece un flujo integrado con esa lógica según sus funciones actuales. Para la operación manual, consulta la guía de imapsync.

Este patrón es ilustrativo, no un script listo para ejecutar: la cabecera no es válida para ejecución directa. Revisa y corrige una copia local para la versión elegida, con sus opciones y el servidor IMAP real del destino. La opción de log es booleana, no define el nombre del archivo. La lectura con comas no interpreta CSV con comillas; contraseñas con comas o saltos de línea pueden romperla. Protege archivos de credenciales, procesos y registros, y activa la verificación de certificados:

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

Algunas notas prácticas:

Caché según el método. Puede reducir lecturas repetidas de metadatos, pero no prueba integridad ni evita todos los duplicados. Los UID no son globales entre servidores; conserva y valida el estado de comparación.

Carpeta de preparación cuando convenga. Separar importados ayuda a revisar actividad en ambos sistemas. Sin embargo, cambia su ubicación y no los convierte automáticamente en las carpetas de producción ni demuestra ausencia de duplicados. Tampoco resuelve escrituras simultáneas en ambos sistemas: planifica el paso a un único entorno activo y revisa movimientos, indicadores y eliminaciones sin sincronización destructiva a ciegas.

Registros por buzón. Identifica qué falló y por qué. El mensaje de finalización se imprime aunque el comando falle: comprueba códigos de salida y registros, además de recuentos, contenido e indicadores. Restringe permisos al propietario y oculta credenciales en registros compartidos.

Transición DNS controlada

Para trasladar la recepción de un dominio propio, reduce TTL con antelación, espera la caducidad de cachés anteriores y prepara la sustitución MX. Publica el destino solo después de validar buzones, alias y copia previa; conserva recepción antigua, sincronizaciones y reversión para llegadas tardías.

Terminar una copia no cambia la recepción. DNS indica el destino de nuevos mensajes cuando sus respuestas actualizadas llegan a cada emisor; las cuentas personales no permiten cambiar MX del dominio del proveedor.

Durante la transición, cachés y reintentos pueden repartir mensajes entre sistemas. Ambos pueden parecer parcialmente activos: supervisa y reconcilia esos flujos en vez de apagar el origen prematuramente.

Comprueba registros reales en el panel y la documentación TrekMail. El ejemplo siguiente es esquemático: conserva todos los emisores legítimos en SPF, usa el valor DKIM de la cuenta y no apliques cuarentena sin inventario, pruebas y un plan de reversión:

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

Durante el cambio, comprueba:

1. MX antiguos retirados del conjunto publicado cuando corresponda, con recepción antigua temporal.
2. MX nuevo publicado y comprobado en resolutores relevantes.
3. Una política SPF por nombre, conservando todos los servicios que aún envían.
4. DKIM configurado y firma válida comprobada en mensajes reales.
5. DMARC adecuado: SPF válido y alineado o alguna firma DKIM válida y alineada, sin exigir ambos para el resultado del protocolo.
6. Prueba recibida en el destino y supervisión de llegadas tardías al origen.

Después, utiliza Google Postmaster Tools si tienes tráfico Gmail y datos disponibles. Revisa autenticación en cabeceras del receptor de confianza; los informes son parciales y la copia final no sustituye pruebas de recepción y envío.

La opción integrada TrekMail

El texto describe importación IMAP en servidor desde otro proveedor mediante el panel TrekMail. Puede reducir la necesidad de una máquina propia y scripts, según el plan y la compatibilidad, pero exige supervisión y validación.

La diferencia operativa puede resumirse así:

Prepara el flujo actual comprobando estas etapas:

1. Añade el dominio y prepara DNS sin cambiar recepción prematuramente.
2. Crea buzones, alias y demás objetos necesarios en el destino.
3. Abre Migración en el panel.
4. Introduce servidor IMAP, puerto y credenciales autorizadas del origen.
5. Selecciona el buzón TrekMail de destino.
6. Importa, revisa estado y datos, y coordina después la transición y sus pasadas adicionales.

Confirma los procedimientos en introducción a la migración IMAP, iniciar una migración en el panel, crear un buzón y registros DNS necesarios. El importador usa credenciales IMAP directas; las contraseñas de aplicación Gmail dependen de verificación en dos pasos y políticas de la cuenta. Si OAuth es obligatorio, prepara otro acceso autorizado compatible, sin asumir soporte interactivo del importador. Respalda correo local sin sincronizar antes de retirar perfiles de clientes.

El texto presenta Starter a partir de $3.50 al mes, Nano a $0 y planes Starter, Pro, Agency y Enterprise. Describe Nano gratuito sin tarjeta y prueba gratuita de 14 días de planes de pago con tarjeta de crédito. Verifica condiciones actuales. El almacenamiento compartido puede facilitar buzones desiguales, sin eliminar cuotas ni garantizar que nunca necesites ampliar el plan.

Compara directamente los precios de TrekMail.

Comprobaciones finales para equipos activos

Antes del cambio MX de un dominio propio, revisa alias, DNS, credenciales y sincronización de buzones grandes. Una lista breve puede detectar riesgos de entrega y datos, aunque no garantiza que todos los errores queden excluidos.

Revisa antes de cambiar:

1. Todos los buzones de destino existen y permiten acceso.
2. Alias, reenvíos y grupos reconstruidos con permisos y pruebas.
3. Acceso IMAP de origen con TLS y certificados comprobados en 993.
4. Buzones grandes copiados con antelación y verificados.
5. TTL reducido y cachés anteriores consideradas.
6. Valores MX antiguos documentados para comprobar cambio y reversión.
7. Pasadas de cambios posteriores al cambio programadas.
8. Usuarios informados sobre cuándo dejar de modificar reglas y escribir en el origen.
9. Un buzón de prueba listo para recepción y envío.
10. Responsable de supervisión asignado, con recepción antigua y acceso administrativo conservados mientras hagan falta.

No es un trabajo vistoso: reducir sorpresas antes del cambio mejora el control de la migración.

Conclusión: un proceso, no una apuesta

Para migrar cuentas de correo de un dominio o cincuenta, inventaría identidades, prepara datos, cambia DNS cuando corresponda y verifica los flujos después. IMAP hace la copia del buzón; no corrige por sí solo un diseño incompleto.

La vía manual permite control directo si mantienes las herramientas y sus pruebas. Si migras a menudo, compara TrekMail por su modelo multidominio, almacenamiento compartido, importación y panel operativo, según funciones y límites actuales. Evalúa Nano o consulta los precios si necesitas migración en un plan de pago.