Las limitaciones de Cloudflare Email Routing que el tutorial no menciona

Ningún tutorial de enrutamiento de correo electrónico de Cloudflare comienza explicando lo que el servicio no hace. Muestran la configuración en cinco pasos, confirman que el correo electrónico ha llegado a su destino y cierran. Lo que queda fuera son los casos en los que el reenvío comienza a rechazar mensajes legítimos, el mensaje general se convierte en spam o el trabajador descarta el correo electrónico del cliente porque una línea de código generó una excepción. Estos casos existen, son predecibles y conviene conocerlos antes de poner en producción el servicio por algo crítico.

El envío mediante dominio no existe aquí

El punto más importante y el que con mayor frecuencia se malinterpreta: Email Routing recibe correo electrónico. Solo. No hay forma de enviar un mensaje desde voce@seudominio.com usando este servicio. Cuando configuras el reenvío y alguien te envía un correo electrónico a contato@seudominio.com, lo recibes en Gmail. Cuando respondes en Gmail, el remitente que ve el destinatario es tu dirección de Gmail, no el alias de tu dominio.

Para enviar correo electrónico a través de su propio dominio necesita un servicio independiente: Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Cada uno de ellos requerirá sus propios registros DNS: SPF y DKIM específicos del proveedor elegido. Cloudflare configura automáticamente los registros SPF para los entrantes, pero no tiene nada que ver con los registros que necesitará un proveedor saliente. Cualquiera que mezcle los dos flujos en la misma configuración DNS termina con errores de autenticación en ambas direcciones.

El problema de la capacidad de entrega con el reenvío y DMARC

Cuando Cloudflare reenvía un correo electrónico, transmite el mensaje desde sus propios servidores, no desde los servidores originales del remitente. Esto crea fricciones con DMARC que afectan a casos específicos pero importantes.

Si el remitente original tiene una política DMARC con p=reject (común en bancos, grandes empresas, proveedores de correo electrónico como Gmail y Outlook) y el correo electrónico se reenvía a través de Cloudflare, el servidor de destino final recibe un mensaje cuyo encabezado From: muestra el dominio del remitente original, pero cuya IP de envío pertenece a Cloudflare. La alineación DMARC falla porque SPF verifica la IP de envío (Cloudflare) con el dominio en From: (el banco, la empresa) y no se alinean.

Cloudflare utiliza ARC (cadena recibida autenticada) al reenviar, lo que conserva la información de autenticación del salto original. Esto mejora la situación para los proveedores que entienden y respetan ARC (Microsoft y Google incluidos). Pero no es universal. Algunos servidores de correo electrónico corporativo con políticas más estrictas aún rechazan el correo electrónico reenviado incluso con ARC. El resultado práctico: es posible que pierda correos electrónicos legítimos enviados desde estrictos dominios p=reject y Cloudflare no tiene control sobre la política de recepción del servidor de destino.

No existe una solución completa para esto dentro del enrutamiento de correo electrónico. Cualquiera que necesite entrega garantizada a todos los remitentes posibles necesita una solución con su propia bandeja de entrada: Google Workspace, Fastmail, Microsoft 365.

Catch-all y el spam que lo acompaña

Habilitar el catch-all *@seudominio.com es útil: cualquier dirección que proporcione en formularios, boletines y eventos cae en la misma bandeja de entrada sin tener que crear alias de antemano. El problema es que los spammers escanean dominios que intentan enviar correo electrónico a direcciones aleatorias. Con el modo general activo, cada intento llega a su bandeja de entrada.

Un dominio con cierta exposición en la web puede recibir cientos de correos electrónicos al día a direcciones que nunca existieron: info@, admin@, noreply@, sales@, variaciones aleatorias. Todos llegan. Gmail tiene filtros de spam, pero el volumen genera ruido.

La mitigación dentro del enrutamiento de correo electrónico es enrutar el sistema general a un trabajador de correo electrónico en lugar de directamente a una dirección de destino. El trabajador puede verificar si la dirección de destino es uno de los alias legítimos que usted definió, rechazar todo lo que no coincida y reenviar solo el resto. Mantiene una flexibilidad general sin aceptar toda la basura.

El trabajador que deja caer el correo electrónico en producción

Los Email Workers tienen un comportamiento que toma desprevenidos a los desarrolladores: si el Worker lanza una excepción no detectada, el mensaje se rechaza con un error 5xx. No hay reintento, no hay cola, no hay letra muerta. El correo electrónico desaparece.

Imagine un trabajador que realiza una PUBLICACIÓN en una API externa para crear un ticket de soporte. La API externa no funciona. El trabajador arroja un error de red. El correo electrónico del cliente que solicita asistencia se rechaza y nunca se entera a menos que el cliente vuelva a intentarlo y se queje.

El patrón correcto es envolver toda la lógica de procesamiento en un try/catch y, en catch, llamar a message.forward() para obtener una dirección de clasificación manual. El correo electrónico no se pierde y puede procesar lo que falló una vez que regrese el servicio externo. Sin este respaldo, cualquier falla transitoria en cualquier dependencia del trabajador se convierte en correo electrónico perdido.

¿Qué cambia cuando vas más allá de los casos base?

El simple reenvío de algunos alias a direcciones de Gmail o Fastmail funciona de forma fiable y sin sorpresas. Aparecen problemas cuando agrega dependencias: trabajadores con llamadas externas que pueden fallar, casos generales sin filtrado, escenarios con remitentes que tienen DMARC restringido. En estos casos, el servicio sigue siendo útil, pero requiere que usted comprenda las superficies de falla y cree las mitigaciones correspondientes.