Migrar correo entre proveedores: carpetas y duplicados

Migrar el correo de un proveedor a otro parece sencillo hasta que un buzón se copia dos veces o no aparece el historial de enviados. El correo no es una colección de archivos: la migración necesita comprender carpetas e identidades.

Copias datos IMAP activos entre dos servidores con reglas de carpetas y comportamiento UID distintos. Una suposición incorrecta puede dejar carpetas aparentemente vacías, conversaciones duplicadas o correo repartido entre ambos sistemas.

Utiliza un proceso gradual, correspondencias de carpetas claras y verificaciones tras el cambio. Para planificar proveedores, precios y control de las cuentas, consulta el correo para empresas. Aquí nos centramos en la migración.

Si vas a TrekMail, empieza por la introducción a la migración IMAP y las instrucciones de Gmail o cPanel según tu origen. El texto describe migración IMAP en servidor en planes de pago desde $3.50 al mes, Nano gratuito sin tarjeta y una prueba de 14 días para planes de pago. Confirma funciones, disponibilidad y condiciones actuales.

Qué se transfiere al migrar correo entre proveedores

Una herramienta IMAP accede al buzón antiguo, lee mensajes y carpetas y los copia al nuevo. No normaliza automáticamente nombres, elimina duplicados del origen ni coordina DNS salvo que el proceso implemente esas tareas.

Es una copia entre dos sistemas. El origen puede mantenerse intacto mientras el destino recibe mensajes, estructura de carpetas e indicadores compatibles, como leído o no leído, cuando el origen los informa. Contactos, calendarios y reglas no forman parte de esta copia IMAP. Comprueba el alcance y las diferencias de identificación.

El RFC 3501 describe UID y UIDVALIDITY por carpeta IMAP. Identifican mensajes dentro de esa carpeta y la generación definida por UIDVALIDITY; no son identificadores globales compartidos entre servidores. Una herramienta que dependa de ese estado puede perder la relación con copias anteriores si cambia.

Por eso una primera pasada correcta no garantiza que una segunda no duplique mensajes. El estado «completado» del panel tampoco sustituye la verificación del resultado.

Por qué aparecen duplicados al migrar correo

Una causa posible es perder la correspondencia de identidad: cambios de UIDVALIDITY, carpetas recreadas o etiquetas Gmail tratadas como carpetas independientes. Según el método de comparación, la herramienta puede volver a copiar datos ya transferidos.

UIDVALIDITY y estado de sincronización

Algunas herramientas mantienen correspondencias UID por carpeta; otras usan cabeceras u otros criterios. Reindexar no cambia necesariamente los UID, pero recrear una carpeta o perder el estado puede afectar a la comparación. Revisa el mecanismo concreto antes de repetir un trabajo.

El RFC 3501 vincula la estabilidad UID con UIDVALIDITY. Si cambia esa generación, los UID anteriores dejan de identificar fiablemente los mensajes actuales de la carpeta. Una segunda pasada podría volver a copiar miles de mensajes si no utiliza otros criterios fiables.

Ejemplo: se copian 38,000 mensajes de la bandeja de entrada. Tras un tiempo de espera agotado, se repite el trabajo, pero una carpeta fue reconstruida durante la noche. Si la herramienta pierde su correspondencia y no detecta las copias existentes, podría añadir otros 38,000 mensajes.

Las etiquetas de Gmail

Gmail no funciona exactamente como un servidor de carpetas tradicional. Un mensaje puede tener varias etiquetas y los archivados aparecen en Todos. Archivar retira el mensaje de la bandeja de entrada sin eliminarlo de Todos.

Importar [Gmail]/All Mail junto a carpetas de etiquetas puede representar el mismo mensaje varias veces en el destino. A veces conservar esas copias por carpeta es intencional; define si buscas mensajes únicos, equivalencia de etiquetas o ambas cosas y estima el almacenamiento.

La guía de importación desde Gmail orienta el acceso. El importador TrekMail usa credenciales IMAP directas. Las contraseñas de aplicación dependen de verificación en dos pasos y políticas de la cuenta; pueden no estar disponibles. En ese caso, valora otro método autorizado o una herramienta compatible con OAuth, sin suponer soporte interactivo del importador.

Este ejemplo de línea de comandos no es seguro para todos los casos: excluir Todos puede omitir mensajes archivados sin otra etiqueta. Planifica cómo copiar todos los archivados antes de usarlo, protege las credenciales y verifica cifrado y certificados de las conexiones:

imapsync \
  --host1 imap.gmail.com \
  --user1 user@gmail.com \
  --password1 'APP_PASSWORD' \
  --host2 mail.newhost.com \
  --user2 user@example.com \
  --password2 'DEST_PASSWORD' \
  --exclude "\\[Gmail\\]/All Mail" \
  --useheader "Message-ID" \
  --dry

La simulación no copia mensajes ni prueba una transferencia completa. Message-ID puede faltar, repetirse o no ser fiable; no basta siempre para evitar duplicados. Evita contraseñas reales en el historial del shell o la lista de procesos y haz una prueba limitada de copia y contenido. La guía de imapsync amplía las opciones operativas.

Por qué algunas carpetas no aparecen

Una carpeta puede haber llegado a otra jerarquía, con un nombre de sistema diferente o un prefijo que el cliente no muestra. También puede haber fallado la copia: verifica el servidor antes de concluir que solo es un problema visual.

Espacios de nombres y separadores

Los servidores usan separadores y espacios de nombres distintos. Puedes encontrar INBOX.Sent, Inbox/Sent Items o un prefijo obligatorio INBOX..

Sin correspondencias revisadas, Project.Alpha podría convertirse en una subcarpeta de Project. Una carpeta especial puede aparecer como personalizada, y el cliente móvil suscribirse a otra o esconderla.

