El correo no funciona después de cambiar DNS: qué revisar
Distingue recepción, envío y acceso al buzón. Revisa delegación, MX, autenticación y SMTP antes de modificar registros o volver al proveedor anterior.
Si el correo deja de funcionar después de cambiar DNS, primero comprueba qué servidores publican ahora la zona y si conservan los registros del proveedor de correo. Cambiar nameservers no crea buzones ni copia mensajes. Tampoco significa que debas cambiar los MX cuando el correo sigue en el mismo proveedor.
1. Distinguir qué está fallando
Haz tres pruebas independientes: entrar al webmail, recibir un mensaje externo y enviar a una dirección externa. Si utilizas formularios web, prueba también su envío; pueden depender de una configuración SMTP diferente.
- El webmail abre, pero no llegan mensajes: revisa MX y destino de recepción.
- No abre el servidor de correo por nombre: comprueba resolución del hostname y proxy.
- Se recibe, pero no se envía: revisa SMTP, autenticación, puertos y respuesta del proveedor.
- Se envía, pero hay rechazos o spam: interpreta la respuesta de entrega y autenticación del remitente.
- Solo fallan formularios web: revisa su configuración y servidor SMTP.
- Faltan mensajes antiguos: identifica dónde están los buzones y cómo se hizo la copia.
Conserva hora, destinatario de prueba y mensaje de error. Un rechazo explícito aporta más información que cambiar registros al azar.
2. Comprobar qué zona es autoritativa
El dominio puede tener paneles DNS en el registrador, el hosting y Cloudflare, pero solo la delegación activa determina qué servidores responden públicamente. Editar el panel anterior puede no cambiar las respuestas actuales.
Consulta la delegación y pregunta directamente a los nameservers activos. Para una comprobación inicial puedes utilizar:
dig NS ejemplo.com
dig MX ejemplo.com
dig TXT ejemplo.com
Sustituye el dominio de ejemplo por el tuyo. Una consulta al resolver local no describe todas las respuestas durante una transición. Compara los servidores autoritativos y otro resolver para distinguir configuración de caché.
Si todo el dominio falla, revisa también DNSSEC y el registro DS en el registrador. Un problema de validación puede afectar web y correo aunque los registros parezcan correctos en el panel.
3. Verificar MX y su destino
Compara los MX actuales con los indicados por el proveedor que debe recibir mensajes. Revisa nombre, destino y prioridad. No uses valores genéricos de una guía para otro servicio.
Si el MX apunta a un servidor bajo tu dominio, comprueba que ese hostname resuelve. La documentación de Cloudflare sobre correo explica la revisión de MX y registros asociados. Un hostname para SMTP, IMAP o POP debe configurarse como DNS sin depender del proxy web ordinario de Cloudflare.
Revisa si has activado un servicio de reenvío como Email Routing: puede gestionar registros de recepción y entrar en conflicto con el destino esperado. No añadas MX de proveedores distintos como si fueran una copia de seguridad sin confirmar esa arquitectura.
4. Confirmar buzones, alias y destino
Un MX correcto no sirve si el nuevo proveedor no tiene creado el destinatario. Prueba un buzón y un alias conocidos, verifica la cuota y consulta si el dominio está habilitado para recibir.
Si solo cambiaste DNS, los mensajes antiguos deben seguir donde estaban. Si cambiaste también de proveedor, la copia de buzones es un trabajo separado. Comprueba si el cliente de correo sigue conectado al origen y evita cerrar ese servicio antes de verificar la migración.
5. Revisar autenticación de envío
Comprueba el registro SPF y los selectores DKIM proporcionados por el servicio emisor. Si también envían la web u otras aplicaciones, identifica esos emisores antes de sustituir su configuración.
Revisa DMARC y su relación con la autenticación del mensaje. Un registro presente no garantiza entrega: interpreta las cabeceras y el motivo de rechazo. No reduzcas una política de autenticación sin identificar el fallo que intentas resolver.
Los valores correctos dependen del proveedor y de los servicios que envían en nombre del dominio. La documentación general ayuda a diagnosticar, pero no sustituye la configuración indicada para tu cuenta.
6. Comprobar clientes y formularios
Si puedes enviar desde webmail pero no desde una aplicación, revisa hostname, puerto, cifrado y credenciales del SMTP configurado. Una migración web puede haber perdido variables de entorno o dejado un servidor antiguo en el plugin del formulario.
Consulta los registros del envío y la respuesta del SMTP. Que una web muestre “enviado” no confirma que el destinatario recibió el mensaje. Prueba con una dirección externa y registra el resultado sin exponer contraseñas ni contenido privado.
7. Corregir y verificar antes de volver atrás
Aplica el cambio correspondiente al fallo identificado y repite pruebas de entrada, salida, alias y formulario. Registra valores anteriores y nuevos. Las respuestas almacenadas pueden seguir circulando hasta caducar; esperar no arregla un registro autoritativo incorrecto.
Volver al DNS anterior puede ayudar en determinadas incidencias, pero también devolver destinos web antiguos. Si ya hay mensajes en dos proveedores, conserva ambos y prepara una reconciliación antes de retirar uno.
Qué reunir para una revisión técnica
Prepara dominio, proveedor DNS activo, proveedor de correo, fecha del cambio, destinatario de prueba y error exacto. Comparte capturas sin credenciales y conserva una exportación de la zona si existe. Los accesos se solicitan por un canal adecuado cuando sean necesarios.
Podemos revisar DNS y dominios, organizar una migración de correo empresarial o comprobar dependencias de una migración de servidores. Para planificar el próximo cambio, consulta cómo migrar DNS sin interrumpir web y correo.