Un cambio de MX o de registros DNS no es complejo técnicamente. Lo complicado es ejecutarlo sin impacto.
Porque en cuanto algo falla, el efecto es inmediato:
- Pérdida de correos
- Servicios inaccesibles
- Incidencias en cadena
Y, en la mayoría de los casos, no es un problema de configuración… es de planificación.
Qué implica realmente un cambio de DNS
Cuando modificas registros DNS (MX, A, CNAME, TXT…), no estás haciendo un cambio "instantáneo".
Lo que ocurre es:
- El cambio se aplica en el servidor autoritativo
- Los resolvers que tienen la información en caché siguen usando el valor antiguo
- Cada resolver actualizará según su TTL
Esto genera un escenario de propagación progresiva, donde durante un tiempo conviven dos realidades:
- Sistemas que apuntan al entorno anterior
- Sistemas que ya resuelven hacia el nuevo
Ese intervalo es donde aparecen la mayoría de las incidencias.
Hacer el cambio sin un entorno listo y validado
A nivel técnico, el cambio de un registro MX es inmediato.
Pero el endpoint al que apunta tiene que estar completamente operativo antes.
Errores habituales:
- Servidores de correo no testeados en producción
- Conectividad incompleta (firewalls, puertos 25/587/993…)
- Configuraciones DNS secundarias sin validar
Buen enfoque:
- Validar envío y recepción (SMTP, IMAP/POP) antes del cambio
- Comprobar conectividad externa (no solo interna)
- Testear autenticación (usuarios reales, no cuentas de prueba)
El registro DNS no puede ser el primer test.
No gestionar correctamente el TTL
El TTL define cuánto tiempo los resolvers cachean un registro.
Ejemplo típico:
- TTL actual: 86400 segundos (24h)
- Cambias el MX → habrá sistemas que seguirán usando el valor antiguo durante horas
Qué hacer a nivel técnico:
- Reducir el TTL del registro implicado (idealmente a 300–600 segundos)
- Esperar al menos un ciclo completo de TTL antes del cambio
- Ejecutar la modificación
- Una vez estabilizado, restaurar TTL a valores normales
Esto no acelera la propagación en sí… pero reduce el tiempo en que conviven estados distintos.
No contemplar la convivencia entre sistemas de correo
Durante la propagación DNS, el tráfico de correo puede dividirse:
- Algunos servidores enviarán al sistema antiguo
- Otros al nuevo
Si uno de los dos sistemas no está preparado, puedes tener:
- Pérdida de correos
- Mensajes encolados
- Situaciones de inconsistencia
A nivel práctico:
- Mantener ambos sistemas operativos durante la transición
- No desactivar el servidor antiguo inmediatamente
- Garantizar que ambos pueden gestionar correo entrante
En algunos casos, incluso se configuran reenvíos temporales como medida de seguridad.
Olvidar dependencias DNS indirectas
Un cambio de MX no es solo el MX.
Hay otros registros que influyen directamente en el funcionamiento del correo:
- SPF (TXT) → autorización de envío
- DKIM → firma de mensajes
- DMARC → políticas de validación
- PTR (reverse DNS) → reputación del servidor
Si no se actualizan correctamente:
- Correos rechazados
- Mensajes en SPAM
- Problemas de entregabilidad
Checklist técnico mínimo:
- Actualizar SPF con los nuevos servidores
- Validar DKIM en el nuevo sistema
- Revisar política DMARC
- Comprobar que el PTR coincide con el hostname del servidor
No planificar la ventana de cambio con criterio técnico
Hacer cambios DNS en horario de alta carga no es lo más recomendable.
No tanto por el cambio en sí, sino por:
- Volumen de tráfico concurrente
- Impacto inmediato en usuarios
- Dificultad para monitorizar correctamente
Buenas prácticas:
- Ejecutar el cambio en ventanas de baja actividad
- Monitorizar logs de correo en tiempo real
- Tener capacidad de respuesta rápida ante errores
No es solo "cuándo hacerlo", sino poder controlarlo mientras ocurre.
No preparar rollback técnico
Un cambio DNS siempre debe ser reversible.
Porque aunque todo esté validado, pueden aparecer variables no controladas:
- Políticas de seguridad externas
- Bloqueos por reputación
- Errores de configuración en clientes
A nivel técnico:
- Guardar los registros DNS originales
- Tener acceso inmediato al panel DNS
- Conocer el TTL activo para estimar reversión
El rollback no es inmediato, pero debe ser posible.
Cómo debería ser un cambio bien ejecutado
Cuando el proceso está bien planteado:
- El nuevo entorno ya está validado funcionalmente
- El TTL ha sido ajustado previamente
- Ambos sistemas conviven durante la transición
- Las configuraciones de seguridad están alineadas
- Y existe un plan de reversión
El resultado: el usuario no percibe el cambio.
Aunque los cambios de MX y DNS puedan parecer tareas sencillas desde un punto de vista técnico, su éxito depende de la planificación, la experiencia y la capacidad de anticiparse a posibles incidencias. Un error en cualquier fase puede afectar a la continuidad del negocio, provocar interrupciones en el servicio o comprometer la recepción y el envío de correos electrónicos.
Por eso, este tipo de proyectos deben ser gestionados por profesionales especializados, capaces de coordinar cada etapa del proceso, validar todos los sistemas implicados y garantizar un plan de contingencia ante cualquier imprevisto.
¿Vas a realizar un cambio de DNS, una migración de correo o una modificación de infraestructura?
En Fontventa ayudamos a las empresas a planificar y ejecutar cambios de infraestructura, migraciones de correo y modificaciones de DNS de forma segura, minimizando riesgos y asegurando que la operativa continúe con total normalidad durante todo el proceso.