¿Cómo debería implementar un equipo de producto el enrutamiento de correo de Cloudflare de forma segura?

Defina la función del correo entrante y los límites de responsabilidad

Empiece por documentar exactamente la función del correo entrante: qué dominio y qué partes locales deben aceptar correo, quién es responsable de cada destino, si un mensaje debe reenviarse, procesarse mediante código o descartarse, y durante cuánto tiempo se puede conservar la evidencia operativa. Cloudflare Email Routing es una capa de enrutamiento de correo entrante. Por sí sola no crea un ticket de soporte, no establece la identidad del remitente, no demuestra que el correo reenviado haya llegado a una persona ni garantiza la llegada al buzón de destino. Mantenga separados esos estados posteriores de la aplicación. Asigne un responsable operativo para el DNS, las reglas de enrutamiento, el código del Worker, la verificación de destinos, los incidentes de seguridad y la reversión. Use alias dedicados como support@ o invoices@ en lugar de un catch-all durante el primer despliegue. Una ruta acotada reduce la recopilación accidental, hace que los resultados de las pruebas sean interpretables y limita el impacto de un destino o una rama del Worker equivocados.

Incorpore el dominio sin tratar el DNS como un paso de instalación a ciegas

La documentación actual de Cloudflare Email Service indica que el dominio debe usar Cloudflare DNS para Email Routing. El flujo de incorporación puede agregar registros MX para el enrutamiento de correo entrante, además de los registros TXT relacionados con SPF y DKIM que describe el producto. Revise exactamente los registros propuestos antes de aplicarlos. Primero, haga un inventario de los MX, SPF, DKIM y DMARC existentes, los buzones, los servicios de reenvío, los tokens de verificación y las delegaciones de subdominios. Reemplazar los registros MX cambia a dónde van las nuevas sesiones SMTP entrantes, así que coordine una ventana de mantenimiento y conserve los valores anteriores como registro de reversión. Evite crear varios registros TXT de SPF en un mismo nombre de propietario. Después del cambio, consulte los resolvedores autoritativos y públicos, y luego pruebe la entrega desde una cuenta sin relación con el destino. Las estimaciones de propagación DNS no demuestran que todos los remitentes vean ya la misma respuesta, y un panel en verde no demuestra un reenvío de extremo a extremo.

Verifique los destinos antes de crear rutas activas

Cloudflare documenta las direcciones de destino como recursos a nivel de cuenta que deben verificarse antes de que las reglas de enrutamiento puedan usarlas. El paso de verificación es una barrera importante contra el abuso: demuestra el control del buzón en ese momento, pero no establece una autorización comercial continua ni la pertenencia correcta al equipo. Registre en su propio sistema al responsable solicitante, el propósito, la fecha de verificación y la fecha de revisión. Prefiera un destino controlado por el equipo antes que la dirección personal de un empleado. Elimine rápidamente los destinos de usuarios que ya no están en la empresa y compruebe qué reglas dependen de una dirección antes de borrarla, porque Cloudflare documenta que eliminar un destino desactiva las rutas que lo usan. Trate los correos de verificación como sensibles para la seguridad y nunca haga clic automáticamente en ellos ni los reenvíe a automatizaciones no confiables. Para los cambios en producción, exija la revisión de una segunda persona en su proceso habitual de infraestructura, aunque el propio panel permita que un único operador guarde la regla.

Cree reglas explícitas y comprenda la precedencia

Una regla de enrutamiento asocia un patrón de correo con un destino verificado o con un Worker. Cloudflare documenta tres acciones: enviar a un correo, enviar a un Worker y descartar. Cree primero las rutas de parte local más específicas, indique su responsable en los registros de cambios y confirme que solo haya una regla prevista por patrón. La documentación advierte que, si varias reglas usan el mismo patrón, solo la regla que aparece primero procesa el correo entrante. No dependa del orden visual como regla de negocio informal; elimine la ambigüedad. Justifique de forma estricta las reglas de descarte, porque eliminar es intencionadamente no entregar. Habilite el catch-all solo después de enumerar sus consecuencias en privacidad, volumen de spam, errores tipográficos y almacenamiento. Un catch-all puede recopilar direcciones que nadie pretendía crear, por lo que debería tener un destino o una política de Worker dedicados, alertas y una forma rápida de desactivarlo, en lugar de heredar discretamente un buzón personal.

