Trasladar el correo de Gmail: guía de migración IMAP

Para trasladar el correo de Gmail, lo difícil no es solo copiar mensajes. Debes mantener alias, etiquetas, DNS y accesos mientras sigue circulando correo. Muchos proyectos fallan durante el cambio, no durante la copia.

Esta guía explica cómo pasar de Gmail o Google Workspace a otro proveedor reduciendo duplicados, rechazos inadvertidos e incidencias del lunes. Es un procedimiento práctico para operadores, fundadores, agencias y administradores, no una presentación comercial.

Por qué fallan las migraciones de Gmail

Trata Gmail como un sistema con características propias, no como otro servidor IMAP cualquiera. Etiquetas, alias, límites de velocidad y tiempos DNS pueden convertir una migración aparentemente correcta en duplicados y mensajes ausentes.

Muchos proveedores guardan cada mensaje en una carpeta. Gmail utiliza un almacén de mensajes y presenta etiquetas como carpetas. Una herramienta IMAP genérica puede leer el mismo mensaje bajo varias etiquetas y copiarlo varias veces, aumentando el tamaño y confundiendo a los usuarios.

Ejemplo: una factura aparece en Inbox, Finance y Q1 de Gmail. Una herramienta básica puede interpretarla como tres mensajes si no adaptas las etiquetas y evitas sincronizar All Mail de forma inadecuada.

La segunda dificultad son los límites. Google determina el ritmo de acceso al origen. Los buzones grandes no siempre se ajustan a tu calendario y un exceso de carga puede ralentizar o detener la tarea. Reservar solo un fin de semana puede no bastar para dirección, buzones compartidos e históricos con muchos adjuntos.

La tercera es la identidad. Una dirección de ventas puede ser usuario, grupo, alias o punto de reenvío. Omitir su correspondencia puede provocar rechazos al cambiar los MX.

La cuarta es la entrega. Recibir y enviar son configuraciones distintas. SPF, DKIM o DMARC incorrectos pueden causar fallos de alineación o mensajes enviados a spam; configurarlos no garantiza llegar a Recibidos. Consulta los requisitos de Google para remitentes.

Para los fundamentos del protocolo, utiliza la introducción de TrekMail a la migración IMAP. IMAP traslada correo, no todo el entorno de Google.

Qué se traslada y qué queda fuera

Por IMAP suelen copiarse bien mensajes, adjuntos, estado de lectura y fechas. No ocurre lo mismo con los datos propios de Google. Definir bien el alcance hace el proceso más previsible.

Cuerpos, adjuntos, histórico y estructura básica pueden conservarse con buena fidelidad, sujeta a comprobación. IMAP utiliza la fecha interna del mensaje del servidor, parte del modelo descrito en el RFC 3501. El estado leído/no leído también suele trasladarse.

Así suele conservarse el registro empresarial esencial: conversaciones con clientes, facturas, aprobaciones, adjuntos e intercambios cotidianos.

La capa de Google es otra cosa. Docs, Sheets, permisos de Drive, historial de Meet y automatización administrativa no aparecen en un buzón IMAP estándar. Expórtalos por separado o mantenlos en su sistema.

Calendarios y contactos tampoco forman parte de IMAP. Aclara pronto que el correo y los datos colaborativos necesitan vías distintas para evitar expectativas y consultas inesperadas.

Revisa también las reglas. Años de filtros, estrellas, etiquetas y flujos de archivo no se recrean automáticamente en otro proveedor. El correo puede haberse copiado correctamente mientras falta la automatización que el usuario necesita.

Las identidades compartidas requieren especial atención. Un Google Group puede parecer una dirección normal, pero no es un buzón convencional. Distingue buzones, alias, grupos y reenvíos antes de empezar: copiar contenido no mantiene por sí solo la dirección operativa.

Para preparar el destino, conserva a mano los registros DNS necesarios de TrekMail. La copia es solo una parte del trabajo.

Auditoría previa al traslado

Inventaría usuarios, alias, grupos, tamaños y clientes. Este es el punto de control de toda la migración: lo que omitas puede causar incidencias al cambiar.

Empieza por los buzones activos y añade usuarios suspendidos, buzones compartidos, Google Groups, direcciones funcionales como billing@ y support@ y todos los alias. Una dirección supuestamente sin uso puede seguir recibiendo facturas o formularios.

