Configurar DMARC, SPF y DKIM en Cloudflare DNS

dig NS ejemplo.es +short

Tipo      : TXT
Nombre    : _dmarc
Contenido : v=DMARC1; p=none; rua=mailto:informes@ejemplo.es
TTL       : Auto

SPF en la raíz, DKIM en el formato del proveedor

Primero SPF. Es un TXT colocado en la raíz de la zona: en el campo Nombre, @ designa el propio dominio.

Tipo      : TXT
Nombre    : @
Contenido : v=spf1 include:spf.protection.outlook.com include:_spf.brevo.com -all

El valor agrupa a todos los emisores legítimos, cada uno mediante su include:. Regla absoluta: un solo registro que empiece por v=spf1 por nombre. Un nuevo emisor se añade dentro del registro existente, nunca como un segundo TXT.

Después DKIM — y ahí el proveedor dicta el formato. Conviven dos escuelas:

• El TXT directo: el proveedor entrega una clave pública para pegar. Google Workspace, por ejemplo: Nombre google._domainkey, contenido v=DKIM1; k=rsa; p=MIIBIjANBg….
• El CNAME de delegación: el proveedor entrega uno o varios alias que apuntan a sus propios servidores, donde vive la clave — y donde rota sin intervención de nadie. Microsoft 365 pide dos: selector1._domainkey y selector2._domainkey, apuntando a selector1-ejemplo-es._domainkey.ejemplo.onmicrosoft.com y a su gemelo. SendGrid, Mailjet o Brevo hacen lo mismo con sus propios nombres (s1._domainkey, s2._domainkey…).

Ambos formatos se crean en el mismo sitio, eligiendo el tipo TXT o CNAME. La delegación por CNAME tiene una ventaja real — la rotación de claves pasa a ser asunto del proveedor —, pero plantea en Cloudflare una cuestión específica, tratada dos secciones más abajo.

Lo que es propio de Cloudflare

Tres particularidades distinguen la plataforma de las interfaces DNS clásicas.

El estado de proxy no aplica a los TXT. La famosa nube naranja — el proxy que hace pasar el tráfico web por la red de Cloudflare — solo concierne a los registros A, AAAA y CNAME. Los TXT (_dmarc, SPF, una clave DKIM pegada) sencillamente no llevan ese conmutador: ninguna decisión que tomar, ningún error posible. La cuestión solo se plantea con los CNAME de selectores, y se trata justo después.

El TTL «Auto» vale 300 segundos. Para un registro sin proxy, «Auto» significa cinco minutos. Es un ajuste excelente para registros de autenticación: una corrección se propaga rápido, un error se subsana rápido. Nada obliga a tocarlo, y buscar un TTL largo «para aliviar los servidores» carece de sentido en una red anycast de ese tamaño.

Una herramienta «DMARC Management» viene integrada. En la sección de correo de la zona, la plataforma ofrece un módulo que publica el registro _dmarc y recoge los informes agregados en una dirección rua alojada por Cloudflare, con gráficos en el panel. Es una funcionalidad de la plataforma DNS, gratuita, que puede servir de primer contacto con los informes agregados. Conviene saber algo antes de activar nada: la etiqueta rua acepta varias direcciones separadas por comas. La dirección de recogida de Cloudflare puede por tanto convivir con otro destino — y la elección de la dirección de recepción de los informes DMARC merece su propia reflexión, porque condiciona toda la explotación posterior.

CNAME de selectores: nube gris obligatoria, «flattening» que conviene conocer

La trampa número uno de Cloudflare para el correo cabe en un color. Al crear un CNAME, la interfaz propone de buen grado el proxy (nube naranja). Para una web suele ser la opción correcta; para un selector DKIM es fatal. Un CNAME con proxy desaparece de la vista pública: Cloudflare responde en su lugar con sus propias direcciones IP para servir tráfico web, y una consulta TXT sobre selector1._domainkey.ejemplo.es ya no devuelve nada. La clave se vuelve ilocalizable, las firmas DKIM fallan, y la alineación DMARC queda colgando solo de SPF. Todo CNAME de selector debe quedarse, por tanto, en «DNS only» — nube gris. El síntoma típico del olvido: el proveedor de correo indica «registro no encontrado» mientras el CNAME figura perfectamente visible en el panel.

