Cómo funciona una transferencia de correo: DNS, copia IMAP y cambio de servicio
La expresión «transferencia de correo» puede inducir a error. En el mundo físico, transferir un archivo significa que sale de la ubicación A y llega a la B. En la infraestructura de correo, eso no ocurre así.
Una transferencia de correo consta en realidad de dos operaciones independientes que se ejecutan en paralelo: replicar una base de datos mediante sincronización IMAP y redirigir el tráfico mediante un cambio de DNS. Confundir ambas capas es la principal causa de pérdida de datos, entrega dividida entre dos sistemas e incidencias de soporte el lunes por la mañana.
Esta guía explica qué significa «transferir» en la práctica, qué elementos se trasladan, cuáles no y cómo elegir el método adecuado para cada situación.
Los tres tipos de transferencia de correo
Antes de tocar un servidor, defina el alcance. «Transferencia» se utiliza para tres operaciones distintas y confundirlas provoca problemas reales.
1. Transferencia del dominio (cambio de registrador)
Traslada la gestión de example.com de GoDaddy a Namecheap. Esto cambia la entidad que factura el dominio. Impacto en el correo: ninguno, siempre que copie correctamente la zona DNS. Si cambia los servidores de nombres sin reproducir los registros MX, el correo dejará de funcionar de inmediato.
2. Migración del correo (cambio de proveedor)
Deja Google Workspace y se traslada a TrekMail, o a cualquier otro proveedor. Hay que preparar un servidor nuevo, copiar los datos antiguos y decir a Internet que entregue allí los mensajes nuevos. Impacto en el correo: total. Es una reconstrucción minuciosa de los datos y constituye el tema principal del artículo.
Consulte el procedimiento completo en la guía de sincronización IMAP.
3. Transferencia de titularidad de la cuenta
Cambiar el correo administrativo de una cuenta de bob@ a alice@. Es una actualización de permisos en la base de datos. Impacto en el correo: ninguno.
Las dos capas que debe gestionar durante una transferencia
Una transferencia correcta exige gestionar dos cronologías al mismo tiempo. Un error en cualquiera de ellas genera problemas.
La capa de datos (copia IMAP)
Los nuevos proveedores no absorben los datos anteriores. Se recuperan mediante el protocolo IMAP (RFC 3501). Es una copia, no un traslado: el original permanece en el servidor de origen hasta que se elimina expresamente.
La trampa de UIDVALIDITY: IMAP se diseñó para consultar mensajes, no para replicarlos en masa. Cada carpeta tiene un valor UIDVALIDITY. Si el servidor de origen falla o vuelve a indexarse durante la migración, ese valor cambia. La herramienta puede interpretar todos los mensajes como nuevos y descargarlos otra vez, lo que deja a los usuarios con 10,000 duplicados. Utilice una herramienta que elimine duplicados según las cabeceras Message-ID, no solo según los UID de IMAP.
La capa de enrutamiento (cambio de DNS)
Mientras se copian los datos, hay que redirigir el correo nuevo. Esto se controla mediante el registro MX (Mail Exchange):
Old: MX 10 aspmx.l.google.com
New: MX 10 mx1.trekmail.net
El riesgo de entrega dividida: los proveedores de Internet de todo el mundo almacenan los registros DNS en caché. Si el TTL es de 86,400 segundos (24 horas) y cambia el MX el viernes a las 5 PM, algunos servidores seguirán enviando al proveedor anterior hasta el sábado a las 5 PM.
La solución es la «regla de los 300 segundos». Reduzca el TTL del registro MX a 300 segundos al menos 24 horas antes del cambio. Consulte el procedimiento completo en cómo configurar correo en su dominio.
Qué se transfiere mediante IMAP y qué no
TrekMail es una plataforma especializada: IMAP y SMTP para el correo, además de sincronización de calendarios y contactos por buzón mediante CalDAV y CardDAV. No es una suite de productividad: no incluye documentos, hojas de cálculo ni videollamadas. Al pasar de una suite como Google o M365 a un proveedor centrado en correo, hay que saber exactamente qué datos pueden acompañarle.
| Objeto | ¿Se transfiere mediante IMAP? | Qué ocurre realmente |
|---|---|---|
| Mensajes | Sí, si son compatibles | Se copian el asunto, el cuerpo, los adjuntos y las fechas que admitan ambos servidores |
| Estructura de carpetas | Sí, si es compatible | Se recrean las carpetas anidadas admitidas; Exchange limita la profundidad a 300 |
| Estado de lectura | Sí, si es compatible | Se conserva el indicador Seen cuando ambos servidores lo admiten |
| Contactos | No | Exporte a CSV/vCard e importe en el dispositivo local |
| Calendarios | No | Exporte a .ics y alójelos en otro servicio o manténgalos en local |
| Alias | No | Vuelva a crearlos manualmente en el panel de TrekMail |
| Reglas del servidor | No | Las reglas de reenvío y filtrado deben volver a crearse |
El obstáculo de la autenticación moderna
Si migra desde un proveedor que exige OAuth, como Google, algunos dispositivos antiguos, por ejemplo escáneres o Outlook 2013, pueden no conectarse a un servidor IMAP estándar. La documentación de migración de Google Workspace explica cómo las contraseñas de aplicaciones pueden salvar esta diferencia. TrekMail admite autenticación IMAP/SMTP estándar mediante TLS 1.2. Compruebe que sus dispositivos sean compatibles.
¿Qué método de transferencia necesita?
Situación A: reducir el coste de Google Workspace
- Configure una cuenta de TrekMail con su dominio
- Utilice la herramienta de migración de TrekMail para copiar los datos de correo
- Exporte los contactos (.vcf) y calendarios (.ics) a archivos locales
- Cambie los registros MX a
mx1.trekmail.net/mx2.trekmail.net - Cancele Google Workspace después de comprobar la copia y la entrega
Situación B: trasladar el dominio a otro registrador
- Habilite la transferencia en el registrador actual
- Obtenga el código EPP o de autorización
- Inicie la transferencia en el registrador nuevo
- Importante: asegúrese de que los servidores de nombres no cambien o copie correctamente toda la zona
Herramientas integradas de TrekMail para transferir correo
Las migraciones IMAP manuales son propensas a errores. Un único tiempo de espera agotado o un cambio de UIDVALIDITY puede dejar una copia incompleta o duplicada. TrekMail trata la migración como infraestructura esencial, no como una función secundaria.
Motor de migración
El panel se conecta directamente al proveedor anterior, como Gmail, cPanel o Exchange, y gestiona la sincronización IMAP entre servidores. Los reintentos, las pausas progresivas ante límites y la eliminación de duplicados por cabeceras son automáticos. No hace falta utilizar la línea de comandos.
Almacenamiento compartido para agencias
Si es un MSP que traslada 50 clientes, gestionar 50 cuotas de almacenamiento independientes es ineficiente. TrekMail ofrece almacenamiento compartido, por ejemplo 200 GB para todos los dominios. Asigne el espacio donde haga falta.
Validación del DNS
Una herramienta sencilla comprueba los registros MX, SPF y DKIM para reducir el riesgo de que el correo quede sin destino durante el cambio.
| Plan | Precio | Motor de migración | Almacenamiento compartido |
|---|---|---|---|
| Free | $0 (sin tarjeta) | Incluido | No |
| Starter | $3.50/mes | Incluido | No |
| Pro | $10/mes | Incluido | No |
| Agency | $23.25/mes | Incluido con herramientas masivas | Sí |
Todos los planes de pago incluyen una prueba gratuita de 14 días que requiere tarjeta. El plan Nano no la necesita.
Conclusión: determine qué transferencia de correo necesita
La mayoría de los fallos se produce al confundir la transferencia del dominio, la migración del correo y los cambios de cuenta. Separe la capa de datos, es decir, la copia IMAP, de la capa de enrutamiento, el cambio de DNS, gestione cronologías independientes y compare recuentos y elementos con el origen al terminar.
Si está preparado para cambiar, cree su cuenta gratuita de TrekMail y deje que el motor de migración se encargue del trabajo más pesado.