Ordena después por tamaño, que influye en el calendario junto con los límites del origen. Los buzones pequeños pueden copiarse en segundo plano; los grandes necesitan preparación anticipada. Por encima de 10-15 GB conviene atención especial; más de 25 GB puede requerir un subproyecto.

Documenta los clientes: Outlook, Apple Mail y aplicación móvil de Gmail. No esperes al lunes. Outlook puede necesitar otro perfil; en móviles puede ser necesario retirar la cuenta antigua solo de la aplicación de correo y añadir IMAP, tras guardar datos locales no sincronizados, sin borrar la cuenta Google ni sus datos.

Guarda los valores DNS actuales: MX de Google, SPF, selectores DKIM y política DMARC. Necesitas un mapa de reversión aunque no lo uses.

Decide si cada dirección será buzón, alias o reenvío. La facturación por usuario ha llevado a sustituir buzones reales por alias para ahorrar. Revisar esa estructura puede mejorar el sistema. Consulta alias de dominio frente a buzón.

Con varias marcas o clientes, normaliza nombres y documenta buzones compartidos, catch-all, titularidad y autoridad para restablecer accesos. El modelo de gestión puede importar más que el comando de migración. Consulta el alojamiento de correo multidominio.

Cómo trasladar el correo de Gmail paso a paso

Una estrategia prudente es adelantar el histórico por IMAP, sincronizar antes del cambio DNS y verificar después. Conserva el origen y repite la sincronización de entregas posteriores. Esto reduce riesgos, sin garantizar ausencia de interrupciones.

Esta es la secuencia operativa:

1. Crea el dominio y los buzones en el destino.
2. Define correspondencias de buzones, alias, reenvíos y direcciones compartidas.
3. Empieza por sincronizar el histórico en segundo plano.
4. Ejecuta la pasada incremental prevista justo antes de cambiar los MX.
5. Mantén Gmail activo durante 24-48 horas como orientación inicial y sincroniza entregas tardías; no lo retires hasta completar las comprobaciones.

Prepara por completo el destino. En TrekMail, según el artículo fuente, el orden es dominio, buzón y migración. Crea los buzones del equipo antes de sincronizar para que cada usuario tenga un destino listo.

Consulta los ajustes IMAP y SMTP. Según el artículo fuente, los planes de pago incluyen migración del lado del servidor, empiezan en $3.50/mes y ofrecen prueba de 14 días con tarjeta. Nano se describe gratuito sin tarjeta, distinto de la prueba de pago; confirma las condiciones actuales.

Después prepara la autenticación del origen. Usa un método autorizado por el administrador y compatible con la configuración del buzón. Una contraseña de aplicación puede ser una opción si está permitida y disponible, no una garantía. Prueba un buzón piloto antes de poner toda la empresa en cola.

Revisa las etiquetas. Sincronizar todas junto con All Mail sin criterios adecuados puede duplicar mensajes. Define qué se convertirá en carpeta y qué excluirás. Copiar archivos innecesarios y repetidos consume tiempo y capacidad.

Programa la copia histórica mientras los usuarios siguen en Google y sincroniza correo reciente y cambios de estado cerca del cambio. Mantén pasadas posteriores para recoger lo que llegue al origen. Así limitas el impacto en equipos que siguen trabajando.

Para un procedimiento técnico más detallado, consulta la guía operativa de imapsync.

Cambio DNS con menos riesgo de perder correo

El cambio DNS necesita su propio procedimiento: bajar TTL con antelación, publicar autenticación antes de modificar los MX y conservar Google hasta recuperar y verificar las entregas tardías.

Dos días antes, reduce el TTL de MX a 300 segundos si el proveedor lo permite. Las cachés que ya tienen el TTL anterior seguirán respetándolo, por lo que el cambio no garantiza actualización inmediata.

Prepara la autenticación antes de los MX. Durante la coexistencia puede haber sistemas que siguen usando Google mientras otros envían desde el destino. SPF debe reflejar los emisores reales en un único registro combinado, no dos TXT SPF separados.

Publica también DKIM antes del cambio si el destino permite preparar la clave. Comprueba la firma desde los primeros mensajes; no presupongas su funcionamiento por haber publicado el registro.

DMARC expresa la política solicitada a los receptores cuando falla la alineación. No corrige DNS ni correspondencias de remitentes, y cada receptor decide cómo aplicarla. No garantiza rechazos ni llegada a Recibidos.

