Cómo configurar SPF, DKIM y DMARC en Cloudflare

Si estás tratando de aprender cómo configurar SPF, DKIM y DMARC en Cloudflare, comienza con un hecho simple: Cloudflare almacena los registros DNS, pero tu proveedor de correo suministra los valores. Eso suena pequeño. No es pequeño.

Cloudflare es el lugar donde viven los registros, y eso significa que editarás entradas TXT o CNAME en su panel DNS. La cadena de inclusión SPF real, el selector DKIM, la clave pública y la política DMARC provienen del servicio que envía tu correo, ya sea Google Workspace, Microsoft 365, SendGrid, Mailgun u otra plataforma. Sin esos valores, estás adivinando.

1. Confirma lo que Cloudflare puede y no puede hacer por la autenticación de correo electrónico

Cloudflare no inventa valores SPF, DKIM o DMARC. Solo los publica. Si tu proveedor dice que agregues un registro TXT para SPF, Cloudflare puede alojarlo. Si el proveedor te da un selector DKIM y un objetivo CNAME, Cloudflare también puede alojar eso. Pero no puede decidir qué servidores pueden enviar correo por ti.

Esto importa porque las personas a menudo abren Cloudflare primero y buscan un botón mágico. No hay ninguno. Necesitas el contenido exacto del registro de tu remitente antes de tocar DNS, o arriesgas publicar un registro que pasa una verificación en el panel y falla en un buzón real.

2. Recoge los valores DNS de tu plataforma de envío de correo

Antes de editar cualquier cosa, recoge tres cosas de la documentación del proveedor. Primero, reúne los mecanismos de inclusión SPF y cualquier dirección IP que el servicio quiera en tu registro SPF. Segundo, reúne los nombres de los selectores DKIM y los datos de la clave pública, o los objetivos CNAME si el proveedor utiliza DKIM basado en CNAME. Tercero, reúne la cadena de política DMARC, incluyendo la política con la que planeas comenzar y cualquier etiqueta de informes.

Escribe los valores en un solo lugar. Usa los nombres de selector exactos. Si tu proveedor te da dos selectores, no los renombres porque se ven desordenados. Si la documentación dice que el registro debe ser `_spf.example.net`, mantenlo así. Pequeños errores de formato causan largas tardes.

Hay un hábito útil aquí: captura el nombre del remitente, el nombre de host, el tipo de registro y la cadena de destino en una tabla antes de iniciar sesión en Cloudflare. Eso hace que la fase de edición sea más rápida, y también previene el error común de pegar el valor correcto en el campo de nombre incorrecto.

3. Agrega un registro SPF en Cloudflare DNS

En Cloudflare, abre DNS y crea o edita el registro TXT en la raíz del dominio si tu proveedor envía correo desde el dominio base. Algunos servicios utilizan un subdominio en su lugar, como `mail.example.com`, así que usa el nombre de host que tu proveedor especifica, no el que asumes. Un nombre de host. Un registro.

Un registro SPF generalmente debe existir solo una vez para un nombre de host. Ese es el punto que la gente pasa por alto. Si ya tienes un registro SPF TXT, no crees un segundo registro SPF TXT junto a él. Combina los remitentes autorizados en una sola cadena para que el servidor receptor vea una política, no dos respuestas en competencia.

Un valor SPF típico incluye mecanismos como `include:` o `ip4:`. Si tu servicio agrega un segundo remitente más tarde, actualiza el registro existente en lugar de agregar otro. Un registro SPF duplicado puede causar un permerror, lo que significa que los sistemas receptores pueden tratar la verificación como fallida incluso si las partes individuales parecen correctas.

Usa el nombre del registro que te proporciona tu proveedor. Para el dominio raíz, Cloudflare a menudo muestra `@` como el campo de nombre. Para un subdominio, ingresa esa etiqueta exacta. No agregues comillas alrededor del valor a menos que tu proveedor te lo indique explícitamente. Cloudflare almacena el texto como contenido DNS plano.

4. Publica registros DKIM TXT o CNAME en Cloudflare

