Dejé de recibir correo después de cambiar DNS: qué comprobar
La web funciona, pero no recibe correo. Revise autoridad DNS, MX y destino antes de reinstalar aplicaciones o cambiar toda la zona.
La web carga bien después del cambio, pero dejaron de entrar mensajes. Es posible que la nueva zona DNS tenga lo necesario para el sitio y no para el correo.
Que la web funcione no confirma que la configuración de correo esté completa. Antes de reinstalar aplicaciones, compruebe quién responde por el dominio, qué destino anuncian los registros MX y si ese destino puede recibir los mensajes.
Consulte lo publicado, no solo lo guardado en un panel
Una cuenta puede conservar una zona que ya no es autoritativa. Editarla no cambia necesariamente las respuestas que reciben los demás servidores.
Estas consultas son de lectura para un equipo que tenga dig. Sustituya el dominio de ejemplo por el suyo:
dig NS example.com +shortdig MX example.com +shortCompare los servidores de nombres con el proveedor que debe administrar la zona. Después contraste los MX con los valores que su proveedor de correo confirmó para su dominio. No copie los MX de otra empresa solo porque utiliza la misma marca.
Revise el destino del MX
Un MX apunta a un nombre de servidor. Ese nombre debe resolver correctamente para el servicio previsto. Si falta su registro o apunta a un servidor anterior, el problema no se arregla agregando más buzones en el panel nuevo.
Cloudflare documenta la revisión de MX y nombres asociados al correo. En su configuración habitual, el proxy web no transporta SMTP: los nombres que sirven directamente al correo deben configurarse según las indicaciones del proveedor, normalmente como DNS only. Esto no significa desactivar la protección de toda la web.
Si activó un servicio de enrutamiento de correo, compruebe que no haya sustituido los MX esperados. No mezcle destinos de proveedores independientes como supuesto respaldo: ambos tendrían que estar preparados para ese diseño.
Diferencie caché de configuración incorrecta
Las respuestas DNS pueden permanecer en caché durante su TTL. Pero “espere a que propague” no explica un MX que sigue mal publicado en el servidor autoritativo.
Compare la respuesta autoritativa con la de los resolutores que intervienen en la prueba y anote cuándo se hizo el cambio. No hay un plazo universal que arregle un valor equivocado. Mantenga el diagnóstico asociado al error de entrega que observa el remitente.
Cuando la recepción vuelva a funcionar, revise también SPF, DKIM y DMARC. Son parte de la autenticación de envíos, no un sustituto del destino MX. La guía de registros de correo de Cloudflare permite distinguir sus funciones.
Antes de corregir, guarde cómo estaba
Conserve los valores anteriores y acuerde qué cambiará. Una corrección puntual es más fácil de validar que rehacer toda la zona. Si la autoridad DNS no está clara, deténgase y confirme quién controla el dominio: no cambie servidores de nombres a ciegas.
Después de corregir, haga una prueba externa autorizada y siga su llegada hasta el buzón. Revise si los mensajes anteriores fueron rechazados o siguen pendientes en los servidores de origen. No suponga que todo lo perdido reaparecerá; puede necesitar que el remitente vuelva a enviarlo.
Un responsable para la web y otro para el correo también necesitan coordinarse
La separación de servicios puede ser útil, siempre que se conozcan las dependencias. Antes del próximo cambio, incluya el correo en la lista de verificaciones y deje un contacto técnico para ambas partes.