Cómo trasladar el correo a otro proveedor sin perder mensajes

Si necesitas trasladar el correo a otro proveedor, lo difícil no es copiar los mensajes antiguos. Es mantener la recepción y el envío mientras persisten las cachés DNS, los usuarios siguen pulsando Enviar y los dispositivos antiguos continúan conectándose al servidor equivocado. Ahí es donde se complican las migraciones. Si todavía estás eligiendo una solución a largo plazo, empieza por el correo empresarial para no tener que repetir el trabajo.

Muchas guías lo presentan como algo sencillo: exportar, importar, cambiar los MX y listo. Ese consejo puede causar problemas. El correo conserva estados, el DNS se almacena en caché, IMAP puede ser lento y los hábitos de los usuarios complican aún más las cosas. Si tratas el cambio de proveedor de correo como una migración web, algunos mensajes pueden quedar repartidos entre el buzón antiguo, el nuevo y el teléfono de alguien.

La solución es sencilla, pero no inmediata: mantén ambos sistemas en paralelo, copia previamente el correo histórico, reduce el TTL del DNS con antelación, realiza el cambio en una ventana controlada y ejecuta una última sincronización incremental antes de retirar el servicio antiguo.

Esta es una guía práctica, sin promesas de «cero interrupciones». Describe un método operativo para migraciones en 2025-2026.

Por qué fallan las migraciones de correo

Para cambiar de proveedor con menos riesgo, debes gestionar el período de coexistencia. Los cambios DNS se reflejan en momentos distintos: algunos remitentes seguirán entregando al servidor antiguo y otros ya utilizarán el nuevo. Sin un plan para ese período, puedes perder de vista mensajes.

Cuando alguien escribe a tu dominio, su servidor consulta los registros MX. Los resolutores recursivos, las pasarelas de correo y otros componentes de la infraestructura de Internet pueden almacenar esa respuesta en caché. SMTP está definido en el RFC 5321, pero aquí el problema es operativo: los servidores remitentes no actualizan el DNS todos a la vez.

Esto crea una ventana con dos destinos activos:

El remitente A todavía ve el MX antiguo y entrega al proveedor anterior.
El remitente B ve el MX nuevo y entrega al proveedor nuevo.
El usuario consulta un solo buzón y cree que faltan mensajes.

Por eso es arriesgado cambiar los registros un viernes por la noche y esperar que todo salga bien. Si buscas mantener el servicio durante el traslado, necesitas una migración por etapas, no un simple interruptor.

Qué debes inventariar antes de tocar el DNS

Antes del cambio, inventaría lo que existe realmente: buzones, alias, direcciones compartidas, reenvíos, cuentas inactivas y buzones de gran tamaño. El número de usuarios apenas revela la complejidad real.

Empieza por los buzones que suelen complicar más los proyectos:

1. Buzones grandes. Los que superan los 20-50 GB merecen un tratamiento especial porque la migración IMAP puede ser lenta y los proveedores pueden limitar su velocidad.
2. Direcciones compartidas. `info@`, `sales@` y `support@` a menudo no son buzones personales convencionales.
3. Alias y reenvíos. Si `jane@` también recibe los mensajes de `hello@` y `jd@`, esas correspondencias deben existir en el sistema nuevo desde el primer día.
4. Buzones de antiguos empleados que siguen recibiendo correo. Son fallos discretos que suelen descubrirse semanas después.

Si omites este paso, no tienes un plan de migración, sino una suposición.

Google advierte de que una actividad intensa de sincronización IMAP puede activar sus protecciones de ancho de banda. La documentación de Google Workspace recogida en el artículo fuente indica 2500 MB diarios de descarga IMAP y 500 MB diarios de carga IMAP, con suspensiones de hasta 24 horas al alcanzar los límites. Comprueba las condiciones vigentes; un buzón grande puede tardar días en copiarse, no horas.

Si utilizas TrekMail, el modelo de costes importa. Según las condiciones recogidas en el artículo fuente, los planes de pago empiezan en $3.50 al mes, utilizan almacenamiento compartido en lugar de facturación por usuario e incluyen una herramienta de migración del lado del servidor desde Starter. Según tus necesidades y las condiciones vigentes, esto puede facilitar preparar el destino con antelación y dejar terminar las importaciones en segundo plano sin duplicar licencias por usuario.

Un método prudente para trasladar el correo

Una migración con ambos sistemas en paralelo reduce riesgos: crea primero el destino, copia el correo antiguo por adelantado, baja el TTL antes del cambio, modifica los MX en una ventana controlada y ejecuta una sincronización incremental final.

Esta es la secuencia recomendada:

1. Prepara primero el destino