Segunda sutileza: el CNAME flattening. En la raíz de la zona, Cloudflare aplana los CNAME de forma sistemática — el protocolo prohíbe un CNAME en la raíz, así que la plataforma lo resuelve por sí misma y sirve directamente el resultado. Una opción extiende ese aplanado a todos los CNAME de la zona. Aplicado a un selector DKIM, el flattening no rompe la validación: la resolución sigue siendo dinámica, se sirve el contenido final y la rotación de claves del proveedor se sigue con normalidad. Pero la cadena se vuelve invisible en los diagnósticos, lo que complica la depuración el día que algo falla. Salvo necesidad concreta, los selectores se leen mejor sin aplanar. La homonimia, por último, se presta a confusión: este flattening de CNAME no tiene nada que ver con el «SPF flattening», que consiste en sustituir los include: por direcciones IP para sortear el límite de diez consultas DNS — una técnica de último recurso, con inconvenientes bien documentados.

Los errores frecuentes

El registro colocado en el lugar equivocado. Un _dmarc sin su guion bajo, un SPF colocado en www en vez de la raíz, o — caso más sutil — una política esperada en un subdominio de envío dedicado pero colocada en la zona. Con DMARCbis, un subdominio sin registro propio hereda la política del dominio organizativo mediante el DNS Tree Walk; para dar a news.ejemplo.es una política propia, el registro va en _dmarc.news. En sentido inverso, un registro varado en un nombre caprichoso sencillamente no será leído nunca.

Los duplicados. Cloudflare acepta sin rechistar dos TXT v=spf1 en el mismo nombre — y ese duplicado invalida SPF (permerror) en todos los receptores. Misma sanción para dos registros en _dmarc: ante varias políticas, los servidores no aplican ninguna. Antes de cualquier creación, un repaso a la lista de registros existentes evita la colisión, sobre todo tras un cambio de proveedor de envío en el que el registro antiguo sigue rondando.

La zona duplicada. Dos variantes del mismo mal. Primero, el dominio añadido a Cloudflare sin que los servidores de nombres se hayan cambiado en el registrador: la zona de Cloudflare existe, se deja editar con esmero… y nadie la consulta — los cambios no surten efecto mientras la zona antigua sigue respondiendo. Segundo, la migración entrante: al importar un dominio, Cloudflare escanea la zona de origen para copiar sus registros, y ese escaneo pasa por alto con facilidad los TXT menos habituales — _dmarc, selectores bajo _domainkey. Un dominio migrado puede perder así su DKIM de la noche a la mañana sin que nada se haya «borrado» conscientemente. Tras cualquier migración, se impone una comparación línea a línea con la zona antigua.

Verificar, y después observar

La propagación es rápida en Cloudflare — TTL Auto de cinco minutos, red anycast — y la verificación puede seguir a la creación en cuestión de minutos. En línea de comandos:

dig TXT _dmarc.ejemplo.es +short
dig TXT ejemplo.es +short
dig TXT selector1._domainkey.ejemplo.es +short

La primera consulta debe devolver la política DMARC; la segunda, el registro SPF (entre otros TXT posibles); la tercera, la clave DKIM — también a través de un CNAME, que dig sigue silenciosamente. Una respuesta vacía en un selector que figura visible en el panel delata casi siempre una nube naranja olvidada.

La verificación DNS es, con todo, solo la mitad del camino. La prueba definitiva son los informes agregados que llegan a la dirección rua y confirman, fuente a fuente, que SPF y DKIM pasan y se alinean. Sobre esa base — datos, no suposiciones — la política podrá subir de p=none a p=quarantine y después a p=reject.

En resumen

Cloudflare aloja la zona, el correo vive en otra parte, y todo se coloca en la pestaña DNS: un TXT _dmarc en p=none con una dirección rua, un único TXT v=spf1 en la raíz, selectores DKIM en TXT o en CNAME según el proveedor. Los reflejos propios de la plataforma caben en cuatro puntos: nube gris obligatoria en los CNAME de selectores, TTL Auto sin tocar, flattening confinado a la raíz de la zona, y vigilancia sobre los duplicados y las zonas fantasma tras una migración. La herramienta DMARC integrada puede arrancar la recogida; la etiqueta rua con varias direcciones deja todas las puertas abiertas.

Para validar el resultado de una sola pasada — registro DMARC, SPF, selectores, alineación — un análisis DMARC gratuito del dominio dibuja el estado completo en segundos. Y cuando lleguen los primeros informes, crear una cuenta abre la siguiente etapa: inventario de fuentes, alertas ante los recién llegados y la subida progresiva hacia p=reject al ritmo que el ecosistema del dominio permita.