DKIM es donde el selector importa. El proveedor puede darte un registro TXT como `selector1._domainkey` con una larga clave pública, o puede darte un registro CNAME que apunte a otro nombre de host. Cloudflare admite ambos, pero el tipo debe coincidir con lo que dice el proveedor. Un valor TXT en un campo CNAME no te ayudará.

Muchos servicios utilizan dos selectores. Eso es normal. Google Workspace a menudo utiliza dos claves durante la rotación, y otros proveedores hacen algo similar para que una clave pueda ser reemplazada sin interrumpir la entrega. Si el remitente te da `s1` y `s2`, publica ambos registros. Si un segundo remitente utiliza una familia de selectores diferente, mantén esos registros separados también. Los nombres pueden parecer repetitivos; los registros no son redundantes.

Ingresa el nombre de host DKIM exactamente como se indica. Si el proveedor te dice que crees `selector1._domainkey.example.com`, usa esa etiqueta completa en Cloudflare. Si el proveedor da un objetivo CNAME, pega el destino exactamente como está escrito. Cloudflare no necesita una traducción. Necesita precisión.

Para equipos que siguen la configuración de DKIM SPF DMARC para transacciones, se aplica la misma regla incluso cuando el volumen de correo es pequeño: el selector en DNS debe coincidir con el selector en el encabezado del mensaje. Si difieren, DKIM falla. Sin drama, solo falla.

5. Crea un registro DMARC en _dmarc

DMARC pertenece a `_dmarc.tudominio.com`. En Cloudflare, crea un registro TXT con ese nombre exacto. El valor comienza con `v=DMARC1`, luego agrega tu política y etiquetas opcionales. Una política de inicio común es `p=none`, porque te permite recopilar informes antes de bloquear cualquier cosa. Ese es el punto de partida menos agresivo.

Si tu organización está lista para recibir informes, agrega la etiqueta `rua` con la dirección de informes agregados y, si es necesario, la etiqueta `ruf` para informes forenses. Usa una dirección que alguien realmente monitoree. Un buzón muerto no es una estrategia. Es una trampa.

Una regla práctica ayuda aquí: comienza con una política DMARC que coincida con tu tolerancia actual a falsos positivos, luego ajústala más tarde después de que sepas que los remitentes legítimos están alineados. Si te mueves demasiado rápido, puedes bloquear facturas, alertas o restablecimientos de contraseña. Eso se nota de inmediato.

Cloudflare almacenará el registro TXT DMARC como cualquier otra entrada de texto, pero los detalles importan. El nombre del registro debe ser `_dmarc`, no `dmarc`, no `_dmarc1`, y no el dominio raíz. La cadena de política debe seguir la sintaxis que tu proveedor espera. Si tu plataforma de correo sugiere etiquetas como `sp`, `adkim` o `aspf`, agrégalas solo cuando entiendas el efecto.

6. Verifica la configuración específica de DNS de Cloudflare que puede bloquear la validación

Cloudflare tiene una configuración que causa más confusión de la que debería: el proxy. Los registros de autenticación de correo electrónico no deben ser proxied. SPF, DKIM y DMARC viven en DNS, no detrás de la nube naranja. Si accidentalmente proxy un nombre de host relacionado con el correo, estás mezclando las reglas de tráfico web con los registros DNS de correo electrónico.

Los nombres de los registros son otro punto de fallo común. Un selector DKIM que debería ser `selector1._domainkey` puede ser ingresado como `selector1._domainkey.` con un punto extra, o como `selector1 domainkey` con un espacio copiado de una página de proveedor. Cloudflare acepta muchas entradas de DNS, pero los sistemas receptores son menos indulgentes que la interfaz.

Los registros antiguos también pueden interferir. Si un antiguo registro SPF TXT permanece junto al nuevo, o si un CNAME DKIM obsoleto aún apunta a un servicio retirado, la validación puede fallar de maneras que parecen aleatorias. Elimina la entrada muerta solo después de confirmar que ya no es necesaria. Eso mantiene al remitente activo intacto.