Use el subdireccionamiento de forma deliberada

Cloudflare documenta un direccionamiento con signo más opcional, coherente con RFC 5233. Cuando está habilitado, el correo para una dirección como user+detail@example.com puede coincidir con la regla base user@example.com, conservando el detalle en el destinatario del mensaje que ven el Worker y los registros. Esto puede servir para etiquetas de enrutamiento, identificadores de prueba o alias por flujo, pero el detalle es texto controlado por el remitente. No lo trate como identidad de inquilino autenticada, autorización ni secreto. Normalícelo y acótelo antes de usarlo como clave de base de datos, dimensión de métricas o nombre de cola. Cloudflare también documenta que una regla explícita para la subdirección completa tiene prioridad sobre la regla base. Pruebe tanto el caso explícito como el de respaldo para que una regla específica posterior no cambie en silencio un flujo existente. Evite poner datos personales o confidenciales en las etiquetas con signo más, porque pueden aparecer en encabezados, registros, mensajes reenviados, exportaciones de soporte y analíticas.

Elija un Worker solo cuando haya una necesidad real de procesamiento

Use el reenvío directo cuando el requisito sea simplemente una dirección hacia un buzón verificado. Enrute a un Worker cuando necesite ramificaciones controladas, inspección de mensajes, almacenamiento, rechazos, respuestas o varios reenvíos. El manejador de correo de Cloudflare expone el remitente y el destinatario del sobre, los encabezados, un flujo MIME sin procesar, su tamaño y métodos para reenviar, responder o rechazar. Mantenga el manejador pequeño: valide primero la política de destinatarios, aplique límites al mensaje y al análisis, haga las llamadas externas mediante colas con límite de tiempo siempre que sea posible y defina el resultado de cada error. Los encabezados, asuntos, nombres para mostrar, adjuntos, enlaces y límites MIME están controlados por el atacante. No registre cuerpos sin procesar ni direcciones completas de forma predeterminada. Si es necesario almacenar el contenido, cífrelo, restrinja el acceso por inquilino y por trabajo, defina su eliminación y analice los adjuntos fuera de la ruta de enrutamiento síncrona. Una excepción de análisis no debe desembocar en un reenvío o una respuesta no previstos.

Implemente una única ruta de decisión explícita

Un manejador seguro debería calcular una acción aprobada antes de producir efectos secundarios. Por ejemplo, asigne el destinatario exacto del sobre a un flujo configurado, rechace los destinatarios desconocidos, ponga en cola un registro de metadatos acotado y luego reenvíe solo a un destino verificado seleccionado de la configuración. Nunca acepte un destino procedente de un encabezado, el asunto, una etiqueta con signo más o el cuerpo del mensaje. Al reenviar a varios destinos, la documentación de límites de Cloudflare indica que un Worker debe llamar a forward una vez por cada destino verificado; decida si un éxito parcial es aceptable y registre cada intento por separado. Use un identificador de correlación interno y estable en lugar del contenido del destinatario en los registros. Si el manejador puede responder, siga las restricciones actuales de respuesta de Cloudflare y agregue protección contra bucles. Una respuesta no es un acuse de recibo de un equipo humano. Si necesita una recepción duradera en la aplicación, guarde el ticket o el evento antes de enviar una respuesta automática y concilie los fallos ambiguos en lugar de prometer que el trabajo se creó.

Trate los reenvíos y las respuestas como resultados con evidencia acotada

