Migrar el correo a un nuevo proveedor sin tiempo de inactividad
Cuando necesitas migrar el correo a la infraestructura de un nuevo proveedor, no tiene por qué producirse un apagón de 24 horas durante el cual los mensajes reboten o desaparezcan. El temido «agujero negro» aparece cuando se ignoran los tiempos de propagación DNS y se intenta hacer todo de una sola vez. Con una ejecución en paralelo, mantienes activo el sistema antiguo mientras el nuevo se sincroniza en segundo plano y cambias el tráfico cuando ambos están conciliados.
Esta guía explica el plan de transición que utilizan los administradores para migrar el correo a nuevos entornos con la menor interrupción posible. Si quieres conocer toda la teoría de la migración, consulta nuestra guía de migración por IMAP.
Por qué falla el método «Big Bang»
El enfoque «Big Bang», copiarlo todo el viernes por la noche, cambiar el DNS y cruzar los dedos, falla porque las velocidades de transferencia no son constantes. La limitación de tráfico (errores HTTP 429) y los topes de ancho de banda pueden detener una migración a mitad del proceso. Llega el lunes por la mañana, la mitad de los buzones están vacíos y el equipo de soporte se desborda.
La práctica profesional al migrar el correo a un nuevo proveedor consiste en ejecutar ambos sistemas en paralelo. Preparas el nuevo entorno, sincronizas el historial en segundo plano y solo actualizas el DNS cuando has conciliado el destino con el origen. Para saber cómo proteger tu reputación como remitente durante el cambio, lee esa guía antes de empezar.
Las 4 etapas de una migración de correo
| Etapa | Momento | Acción | Objetivo |
|---|---|---|---|
| Preparación | T-7 días | Sincronizar por IMAP los mensajes de más de 30 días | Mover el 90% del almacenamiento sin presionar el ancho de banda |
| Reducción del TTL | T-48 horas | Bajar el TTL de MX/SPF a 300 segundos | Reducir la caché DNS para una ventana de cambio prevista de 5 minutos |
| Transición | Momento cero (viernes por la tarde) | Actualizar los registros MX al nuevo proveedor | Dirigir el correo entrante nuevo al servidor nuevo |
| Sincronización delta | T+1 hora | Sincronizar los elementos recientes (últimos 30 días) | Recuperar el correo entregado al servidor antiguo durante la transición |
Fase 1: propagación DNS y la regla de los 300 segundos
El enrutamiento dividido, en el que unos remitentes llegan al servidor antiguo y otros al nuevo, se debe a valores TTL largos en los registros DNS. Los resolutores recursivos guardan en caché tus registros MX según el TTL. Un TTL habitual es de 86,400 segundos (24 horas). Si cambias los registros MX sin reducirlo antes, algunos remitentes pueden seguir enviando correo al servidor antiguo mientras sus cachés permanezcan vigentes. Quien quiera migrar el correo a un nuevo proveedor debe preparar primero el TTL.
El procedimiento es sencillo: revisa el TTL actual, baja los TTL de MX y SPF a 300 segundos y espera al menos el TTL original antes de continuar. Ese valor es una indicación máxima para cachés que respetan el TTL, no una garantía de propagación global. Si omites la espera, habrá resolutores que aún conserven los registros anteriores.
La trampa de las 10 consultas SPF
Durante la migración, quizá quieras añadir el include SPF del nuevo proveedor junto al del antiguo. Ten cuidado. RFC 7208 limita SPF a 10 consultas DNS. Acumular varios proveedores (Google + Outlook + el nuevo proveedor) suele superar el límite, lo que provoca PermError y problemas de entrega. Aplana el registro SPF solo si mantienes actualizadas de forma fiable las direcciones IP resultantes, o retira temporalmente durante la transición las herramientas de marketing que no sean esenciales. Para configurar SPF correctamente, consulta nuestra guía de SPF.
Fase 2: sincronización de datos por IMAP
Al migrar el correo a un nuevo proveedor, la migración utiliza el protocolo IMAP (RFC 3501). No es una simple copia de archivos, sino una sincronización de estados. Herramientas como imapsync se encargan del trabajo pesado, pero conviene entender el protocolo.
El problema del «buzón fantasma» de Gmail
Si migras «All Mail» de Gmail tratando sus etiquetas como carpetas, puedes generar múltiples copias visibles en carpetas IMAP: un solo mensaje con 3 etiquetas puede copiarse 3 veces en 3 carpetas distintas. La documentación de migración de datos de Google describe este comportamiento de las etiquetas. La solución es configurar la herramienta de migración para que asigne las etiquetas de forma inteligente o excluir por completo la carpeta [Gmail]/All Mail.
Limitación de tráfico y códigos de error
Al migrar el correo a un nuevo proveedor, es habitual que el servidor de origen imponga límites. Google devuelve fallos de conexión 11001/11002 cuando el acceso IMAP está deshabilitado o bloqueado por un cortafuegos. Los errores HTTP 429 indican que estás enviando demasiados datos; muchos proveedores interrumpen conexiones al superar 2 GB/hour/user. Utiliza una herramienta de migración con espera exponencial que detecte la limitación y se detenga automáticamente.
Fase 3: impacto en los clientes de correo
Después de migrar el correo a los servidores del nuevo proveedor, el lado del servidor suele ser la parte sencilla; nuestra guía sobre cómo transferir un buzón explica la transición DNS en detalle. En los clientes es donde puede llegar la avalancha de consultas al soporte.
Certificado no coincidente: si Outlook permanece abierto durante el cambio de DNS, se conecta a mail.yourdomain.com, que ahora apunta al nuevo proveedor, con las credenciales antiguas. Pueden aparecer advertencias del certificado SSL/TLS. Recomienda reiniciar el cliente el lunes por la mañana.
OAuth en móviles: los clientes móviles modernos utilizan tokens OAuth vinculados a un tenant concreto. En algunas aplicaciones basta con volver a autorizar o configurar la cuenta; en otras, el usuario tendrá que eliminar la cuenta antigua y añadir una nueva conexión IMAP.
Bucles de enrutamiento interno: tras el cambio de MX, es posible que el servidor antiguo siga creyendo que aloja el dominio. Si el usuario A (en el antiguo) escribe al usuario B (también en el antiguo), el servidor entrega el mensaje localmente y el usuario B, que ya consulta el nuevo, no lo ve. Reconfigura de forma segura la entrega local del proveedor antiguo para que reenvíe el correo tardío al nuevo mientras se extinguen las cachés DNS; no la desactives sin comprobar antes la ruta alternativa.
La reversión: una red de seguridad de 15 minutos
Como redujiste el TTL a 300 segundos en la fase 1, una reversión puede ser más rápida para los resolutores que respetan el TTL. Si falla el intento de migrar el correo al nuevo proveedor, por ejemplo por un bloqueo del cortafuegos, problemas de licencia o ausencia de flujo de correo durante 30+ minutos, restaura los registros MX del proveedor antiguo. El tráfico volverá gradualmente a medida que caduquen las cachés, pero no se puede garantizar que lo haga en 5 minutos.
Cómo simplifica TrekMail la migración
Migrar el correo a un nuevo proveedor de forma manual implica gestionar scripts de imapsync, interpretar errores crípticos como 0x800CCC0E y vigilar la propagación DNS. TrekMail incluye un motor de migración IMAP que automatiza la asignación de carpetas, la espera ante límites de tráfico y las sincronizaciones delta para los datos IMAP compatibles; al terminar, sigue siendo necesaria una conciliación con el origen.
| Plan | Precio | Ideal para |
|---|---|---|
| Free | $0 | Pruebas y dominios personales (sin tarjeta) |
| Starter | $3.50/mo | Pequeñas empresas y un solo dominio |
| Pro | $10/mo | Varios dominios y usuarios avanzados |
| Agency | $23.25/mo | MSP que migran 50+ dominios de clientes con almacenamiento compartido |
Todos los planes de pago incluyen una prueba de 14 días (requiere tarjeta). El plan Nano no exige tarjeta.
TrekMail se centra en el almacenamiento y la entrega de correo de alto rendimiento, junto con calendarios y contactos por buzón mediante CalDAV y CardDAV. Si también necesitas crear correo con tu propio dominio, nuestra guía de configuración explica todos los pasos. La migración solo mueve el correo: exporta los calendarios y contactos del proveedor antiguo e impórtalos cuando los buzones estén activos.
Para las agencias que migran habitualmente el correo a un nuevo proveedor en decenas de dominios a la vez, TrekMail ofrece almacenamiento compartido (distribuye 200 GB entre todos tus dominios), SMTP gestionado con reputación de IP previamente establecida y aprovisionamiento mediante plantillas para aplicar la configuración de DNS y migración a 100 dominios de una vez.
Conclusión: migra el correo sin un agujero negro
Migrar correctamente el correo a un nuevo proveedor consiste en gestionar a la vez una transición de estado en el DNS, los datos y el acceso de los clientes. Todo administrador que deba hacerlo tiene que planificar esta complejidad. El éxito significa reducir los rebotes, la pérdida de datos y las llamadas urgentes mediante comprobaciones y conciliaciones. Prepara el TTL de 300 segundos, utiliza una arquitectura en paralelo y ten listo un plan de reversión.
Si quieres profundizar en cómo elegir la plataforma de correo adecuada y proteger la reputación de tu dominio durante el cambio, consulta esas guías.
Deja de pagar tarifas por usuario por funciones que no utilizas. Prueba TrekMail gratis y descubre cómo es un alojamiento de correo creado para administradores.