Si también estás trabajando en la configuración de autenticación de correo electrónico para correos transaccionales, este es el momento de verificar cada host de envío listado por el proveedor. Un subdominio olvidado puede hacer que un mensaje de soporte pase mientras que un mensaje de recibo falle, y ese comportamiento dividido es difícil de detectar hasta que un cliente se queja.

7. Verifica la propagación y la autenticación de correo desde DNS gestionado por Cloudflare

Después de guardar los registros, espera la propagación de DNS. El tiempo exacto depende de tu TTL y de la caché del resolutor frente a ti, así que no asumas que el registro es visible en todas partes en el momento en que Cloudflare dice que está guardado. Verifica externamente con una herramienta de búsqueda de DNS y confirma que cada nombre de registro devuelve el valor esperado.

Luego envía un mensaje de prueba real desde el servicio que utiliza los registros. No pruebes desde una bandeja de entrada aleatoria que eluda tu flujo de correo normal. Abre los encabezados del mensaje en el buzón receptor y busca SPF pass, DKIM pass y DMARC alignment pass. El mensaje aún puede caer en spam por otras razones, pero el resultado de autenticación debería indicarte si el lado de DNS es correcto.

Una verificación rápida es suficiente para el primer pase, pero una segunda verificación desde un buzón diferente te da una mejor señal. Una prueba de Gmail y una prueba de Microsoft 365 pueden comportarse de manera diferente si un resolutor ve brevemente el registro antiguo mientras que otro ve el nuevo. Eso no es raro. Sucede.

Si la entregabilidad es parte del mismo proyecto, combina este trabajo con mejores prácticas de entregabilidad de correo electrónico. La autenticación no es toda la historia, pero es la parte que permite a los receptores decidir si tu dominio está hablando por sí mismo.

8. Actualiza los registros cuando tu proveedor de correo cambie

Las configuraciones de correo cambian. Un proveedor rota las claves DKIM, se añade una plataforma de marketing o se mueve un servicio de transacciones después de una migración. Cuando eso sucede, actualiza los registros DNS en Cloudflare antes de cambiar el tráfico, no después. Ese orden te ahorra un día de firmas rotas.

La rotación de DKIM es generalmente el cambio más limpio. El proveedor te da un nuevo selector y clave, lo publicas en Cloudflare y esperas hasta que el nuevo selector se valide antes de retirar el antiguo. Mantén ambos activos durante la transición si el proveedor lo soporta. Dos selectores son más fáciles que una interrupción.

Los cambios de SPF son un poco más delicados porque el registro debe mantenerse dentro de los límites de tamaño de TXT de DNS y de búsqueda establecidos por el estándar SPF. Si un nuevo remitente se une al grupo, añade su mecanismo de inclusión al registro SPF existente en lugar de apilar otro registro al lado. Si estás cerca del límite de búsqueda, reduce las inclusiones innecesarias donde sea posible y confirma la guía actual del proveedor.

Para equipos que envían a través de múltiples servicios, el mantenimiento se vuelve más fácil si una persona es responsable de la lista de remitentes autorizados. Esa lista debe nombrar el servicio, el nombre de host, el selector DKIM y la fecha del último cambio. Una tabla simple mantiene las ediciones de Cloudflare consistentes, y la consistencia importa más que la astucia.

Si el manejo de rebotes y los cambios de remitente son parte del mismo proyecto de buzón, la misma disciplina ayuda con las mejores prácticas de manejo de rebotes de correo electrónico. Una migración de proveedor puede cambiar tanto la autenticación como el comportamiento de error el mismo día, y ninguno de los dos lados debe ser adivinado.

Cloudflare hace que la parte de publicación sea sencilla, pero los registros aún necesitan disciplina. Un remitente. Un registro SPF. Cada selector DKIM en el lugar correcto. Un registro DMARC en `_dmarc`. Si mantienes esos cuatro puntos claros, el resto es principalmente paciencia, algunas verificaciones de encabezado y la disposición a actualizar DNS antes de que llegue el próximo cambio de plataforma.