Crea el dominio, los buzones, los alias y las reglas de reenvío en la plataforma nueva antes de modificar los MX. En TrekMail, eso implica añadir el dominio, comprobar la preparación del DNS y crear los buzones de destino antes de iniciar las importaciones.

Documentación útil: añadir un dominio, iniciar una migración IMAP y ajustes IMAP/SMTP.

2. Copia previamente el correo antiguo

Copia los mensajes antiguos antes del cambio. Un procedimiento habitual consiste en importar primero todo lo que tenga más de 30 días y reservar el correo reciente para la última pasada. Así puedes trasladar buena parte del correo sin la presión del momento del cambio.

Según el artículo fuente, la herramienta de TrekMail importa desde servidores IMAP externos, como Gmail, Outlook o proveedores basados en cPanel, a un buzón específico de TrekMail. Activa la omisión de duplicados para reducir el riesgo al repetir las tareas.

3. Reduce el TTL con 48 horas de antelación

Reduce el TTL de los MX y los registros DNS relacionados unas 48 horas antes del cambio. Un valor de 300 segundos puede ser útil si tu proveedor lo permite. Puede acortar la coexistencia de respuestas antiguas y nuevas una vez expire el TTL previo; no garantiza la actualización inmediata de todas las cachés ni determina por sí solo el tratamiento de los filtros antispam.

Si también cambias la configuración de envío, revisa el DNS con cuidado. La documentación de TrekMail señala un error habitual: crear un segundo registro SPF en vez de reunir las directivas include en un único registro.

4. Detén los cambios en el sistema antiguo

Al realizar el cambio, pide a los usuarios que dejen de enviar desde la cuenta antigua. En migraciones de mayor riesgo, bloquea el inicio de sesión de los clientes antiguos para evitar que sigan generando correo enviado en el proveedor equivocado.

5. Cambia los MX y verifica desde fuera

Actualiza los registros MX y comprueba después qué respuestas se obtienen desde Internet.

dig mx example.com +short
nslookup -type=mx example.com

No te fíes únicamente del panel DNS. Haz consultas externas.

6. Ejecuta la sincronización incremental

Después de cambiar los MX, ejecuta otra pasada de importación. Recuperará los mensajes que hayan llegado al proveedor antiguo durante la coexistencia. Esta pasada final reduce el riesgo de dejar atrás las últimas horas de correo entrante.

7. Desactiva pronto el acceso antiguo

Cuando confirmes que la entrega llega al proveedor nuevo, desactiva los accesos de los usuarios al anterior. Las configuraciones antiguas de los teléfonos son un riesgo real. Si un teléfono sigue enviando desde la cuenta antigua, las respuestas llegarán al buzón nuevo, pero el correo enviado quedará en el servidor anterior y la conversación se dividirá.

Registros DNS que suelen cambiar durante la transición

Al cambiar de proveedor, los registros críticos son MX para la recepción y, normalmente, SPF, DKIM y DMARC para autenticar el envío. Conservar registros antiguos incompatibles puede causar problemas de entrega y reputación.

Cada proveedor utiliza valores concretos distintos, pero el esquema suele ser este:

; Incoming mail
example.com.   300   IN MX 10 mail.your-new-provider.tld.

; SPF - keep only one SPF TXT record
example.com.   300   IN TXT "v=spf1 include:your-sender.example -all"

; DKIM - provider-specific selector and key
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."

; DMARC
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Hay dos reglas importantes:

1. No publiques dos registros SPF para el mismo nombre de host.
2. No elimines los registros de envío antiguos hasta confirmar que nada sigue enviando a través del servicio anterior.

Si te importa la entrega a Gmail, revisa los requisitos para remitentes. Las preguntas frecuentes de Google citadas en el artículo fuente consideran remitentes masivos a quienes envían aproximadamente 5,000 mensajes diarios o más a cuentas personales de Gmail y describen una aplicación más estricta desde noviembre de 2025. Consulta las preguntas frecuentes de Google sobre las directrices para remitentes para conocer los requisitos vigentes.

Qué suele fallar al cambiar de proveedor de correo

La mayoría de los fallos no son cortes espectaculares, sino desajustes discretos: mensajes duplicados u omitidos, carpetas mal asignadas, dispositivos antiguos que siguen enviando por el servidor anterior o registros DNS actualizados solo en parte.

Estos son los problemas más habituales:

Limitación de velocidad IMAP

Los buzones grandes pueden detenerse a mitad de la importación, especialmente desde Gmail. Si insistes sin ajustar la carga, la cuenta puede quedar limitada. Por eso conviene copiar el histórico con antelación.

Mensajes duplicados

Las repeticiones mal configuradas o una deduplicación insuficiente pueden volver a copiar el correo. Utiliza opciones que omitan duplicados y verifica después el número de elementos.

Problemas de correspondencia entre carpetas

