La autenticación de correo electrónico tiene tres capas (SPF, DKIM y DMARC) y un error común que cometen quienes usan Cloudflare Email Routing es asumir que la activación del servicio resuelve las tres a la vez. Cloudflare configura SPF para la recepción automáticamente, maneja DKIM a través de ARC en correos electrónicos reenviados y no configura DMARC por usted. Si utiliza un proveedor de envío independiente, el SPF y el DKIM de ese proveedor deben agregarse manualmente. Confundir estos roles lleva a que se rechacen los correos electrónicos, a veces los suyos propios.
Qué hace SPF y qué añade Cloudflare
SPF (Sender Policy Framework) es un registro TXT en su zona DNS que enumera los servidores autorizados para enviar correo electrónico a través de su dominio. Cuando un servidor receptor acepta un correo electrónico que dice ser de seudominio.com, consulta el SPF de seudominio.com para verificar si la IP de envío está en la lista.
Cuando habilitas el enrutamiento de correo electrónico, Cloudflare agrega automáticamente un include:_spf.mx.cloudflare.net al SPF de tu dominio. Esto autoriza a los servidores de Cloudflare a recibir correo electrónico para su dominio, lo cual tiene sentido, porque son los servidores que aceptarán los mensajes entrantes antes de reenviarlos.
El punto que requiere atención: si también utiliza un proveedor de envío saliente (Resend, SendGrid, Amazon SES, Mailgun), este proveedor tiene sus propios servidores que deben aparecer en su SPF. El registro SPF final debe incluir tanto a Cloudflare como al proveedor de envío. Un ejemplo con Reenviar:
v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all
SPF tiene un límite de 10 búsquedas de DNS por evaluación. Cada include: cuenta como una búsqueda y puede desencadenar búsquedas más recursivas. Con muchos proveedores combinados, es posible exceder este límite, lo que hace que el SPF falle para todos los remitentes, no solo para algunos. Herramientas como MXToolbox y dmarcian tienen validadores que cuentan las búsquedas y le avisan antes de que se convierta en un problema.
DKIM al recibir y enviar
DKIM (DomainKeys Identified Mail) funciona mediante cifrado asimétrico: el servidor emisor firma el correo electrónico con una clave privada y el servidor receptor verifica la firma con la clave pública publicada como un registro TXT en el DNS del dominio emisor.
Para los correos electrónicos recibidos y reenviados a través del enrutamiento de correo electrónico, Cloudflare utiliza ARC (cadena de recepción autenticada). ARC es un conjunto de encabezados que registra la cadena de autenticación de correo electrónico a medida que pasa a través de intermediarios, en este caso, el servidor de Cloudflare. Cuando Cloudflare reenvía un correo electrónico, agrega encabezados ARC que le dicen al servidor receptor final: "Recibí este correo electrónico, la firma DKIM original era válida en el momento en que llegó aquí y lo renunciaré para preservar esa información". Cloudflare vuelve a firmar con su propia clave DKIM al reenviar.
Para los correos electrónicos enviados por su proveedor saliente, DKIM funciona de manera diferente. Resend, SES o cualquier otro proveedor de envío le pedirá que agregue uno o más registros TXT a su zona DNS con su clave pública DKIM. Agrega estos registros al panel de Cloudflare y el proveedor utiliza la clave privada correspondiente para firmar los correos electrónicos que se envían a través de su dominio. Cloudflare no genera ni administra esta clave; simplemente aloja el registro TXT que creó el proveedor.
DMARC: qué configurar y en qué orden
DMARC (Autenticación, informes y conformidad de mensajes basados en dominio) se encuentra en un registro TXT en _dmarc.seudominio.com y define qué deben hacer los servidores receptores cuando un correo electrónico falla en SPF y DKIM simultáneamente. También define dónde enviar informes de autenticación.
Cloudflare no configura DMARC por usted. El registro lo creas manualmente. Un registro inicial razonable:
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; pct=100
p=none significa “vigilar, no rechazar”. Los informes llegan a las direcciones definidas en rua (informes agregados diarios) y ruf (informes forenses de fallos). Estos informes en formato XML muestran qué IP están enviando correo electrónico a través de su dominio y cuál es el resultado SPF/DKIM para cada una.
La secuencia correcta es esta: active p=none primero, espere al menos una semana de informes, verifique que todos los remitentes legítimos (el proveedor de envío, los servidores de formularios, las herramientas de marketing) aparezcan alineados en SPF o DKIM. Solo después de confirmar esta alineación pasa a p=quarantine (los correos electrónicos sospechosos se convierten en spam) y, finalmente, a p=reject (los correos electrónicos sospechosos se rechazan al recibirlos).
Activar p=reject antes de agregar los registros SPF y DKIM del proveedor de envío es el error más común. El resultado: sus propios correos electrónicos comienzan a ser rechazados por los servidores de destino porque salen a través de Resend o SES pero SPF aún no incluye esos servidores, o el registro DKIM aún no se ha agregado. DMARC falla y con p=reject el correo electrónico se rechaza, silenciosamente desde la perspectiva del remitente.
Qué comprobar antes de cambiar la política DMARC
Antes de pasar de p=none a cualquier política más restrictiva, vale la pena verificar tres cosas en los informes agregados: que Cloudflare aparece como SPF alineado para los correos electrónicos entrantes que usted reenvía a sus propias cuentas, que el proveedor de envío aparece como DKIM alineado para los correos electrónicos salientes y que no hay IP inesperadas que envíen correos electrónicos a través de su dominio, lo que indicaría una configuración de otro servicio que usted no mapeó o hizo un mal uso.
Herramientas como dmarcian, Postmark (que tiene un analizador DMARC gratuito) y MXToolbox facilitan la lectura de los informes XML. Vale la pena el tiempo invertido. Un dominio con DMARC configurado correctamente tiene menos posibilidades de que los destinatarios acepten correos electrónicos falsificados y menos posibilidades de que se rechacen correos electrónicos legítimos debido a una falla de configuración.
Lea también
- Las limitaciones de Cloudflare Email Routing que el tutorial no menciona
- Enrutamiento de correo electrónico de Cloudflare: reciba correo electrónico en su dominio y lo que no está incluido
- Cloudflare KV: ¿Qué significa distribuido globalmente cuando necesitas escribir?
- Cloudflare Workers vs Pages: la diferencia que importa antes de elegir
- Enrutamiento de correo electrónico vs Improvmx vs Reenvío de correo electrónico: comparación honesta
- Enrutamiento de correo electrónico + Trabajadores: procesar correos electrónicos mediante programación en el borde