Una llamada exitosa a un método del Worker es evidencia de la operación de la plataforma, no del resultado final para el usuario. SMTP define la transferencia entre sistemas, mientras que el filtrado posterior, el reenvío, la cuarentena, las reglas del buzón y la lectura humana quedan fuera de ese salto. Modele por separado estados como recibido por Cloudflare, Worker invocado, acción intentada, aceptado por el servidor de destino, demorado o fallido, y registro de aplicación creado. No los etiquete todos como entregados. Mantenga registros estructurados y con datos personales minimizados, con la identidad de la regla, la revisión del Worker, la acción, la marca de tiempo, el identificador de correlación y un resultado general; guarde las direcciones o el contenido completos solo donde una necesidad operativa documentada lo justifique. Configure alertas para los fallos de invocación, los rechazos por tamaño, un volumen anómalo de catch-all, los patrones de remitentes repetidos, los fallos de destino y los cambios bruscos de tráfico. Envíe mensajes de prueba controlados de forma continua, pero nunca use contenido real de clientes como material de observabilidad.

Respete los límites actuales de la plataforma y sus modos de fallo

Cloudflare documenta actualmente límites de Email Routing que incluyen 200 reglas de enrutamiento por dominio, 200 direcciones de destino por cuenta, un límite de tamaño de 25 MiB para los mensajes entrantes y los límites estándar de CPU y memoria de Workers para los mensajes enrutados a un Worker. Trátelos como documentación actual del proveedor, no como constantes permanentes. Lea la página de límites en vivo durante la planificación y configure alertas mucho antes de acercarse a un tope. Los mensajes MIME grandes pueden agotar la memoria o la CPU incluso por debajo del tamaño bruto máximo de la plataforma si se decodifican sin precaución. Procese en streaming o rechace el contenido innecesario, limite el número de adjuntos y traslade el análisis costoso a un trabajo asíncrono acotado. Según la documentación de enrutamiento de Cloudflare, cambiar el nombre de un Worker puede romper su vínculo de enrutamiento, así que incluya la inspección de rutas en la verificación del despliegue. Las invocaciones fallidas deberían ser visibles en los registros de Workers, pero los registros por sí solos no permiten reproducirlas. Decida si un remitente debe reintentar por SMTP, si un operador puede volver a ejecutar un trabajo de la aplicación de forma segura y cómo se evitan los registros duplicados en los sistemas posteriores.

Pruebe el despliegue y la reversión como un solo cambio

Cree primero una ruta de staging o de bajo riesgo. Envíe mensajes controlados desde una cuenta distinta del destino verificado, cubriendo texto sin formato, contenido multipart, adjuntos esperados, direccionamiento con signo más, partes locales desconocidas y entradas deliberadamente mal formadas dentro de límites seguros. Verifique las respuestas DNS, la configuración del panel, la revisión del Worker, el resultado del reenvío, el registro en los sistemas posteriores y el comportamiento en materia de privacidad. Luego pruebe las rutas negativas: destino no verificado, regla desactivada, excepción del Worker, mensaje demasiado grande, entrega repetida y una regla que de otro modo caería en el catch-all. Registre la evidencia esperada para cada etapa. Antes de ampliar el tráfico, ensaye la desactivación de la regla, la restauración de los registros MX anteriores si fuera necesario, la desvinculación del Worker y la comunicación del correo demorado o rechazado. Revierta ante una pérdida de enrutamiento sin explicación, una exposición entre inquilinos, una filtración de contenido, respuestas inesperadas, un almacenamiento sin límites o fallos sostenidos del Worker. Conserve instantáneas de la configuración y los resultados de las pruebas sin retener el contenido de los mensajes más tiempo del necesario.

Cómo encaja SendHQ

SendHQ admite correo entrante. Esta guía cubre Cloudflare Email Routing; siga la documentación de cada servicio para su propia configuración y sus límites.

Preguntas frecuentes

Fuentes

• Enrutar correos (Route emails) — Cloudflare
• Reglas y direcciones de enrutamiento de correo — Cloudflare
• API de Workers para el correo enrutado — Cloudflare
• Límites de Cloudflare Email Service — Cloudflare
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor
• RFC 5233: filtrado de correo con Sieve, extensión de subdirecciones — RFC Editor