El correo dejó de funcionar al activar Cloudflare: qué revisar
Distingue registros omitidos, destinos de correo detrás del proxy y cambios de recepción antes de desactivar Cloudflare o modificar todos los DNS.
Si el correo falla al activar Cloudflare, comprueba qué cambió realmente: la delegación del dominio, los registros que se publican o el proxy de un nombre utilizado por el correo. Que la incidencia empiece en ese momento no demuestra que debas desactivar Cloudflare para toda la web.
Esta guía se centra en ese cambio concreto. Si utilizas otro proveedor DNS o todavía no sabes qué capa falla, empieza por el diagnóstico de correo después de cambiar DNS.
1. Identificar qué cambió y qué dejó de funcionar
Anota cuándo se activaron los nameservers y si alguien modificó registros o servicios de correo al mismo tiempo. Distingue entrar al webmail, conectarte desde el cliente, recibir mensajes y enviarlos: no son la misma prueba.
Como ejemplo hipotético, el webmail del proveedor puede seguir funcionando mientras el programa del ordenador no conecta con un nombre bajo tu dominio. Otro caso diferente es que el programa abra mensajes antiguos, pero ningún correo nuevo llegue. Describe el síntoma antes de corregir registros.
2. Comparar la zona publicada con los datos del proveedor
Conserva una exportación o captura de la configuración anterior y comprueba qué zona responde ahora. No edites simultáneamente el panel del hosting antiguo y el de Cloudflare esperando que ambos sean autoritativos.
Revisa los MX y los nombres que necesita el correo. Confirma sus valores con el producto contratado: copiar registros de otra empresa que utiliza la misma marca no garantiza que sean correctos para tu cuenta. No des por completa una importación automática sin comparar los registros relevantes.
Los buzones, alias y mensajes siguen siendo otra capa. Cambiar DNS no copia el historial ni crea cuentas en un proveedor distinto. Si también se está trasladando el correo, utiliza el preparador de migración de correo para ordenar ese alcance.
3. Revisar el proxy del nombre utilizado por el correo
La documentación de Cloudflare indica que SMTP, IMAP y POP3 no funcionan mediante su proxy HTTP estándar. Los nombres utilizados para esas conexiones deben resolver al destino adecuado sin ese proxy. El MX no se proxifica, pero hay que revisar también el nombre al que apunta.
Las limitaciones del proxy son importantes cuando web y correo comparten un nombre. No cambies el dominio principal a DNS only sin comprobar qué servicios dependen de él y qué protección web perderías. Solicita al administrador un destino de correo adecuado cuando sea necesario separarlos.
Esta comprobación no implica desactivar el proxy de todos los registros. Corrige el nombre afectado y verifica su resolución y uso antes de ampliar el cambio.
4. Comprobar si se activó Email Routing
Cloudflare documenta que Email Routing gestiona registros MX y puede entrar en conflicto con los de otro proveedor de correo. Si la recepción debe seguir en el proveedor original, revisa si se habilitó este servicio y qué ruta está activa.
No añadas MX de ambos proveedores para intentar cubrir las dos opciones. Define primero el destino previsto y sigue el procedimiento correspondiente. Si existe reenvío, comprueba sus direcciones y resultados por separado de los buzones originales.
5. Separar autenticación de envío y recepción
Si ya recibes mensajes, pero tus envíos se rechazan o terminan en spam, revisa los emisores y la autenticación. No cambies los MX como respuesta automática a un problema de salida.
La guía de SPF, DKIM y DMARC al cambiar de proveedor desarrolla esa comprobación. Debe contemplar tanto los buzones como los servicios que envían desde la web, el CRM o la tienda, sin publicar contraseñas ni mensajes privados en herramientas de terceros.
6. Verificar un cambio cada vez
Registra el valor anterior, el nuevo y la hora de intervención. Después prueba recepción y envío externos y la conexión del cliente con el nombre configurado. Si el error continúa, conserva su texto exacto para distinguir resolución, conexión, autenticación y rechazo del destinatario.
No atribuyas cualquier fallo a propagación. Una caché puede conservar respuestas anteriores, pero esperar no corrige un destino equivocado. Tampoco conviene volver a los nameservers anteriores sin valorar qué otros cambios web se perderían.
Cuándo solicitar una revisión técnica
Prepara el dominio, el proveedor de correo, los nameservers activos y el error observado, sin incluir claves. Indica también si cambió el hosting o únicamente la gestión DNS.
Podemos revisar la configuración de Cloudflare y la gestión de DNS y dominios. Si necesitas mover mensajes y cuentas, la migración de correo empresarial se trata como un trabajo distinto de corregir los registros.