El correo enviado puede acabar en otra carpeta porque un sistema utiliza `Sent`, otro `Sent Items` y otro una ruta con espacio de nombres. Si los usuarios dicen que «el correo ha desaparecido», comprueba si simplemente está en la carpeta equivocada. La guía de TrekMail sobre imapsync aborda estos detalles operativos.

Buzones que siguen activos sin que nadie los consulte

El correo puede seguir llegando al proveedor antiguo tras el cambio porque las cachés aún no han caducado o todavía queda algún MX antiguo. Para eso sirve precisamente la sincronización incremental.

Clientes antiguos que siguen enviando por el servidor equivocado

Los teléfonos y los perfiles de Outlook conservan sus ajustes. Tras el traslado, los usuarios deben actualizar la configuración IMAP/SMTP o seguirán conectándose al servidor anterior. Si aprovechas el proyecto para revisar la titularidad de los buzones y restablecer accesos, también puede servirte la guía de gestión del correo de clientes.

Cómo verificar la migración con datos

Tras el cambio, verifica con pruebas, no con impresiones. No preguntes únicamente si «todo parece estar bien». Compara el número de elementos de los buzones, prueba la entrega real, revisa el correo enviado y confirma que el proveedor anterior ha dejado de recibir tráfico.

Utiliza esta lista de comprobación:

1. Compara el número de elementos del origen y del destino en cada buzón.
2. Envía mensajes de prueba desde un proveedor externo a varias direcciones, incluidos alias y buzones compartidos.
3. Responde desde el buzón nuevo y confirma que el mensaje aparece en Enviados en el proveedor nuevo.
4. Comprueba que el proveedor antiguo ya no admite el acceso de los usuarios.
5. Consulta los MX desde varias redes externas.
6. Revisa por muestreo las carpetas con nombres inusuales, los archivos y las estructuras anidadas.

No compares el tamaño de los buzones en gigabytes entre proveedores: el cálculo del almacenamiento puede variar mucho. Compara el número de elementos.

Enfoque tradicional frente a TrekMail

El riesgo empresarial no se limita a las interrupciones: también cuenta el coste de la coexistencia. Las plataformas con facturación por usuario pueden empujar a acelerar el cambio cuando se paga a ambos proveedores. Un modelo de tarifa fija puede facilitar la preparación anticipada del destino y una migración más pausada, según las condiciones contratadas.

TrekMail no cambia el funcionamiento del DNS. Lo que puede cambiar es el coste y el flujo de trabajo. Según las funciones recogidas en el artículo fuente, puedes preparar dominios y buzones, importar en segundo plano e incorporar usuarios mediante invitaciones, con menos presión por las licencias individuales durante el traslado.

Esto importa especialmente a agencias y proveedores de servicios gestionados. Si administras muchos clientes, consulta después la guía de alojamiento de correo multidominio. La migración es solo una parte del trabajo; el modelo operativo posterior también influye en tus márgenes.

Cuándo puede encajar TrekMail en esta migración

TrekMail puede encajar cuando buscas buzones IMAP basados en estándares, gestión multidominio, almacenamiento compartido, migración integrada y SMTP gestionado o propio, según el plan. Su enfoque en el correo, sin pretender sustituir una suite ofimática completa, puede simplificar la configuración.

Condiciones de los planes recogidas en las páginas de precios al preparar el artículo fuente; comprueba su vigencia:

• Free: $0, hasta 10 dominios, 5 GB compartidos, SMTP propio.
• Starter: desde $3.50/mes, 50 dominios, 15 GB compartidos, SMTP gestionado, herramienta de migración.
• Pro: $10/mes, 100 dominios, 50 GB compartidos, acceso API.
• Agency: $23.25/mes, 1000+ dominios, 200 GB+ de almacenamiento, API y MCP.
• Enterprise: precio personalizado.

Según el artículo fuente, los planes de pago ofrecen una prueba gratuita de 14 días y requieren tarjeta de crédito. El plan Nano se describe sin tarjeta ni caducidad; revisa las condiciones vigentes.

Para calcular el coste de coexistencia antes del cambio, consulta los precios de TrekMail.

La regla final del cambio

Quédate con esta idea: para reducir el riesgo de perder correo al cambiar de proveedor, mantén ambos sistemas en paralelo hasta verificar la entrega, repetir la sincronización incremental y bloquear el acceso de los usuarios al proveedor anterior.

Ese es el procedimiento: inventariar, copiar previamente los buzones pesados, reducir el TTL con antelación, cambiar los MX en una ventana controlada, ejecutar la sincronización final y verificar mediante recuentos, no impresiones.

Con estos pasos puedes reducir las incidencias del traslado. Si los omites, quizá pases el mes siguiente buscando mensajes «desaparecidos» que en realidad llegaron a un buzón que nadie recordó consultar.