Idioma
La web abre en el nuevo servidor, pero un mensaje de un empleado ya no llega al destinatario. Declarar terminada la migración sería prematuro. Web y correo pueden estar en proveedores distintos, con la zona DNS en un tercer sistema. El plan debe reconocer esas fronteras desde el principio.
El día anterior: prepare el inventario
Identifique quién mantiene el registro, dónde se configura la delegación de nameservers, qué plataforma sirve la zona DNS y quién aloja los buzones. Marque el origen web por separado. Ver varios servicios en un mismo panel no demuestra que compartan autoridad técnica.
Anote responsables y propietarios del acceso. Un desarrollador puede controlar DNS sin estar autorizado para migrar buzones. No guarde contraseñas en la hoja: registre al responsable y el método seguro de entrega acordado.
Identifique los sistemas y al responsable de cada uno. Tener acceso al dominio es ambiguo: puede referirse solo al registrador, sin autoridad para cambiar la zona DNS. El panel de hosting puede gestionar los archivos de la web mientras los MX apuntan a otro proveedor.
Inventaríe A/AAAA, CNAME, MX y los TXT relacionados con correo, incluidos los selectores DKIM. Añada TTL, valor, finalidad y necesidad de modificación. Conserve los registros de verificación de otros servicios empresariales. Cuando sea posible, guarde una exportación fechada de la zona.
Antes del cambio, conserve una exportación completa de la zona o un registro que permita reconstruir cada entrada. Una captura puede ocultar parte de un TXT largo. Preste atención a subdominios, verificaciones de terceros y selectores DKIM. Mover la web no es motivo para eliminarlos.
Dé al correo su propio acuerdo
Decida si también se trasladan los buzones. Si el correo permanece donde está, conviértalo en un objetivo explícito: cambiar el destino web conservando la ruta del correo. Si se trasladan los buzones, planifique por separado volumen, sincronización, credenciales y dispositivos. Copiar mensajes antiguos y recibir nuevos son comprobaciones distintas.
MX identifica el servicio receptor. SPF describe los emisores autorizados para el dominio correspondiente; publicar varias políticas SPF independientes con el mismo nombre no es correcto. Dividir un único registro TXT en varias cadenas de texto es un caso diferente.
DKIM verifica una firma criptográfica asociada a un dominio: la clave pública se publica en DNS y la privada permanece secreta. DMARC comprueba la alineación de una identidad SPF o DKIM válida con el dominio visible de From. El éxito de un mecanismo no demuestra automáticamente todas las demás condiciones.
Identifique todos los remitentes legítimos: personal, formularios web, facturación y plataformas de marketing. No active una política DMARC estricta sin evaluar esos flujos. Acuerde el cambio con el responsable del correo en lugar de tratarlo como una modificación web rutinaria.
La ventana de cambio
La secuencia siguiente es un ejemplo organizativo. Las acciones concretas dependen del proveedor DNS, el hosting y el sistema de correo. Separe cada cambio de su verificación y de la condición para continuar. Varios cambios simultáneos sin comprobar dificultan identificar la causa de un fallo.
- Compruebe el nuevo entorno antes de cambiar DNS y conserve los resultados.
- Realice la sincronización final acordada y el plan de control de escritura.
- Cambie solo los registros web o mail previstos; sustituir toda la zona requiere otra decisión.
- Compare respuestas DNS autoritativas y de un resolver normal; una diferencia temporal no siempre es un error.
- Complete pruebas de aceptación separadas de web y correo antes de cerrar la ventana.
Supongamos que el sitio ficticio example.com utiliza un hosting web y un proveedor de correo independiente. Trasladar la web puede requerir un nuevo registro de origen mientras MX permanece igual. Cambiar nameservers no es obligatorio simplemente porque cambie el alojamiento web.
El SMTP del formulario de contacto necesita una comprobación independiente. Si empieza a utilizar el transporte local del nuevo servidor, la autenticación anterior podría dejar de describir la ruta de envío. Utilice un canal verificado y siga las instrucciones de su proveedor.
No acepte el nuevo host solo porque abra la portada. Compruebe una URL interna relevante, una subida y una operación que escriba en la base de datos. Evite que los dos entornos acumulen datos reales incompatibles. En una tienda activa son especialmente importantes la última sincronización y la ventana de escritura.
Una web operativa también exige comprobar el correo
Reducir TTL no invalida inmediatamente las respuestas que los resolutores ya almacenaron. Después del cambio autorizado, compare las respuestas autoritativas y los resolutores recursivos usados por los usuarios relevantes. Un resultado correcto en un dispositivo no demuestra que todas las redes hayan completado la transición.
Si también cambia el proveedor de correo, acuerde una copia inicial, sincronización final y momento de cambio. Revise alias, reenvíos, buzones compartidos y ajustes SMTP/IMAP de los dispositivos. Crear un buzón vacío no transfiere su historial.
Registre por separado las pruebas de entrada y salida de correo. Con un mensaje de prueba acordado, compruebe el intercambio con una dirección externa, el resultado de autenticación recibido y la cuenta SMTP que usa la propia web. Que funcione el buzón de un empleado no confirma la configuración SMTP del formulario.
Defina qué significa volver atrás
Restaurar un registro DNS no devuelve los mensajes recibidos en otro sistema. El plan debe indicar dónde se guarda el correo nuevo en cada fase, quién completa la sincronización y cuándo puede cancelarse el servicio anterior. No elimine datos solo porque la web funcione.
La reversión necesita algo más que un límite horario. Si volver al entorno anterior pierde mensajes o pedidos creados en el nuevo, restaurar una dirección DNS no basta. Defina qué sistema es la fuente de datos, cómo se conciliarán los cambios y quién decide.
Qué debe quedar al entregar el trabajo
Al entregar, deje una nota breve y comprensible: dónde funciona la web, dónde quedó o se trasladó el correo, quién gestiona la zona y qué pruebas terminaron. Separe lo pendiente. La siguiente persona no debería reconstruir qué sistema se pretendía cambiar.
Para una migración de hosting, adjunte el inventario y delimite por escrito el alcance de los buzones. Al elegir hosting web, confirme qué trabajo está incluido y cuál requiere un acuerdo adicional.
Para elegir el entorno después del traslado: Cómo elegir web hosting para una web empresarial: 7 preguntas antes del precio.
Fundamentos técnicos de DNS y autenticación de correo: IETF - SPF, RFC 7208; IETF - DKIM, RFC 6376; IETF - DMARC, RFC 9989.
