PiensaHost PiensaHost
Hable con un especialista
Guía práctica

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.

Revise el DNS cuando deja de recibir
Servidor autoritativo: Compruebe dónde se administra la zona real. Registro MX: Debe apuntar al proveedor de correo vigente. Nombre de destino: Verifique que resuelva como exige el servicio. Recepción real: Pruebe desde fuera y revise los registros.
No cambie toda la zona DNS para resolver un problema de correo.Ampliar infografía ↗

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:

Ventana de terminal
dig NS example.com +short
dig MX example.com +short

Compare 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.