Durante la coexistencia llega correo al nuevo proveedor y también a Google. No canceles Workspace al cambiar los MX. Un día o dos es una referencia, no una condición suficiente: sincroniza lo pendiente y conserva el origen hasta confirmar el resultado.

Para una lista de configuración del dominio, consulta crear correo con tu dominio junto con la documentación DNS.

Ajustes de clientes tras el cambio

Los datos pueden estar bien y la experiencia parecer rota por perfiles en caché, expectativas OAuth antiguas y aplicaciones que siguen tratando el buzón como Google.

En móviles, editar un perfil Google no suele convertirlo en un perfil IMAP genérico. Tras guardar datos locales no sincronizados, retira únicamente el perfil de la aplicación de correo y vuelve a añadir el buzón como IMAP. No elimines la cuenta Google ni sus datos.

Outlook puede conservar el tipo antiguo de cuenta e intentar repararlo. Crear otro perfil puede ser más eficaz que corregir durante horas uno que sigue contactando Google; conserva primero los datos locales pendientes.

Los tamaños también inquietan. Google y otros proveedores calculan capacidad de manera distinta. Un buzón de 12 GB puede mostrar menos en el destino sin pérdida. Compara primero recuentos en carpetas clave, no gigabytes totales.

Lista práctica de validación:

1. El número de elementos de Inbox entra en el rango explicado y esperado.
2. El correo enviado existe y se abre.
3. Las conversaciones antiguas de varios años son legibles.
4. El correo entrante reciente llega al destino.
5. El correo saliente supera SPF y DKIM.
6. Alias y direcciones compartidas siguen recibiendo.

Si alguien dice que falta correo, prueba muestras en vez de discutir con barras de almacenamiento. Busca tres asuntos conocidos, una conversación antigua con adjuntos y un mensaje de las últimas 24 horas.

La documentación de clientes ahorra tiempo. Para TrekMail, usa una hoja común de ajustes en lugar de instrucciones distintas por empleado.

Enfoque tradicional y nuevo

Si sales de Gmail por coste, control o muchos dominios, compara el modelo operativo, no solo la capacidad. El objetivo puede ser evitar que la facturación por usuario condicione la arquitectura.

Esta es la diferencia práctica:

TrekMail puede encajar en cargas centradas en correo. Si dependes mucho de Docs, Sheets, Meet y colaboración Google, un proveedor IMAP no sustituye esa suite. Según el artículo fuente y el plan, TrekMail ofrece dominios propios, buzones IMAP, catch-all, reenvíos, migración y panel multidominio sin precio por usuario; verifica las funciones actuales.

El artículo fuente sitúa en marzo de 2026 el precio de Starter desde $3.50/mes y Free a $0 sin tarjeta. Los planes de pago ofrecen prueba gratuita de 14 días con tarjeta. Esa estructura puede facilitar planificar el crecimiento de buzones, pero confirma las condiciones vigentes.

Para presupuestar con datos, consulta los precios de TrekMail.

Lista final y siguiente paso

Haz bien tres cosas: inventariar, adelantar copias y tratar el DNS como parte de la migración. Muchas incidencias vienen de apresurar el cambio, no de IMAP en sí.

Antes de empezar, prepara esta lista:

1. Enumera buzones, alias, grupos y reenvíos.
2. Identifica buzones grandes y cópialos primero.
3. Crea el destino antes de sincronizar.
4. Adapta las etiquetas y evita criterios que generen duplicados.
5. Reduce TTL de MX 48 horas antes, considerando las cachés previas.
6. Publica SPF, DKIM y DMARC del emisor nuevo antes del cambio.
7. Sincroniza justo antes de modificar MX y repite después para entregas tardías.
8. Mantén Gmail activo 24-48 horas como orientación y hasta completar la recuperación y validación.
9. Reconfigura móviles y Outlook si hace falta, protegiendo datos locales.
10. Valida con recuentos, búsquedas por muestreo y pruebas reales.

Esta secuencia reduce riesgos mediante un procedimiento controlado y repetible. No elimina el trabajo ni convierte la migración en una operación de un clic. Eso es lo que necesitas de la infraestructura de correo.

Si buscas salir de la facturación por usuario hacia una tarifa fija multidominio, revisa la documentación de migración de TrekMail y prueba un buzón piloto. Después evalúa los números en trekmail.net antes de trasladar toda la empresa.