Carpetas de enviados

Un servidor usa Sent, otro Sent Items y otro Sent Messages. Verifica nombres y atributos de uso especial del destino, además de la configuración del cliente.

Si la carpeta original se copia como personalizada sin asociarla a la de enviados, la carpeta predeterminada puede parecer vacía aunque el historial esté en otro lugar. Comprueba que los mensajes realmente se copiaron.

Para alojamiento compartido, consulta la migración desde cPanel u otros proveedores. Ayuda a identificar los datos de acceso habituales, pero necesitas probar credenciales, permisos y carpetas de tu origen.

Plan de migración en 3 fases

Un proceso de tres fases puede reducir riesgos: prepara el histórico, sincroniza cambios cerca del cambio de proveedor y vuelve a comprobar lo recibido en el antiguo tras cambiar MX. No garantiza ausencia de interrupciones ni duplicados; adapta el proceso y la reversión al entorno.

1. Sincronización histórica. Copia primero el correo antiguo; una ventana de más de 30 días es ilustrativa. Los usuarios pueden seguir trabajando en el origen mientras controlas los cambios.
2. Sincronización de cambios. Ejecuta una segunda pasada para nuevas llegadas y cambios pertinentes, incluidos movimientos e indicadores. Abarca llegadas tardías con fecha antigua, no solo un filtro de mensajes recientes. Conserva el estado y verifica la comparación con el histórico importado.
3. Transición y repasos finales. Cambia MX tras las pruebas. Mantén recepción en el antiguo mientras existan cachés y reintentos, incluso después del TTL, y realiza las pasadas adicionales necesarias, no una única barrida garantizada.

Los errores DNS pueden mantener envíos en el origen o provocar rechazo. Consulta los registros DNS necesarios durante la planificación del cambio.

; Example cutover records
@      MX   10 mail.trekmail.net.
@      TXT     "v=spf1 include:spf.trekmail.net -all"
_dmarc TXT     "v=DMARC1; p=quarantine;"

Son ejemplos, no registros listos para publicar: verifica el panel de tu cuenta, conserva todos los remitentes SPF legítimos, verifica DKIM alineado y no cambies a cuarentena sin inventario y pruebas. Tras verificar la migración y actualizar clientes, puedes limitar el acceso de usuarios al origen para evitar enviados repartidos. No apagues inmediatamente su recepción ni elimines datos mientras haya entregas pendientes o una ventana de reversión.

La planificación gradual también ayuda a agencias con varias marcas. La gestión dispersa es un problema adicional a la copia: consulta el alojamiento de correo para varios dominios para valorar una administración centralizada.

Comprobaciones después de migrar

Compara recuentos, fechas extremas y jerarquías, además de muestras de contenido, adjuntos e indicadores. El tamaño total no basta: compresión, índices y representación de mensajes pueden variar sin pérdida de datos.

1. Comparar mensajes y correspondencias

Si había 4,502 elementos en la bandeja de entrada, espera 4,502 en la carpeta equivalente con el mismo alcance y exclusiones aprobadas, sin cambios recientes ni otra representación prevista. Un recuento igual no prueba integridad: compara contenido, adjuntos, fechas e indicadores. En Gmail, distingue mensajes únicos de copias por etiqueta.

2. Revisar las fechas extremas

Compara los mensajes más antiguos y recientes en bandeja de entrada y enviados. Si faltan, investiga filtros, correspondencias y pasadas históricas o de cambios; la fecha sola no demuestra cuál falló.

3. Buscar carpetas sin asociar

Busca INBOX.Sent en la raíz, restos de [Gmail] o varias carpetas de enviados. Pueden señalar correspondencias incorrectas, aunque algunas representaciones sean intencionales.

4. Probar recepción y envío

Envía desde una cuenta externa y responde desde el destino. Verifica llegada, autenticación y la carpeta donde se guarda la respuesta. Amplía las pruebas a los flujos importantes.

5. Actualizar los clientes

Una copia correcta puede parecer incompleta si el cliente sigue conectado al servidor anterior. Actualiza IMAP y SMTP según las instrucciones del destino y comprueba carpetas, suscripciones y acceso de cada usuario.

Por eso copia y sustitución del proveedor deben planificarse juntas. La alternativa a Titan Email trata el mismo cambio desde la perspectiva del proveedor: copiar el buzón es solo una parte.

Gestión manual y migración con TrekMail

La gestión manual puede exigir tareas repetidas y correspondencias específicas. TrekMail describe migración IMAP en servidor, almacenamiento compartido y un panel para dominios, buzones y DNS según el plan. Comprueba detección de duplicados y cobertura real; ningún panel sustituye las pruebas.

Centralizar puede reducir tareas en un equipo o agencia. Trabajar en un lugar en vez de cinco es una ilustración, no un ahorro garantizado. Consulta los precios actuales de TrekMail; Nano y la prueba de 14 días de planes de pago dependen de la disponibilidad y condiciones vigentes.

Conclusión

Si necesitas migrar el correo entre proveedores, trata el proceso como una transición IMAP controlada, no una copia masiva sin comprobaciones. Define carpetas y cobertura de archivados Gmail, prueba transferencias, sincroniza cambios y verifica datos y clientes. Retira el acceso antiguo solo cuando corresponda, conservando recepción y reversión el tiempo necesario; no prometas ausencia de pérdidas o interrupciones.

Para valorar TrekMail como destino, visita trekmail.net. Compara su alojamiento multidominio, modelo de plataforma, almacenamiento compartido y migración IMAP con los recursos y límites actuales. No presupongas que cualquier alta de usuario carece de coste adicional.