Una migración de correo con dominio propio desde cPanel traslada los buzones de un alojamiento cPanel combinado (Bluehost, HostGator, Hostinger o similar) a un proveedor especializado sin perder correo entrante durante la transición. La clave es la recepción en paralelo: configurar el nuevo proveedor mientras el anterior sigue recibiendo y después cambiar los registros MX con un TTL de DNS bajo para que la transición dure minutos en vez de horas.
La mayoría de las guías de migración desde cPanel omite la recepción en paralelo y describe una transición en frío que puede perder mensajes durante la propagación DNS. Una transición en frío suele perder 10-50 mensajes, según el volumen entrante. El método en paralelo que se presenta aquí busca evitar esa pérdida. La preparación adicional requiere 30 minutos y ayuda a proteger esos mensajes.
Esta guía recorre la transición en seis pasos e incluye bloques de código con registros DNS. Para una visión más amplia, consulta mover el correo a otro proveedor.
Por qué importa una migración limpia desde cPanel
Una migración limpia importa porque el correo en tránsito durante la propagación DNS supone un riesgo real para los ingresos. En una transición en frío con una propagación que dura horas, se pierde todo lo que llega al MX anterior después de que deje de aceptar correo. Muchos responsables no perciben el coste hasta que un cliente se queja.
El método de seis pasos evita la ventana de pérdida mediante recepción en paralelo: ambos proveedores reciben simultáneamente durante la transición y el responsable inicia manualmente la retirada solo después de confirmar que se ha despejado el correo en tránsito. La disciplina adicional requiere 30 minutos de preparación y puede evitar pérdidas difíciles de acotar.
Resumen de la transición en seis pasos
Seis pasos cubren la migración desde cPanel mediante recepción en paralelo. El orden importa porque el resultado de cada paso permite ejecutar el siguiente. El tiempo total es de alrededor de una semana, desde la reducción del TTL hasta la retirada completa; el trabajo activo ronda las 3-4 horas repartidas durante esa semana.
- Reduce el TTL del DNS con 48 horas de antelación. Disminuye el tiempo de propagación del MX de horas a minutos durante la transición.
- Prepara los buzones en el nuevo proveedor. Crea buzones equivalentes en el nuevo servicio mientras mantienes activos los anteriores.
- Copia el correo histórico mediante IMAP. Una herramienta de migración IMAP del lado del servidor copia los mensajes existentes de los buzones anteriores a los nuevos.
- Cambia los registros MX. Actualiza el DNS para que apunte al nuevo proveedor; ambos reciben durante la propagación.
- Comprueba la autenticación y el recorrido completo. Confirma que SPF, DKIM y DMARC se validan en tres destinatarios desde el nuevo proveedor.
- Retira los buzones anteriores. Espera 48-72 horas tras cambiar el MX y desactiva los buzones antiguos cuando se haya despejado el correo en tránsito.
Cada paso funciona como punto de control; revertir cualquier paso hasta el paso 4 es sencillo. Después del paso 4, el cambio de MX, aún se puede revertir, pero resulta costoso en la operación porque el correo empieza a acumularse en el nuevo proveedor. Una transición estándar normalmente no requiere reversión si los pasos 1-3 se realizaron correctamente.
Paso 1: reducir el TTL del DNS con 48 horas de antelación
Reduce el TTL de DNS de los registros MX existentes 48 horas antes de la transición prevista. El TTL predeterminado suele ser 3600 segundos (1 hora) u 86400 (24 horas). Establécelo en 300 segundos (5 minutos) para que el cambio de MX del paso 4 se propague en minutos en lugar de horas.
El cambio se realiza en el panel del proveedor DNS. Edita el TTL de cada registro MX, establece el valor en 300 y guarda. Espera 48 horas para que venza el TTL actual y se propague el valor bajo. Después del paso 6, vuelve a elevar el TTL a 3600 para el funcionamiento normal. Ejemplo de cambio de registro DNS en Cloudflare:
; before: MX record with default TTL
yourcompany.com. 3600 IN MX 10 mail.oldhost.example.com.
; after: MX record with low TTL for migration window
yourcompany.com. 300 IN MX 10 mail.oldhost.example.com.
Paso 2: preparar los buzones en el nuevo proveedor
Prepara buzones equivalentes en el nuevo proveedor. Añade el dominio en TrekMail, verifica su propiedad mediante el registro TXT y crea buzones que correspondan a cada dirección del alojamiento cPanel anterior. En este punto, los nuevos buzones están listos, pero el MX aún señala al proveedor anterior.
Genera los valores SPF, DKIM y DMARC que proporciona el nuevo servicio. No los publiques todavía; eso ocurre en el paso 4, junto con el cambio de MX. Generarlos con antelación garantiza que los valores estén listos cuando llegue el paso 4. Esta preparación es lo que permite la recepción en paralelo más adelante. Consulta migración IMAP para conocer los detalles de la herramienta.
Paso 3: copiar el correo histórico mediante IMAP
Usa la herramienta de migración IMAP del nuevo proveedor para copiar el correo histórico desde los buzones cPanel anteriores a los nuevos. La herramienta del lado del servidor de TrekMail (Starter y superiores) permite hacerlo desde el panel: proporciona las credenciales IMAP del alojamiento anterior y deja que copie carpeta por carpeta durante unas horas.
La migración se ejecuta en segundo plano mientras el MX todavía apunta al proveedor anterior. Este sigue recibiendo los mensajes nuevos y el nuevo conserva la copia histórica. Cuando termina, ambos tienen la misma estructura de carpetas con los mismos mensajes, que es precisamente el estado necesario para la transición en paralelo del paso 4. Consulta lista de comprobación para migrar correo como guía estructurada.
Paso 4: cambiar los registros MX
El cuarto paso actualiza los registros MX en el proveedor DNS para que apunten al nuevo servicio de buzones. Publica los nuevos valores MX junto con los registros SPF, DKIM y DMARC del paso 2. La propagación DNS tarda alrededor de 5 minutos gracias al TTL bajo del paso 1. Durante la ventana de propagación, ambos proveedores reciben en paralelo.
; new MX records pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; published SPF, DKIM, DMARC TXT records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
La ventana de recepción en paralelo evita el intervalo habitual de pérdida de mensajes. Lo que se envíe durante la propagación llega al proveedor anterior, todavía activo, o al nuevo, recién activado, en lugar de rebotar por una interrupción entre ambos. Mantén activos y accesibles los buzones anteriores al menos 48 horas después de cambiar el MX para recoger correo en tránsito que aún tarde en llegar.
Paso 5: comprobar la autenticación y el envío de ida y vuelta
Comprueba la autenticación del correo saliente desde el nuevo proveedor. Envía mensajes de prueba desde cada buzón nuevo a cuentas de Gmail, Outlook.com y Yahoo. Confirma que los encabezados muestran SPF=PASS, DKIM=PASS y DMARC=PASS en los tres. Cualquier FAIL indica que los registros publicados en el paso 4 deben ajustarse antes de considerar terminada la transición.
Comprueba también que el correo llega correctamente al nuevo proveedor. Envía un mensaje de prueba desde una dirección externa a uno de los buzones nuevos y confirma que aparece en la bandeja de entrada del nuevo servicio en pocos minutos. Si llega al anterior, la propagación DNS todavía no ha terminado; espera otros 10-15 minutos y repite la prueba.
Paso 6: retirar los buzones anteriores
Retira los buzones anteriores entre 48-72 horas después de cambiar el MX. Para entonces, la propagación DNS debería haberse completado globalmente y los remitentes ya no deberían dirigirse al MX anterior. Desactiva los buzones desde el panel de cPanel; mantén activo el plan cPanel para el sitio web si lo necesitas, pero desactiva la recepción de correo.
Si cPanel también aloja el sitio web y no quieres seguir pagándolo, este es el momento de migrar el sitio a otro alojamiento web. La migración del correo desde cPanel queda terminada cuando el correo anterior está desactivado y el nuevo proveedor ha recibido mensajes correctamente durante varios días. Vuelve a elevar el TTL del DNS a 3600 segundos para el funcionamiento normal.
Próximos pasos
La migración de correo desde cPanel con recepción en paralelo requiere alrededor de una semana de tiempo total y 3-4 horas de trabajo activo. El objetivo es evitar la pérdida de mensajes y lograr una transición limpia a un proveedor especializado, con la autenticación adecuada en cada mensaje saliente.
El marco de seis pasos se puede repetir: aplícalo de la misma forma a cada dominio cPanel adicional y el proceso se agilizará con cada repetición.
Prueba TrekMail Nano gratis en trekmail.net/pricing, sin tarjeta. Starter por $4/mes incluye la herramienta de migración IMAP del lado del servidor necesaria en el paso 3. La plataforma asume las tareas operativas del alojamiento de buzones que los proveedores cPanel dejaban a tu cargo en el paquete.
Una observación operativa: la ventana de recepción en paralelo del paso 4 es el motivo estructural por el que este método busca evitar la pérdida de mensajes. Las transiciones en frío pierden correo porque dejan un intervalo entre el momento en que se detiene el proveedor anterior y aquel en que el nuevo recibe globalmente, durante el cual los mensajes rebotan. La recepción en paralelo elimina ese intervalo manteniendo activos ambos servicios durante la propagación.
La migración desde cPanel suele ser más sencilla en la práctica de lo que muchos responsables esperan. El temor a que el correo falle puede retrasar el traslado durante meses, mientras se acumula el coste de entregabilidad del alojamiento cPanel combinado. El método de seis pasos reduce el riesgo de pérdida que provoca esa demora, por lo que quienes realizan una migración suelen dudar menos al repetirla con otros dominios.
Para quienes gestionan varios dominios personalizados en alojamientos cPanel, la plantilla se aplica a cada dominio: los mismos seis pasos con entradas DNS diferentes. Planifica las transiciones en días distintos y no de forma simultánea. La atención necesaria durante cada migración es pequeña, pero real; encadenarlas aumenta la carga cognitiva sin necesidad y la probabilidad de omitir un paso.
