¿Mover mi DNS a Cloudflare rompe el correo?

Tener el DNS en Cloudflare no rompe el correo por sí solo. Dos cosas sí. La primera es poner proxy en un hostname que lleva correo: Cloudflare documenta que los registros MX siempre son solo DNS y que el hostname al que apunta un MX tiene que resolver a un destino sin proxy, porque SMTP, IMAP y POP3 no pasan por un proxy HTTP. La segunda es Email Routing, que se adueña de los registros MX del dominio cuando lo activas. Revisa ambas antes de culpar al proveedor de correo.

¿Por qué mi plataforma de envíos dice que falta el registro DKIM si lo veo en Cloudflare?

Dos causas típicas. Si el registro es un CNAME que apunta al proveedor y está con proxy, Cloudflare lo aplana y devuelve direcciones de Cloudflare en lugar del destino, así que la consulta no encuentra la llave. Déjalo en solo DNS. Si es un TXT con una llave de 2048 bits, recuerda que una cadena TXT tiene un tope de 255 caracteres. Google documenta partir la llave en varias cadenas entre comillas dentro del mismo valor, o bajar a 1024 bits cuando el proveedor de DNS no puede guardar la forma larga.

SPF, DKIM y DMARC en Cloudflare: registros exactos

Q: ¿Puedo tener dos registros SPF en Cloudflare, uno por cada proveedor?

No. Cloudflare indica que tener más de un registro SPF en el dominio no está permitido y deja de funcionar, y el RFC 7208 es la razón: un servidor que encuentra dos registros que empiezan con v=spf1 obtiene un error permanente en lugar de una política. Fusiona todos los remitentes en un solo registro TXT y después cuenta las consultas DNS, porque el RFC 7208 permite un máximo de diez por evaluación y cada mecanismo include, a, mx y redirect gasta de ese presupuesto.

Imagina un estudio de arquitectura de doce personas que mueve su DNS a Cloudflare un viernes por la tarde porque alguien leyó que así el sitio carga más rápido. Y sí, carga más rápido. El lunes la administradora comenta que desde el fin de semana no ha llegado ningún correo de clientes, y que las tres facturas que salieron el viernes están en la carpeta de spam. Nadie tocó Google Workspace. Nadie tocó el flujo de correo. Lo que cambió es la zona que lee el resto de internet.

Cloudflare es un buen lugar para el DNS de una empresa pequeña, y movemos clientes ahí a propósito. También tiene dos comportamientos que son correctos para un sitio web y equivocados para el correo, y los dos fallan sin avisar. Esta es la configuración que aplicamos en una zona de Cloudflare: dónde van los registros, los tipos exactos y los dos ajustes que revisamos antes que nada.

Antes de agregar un registro: ¿esta zona manda de verdad?

Lo primero que revisamos en cualquier dominio de cliente es a dónde apuntan los nameservers. Una empresa que arrancó en 2018 suele tener tres paneles de DNS plausibles: el registrador, un hosting web y lo que sea que se agregó después. Los registros que escribes en un panel que ya no es autoritativo se ven perfectos en la interfaz y no hacen absolutamente nada. En una migración a Cloudflare esto pasa más de lo que parece, porque el editor de DNS del registrador sigue funcionando mucho después de que los nameservers cambiaron.

Confirma los nameservers y edita en un solo lugar.

Los tres registros y los tipos que Cloudflare espera

Los tres registros de autenticación son registros TXT. La documentación de DNS de Cloudflare lo dice de forma explícita, y explica por qué: el tipo de registro SPF quedó obsoleto en el RFC 7208, así que SPF va en un TXT, y tampoco existe un tipo de registro DKIM ni un tipo DMARC. Si los buscas en la lista de tipos no los vas a encontrar, y esa ausencia manda a bastante gente directo a un foro de soporte.

Para un dominio cuyo correo corre en Google Workspace, el conjunto se ve así. Google publica smtp.google.com como el valor MX único, y aclara que las cuentas creadas antes de 2023 pueden seguir con los hosts aspmx anteriores, que siguen soportados y no hay que cambiar si el correo funciona.

Tipo: MX    Nombre: @                  Valor: smtp.google.com                   Prioridad: 1
Tipo: TXT   Nombre: @                  Valor: v=spf1 include:_spf.google.com ~all
Tipo: TXT   Nombre: google._domainkey  Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...
Tipo: TXT   Nombre: _dmarc             Valor: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com

Dos detalles sobre ese bloque. Google recomienda eliminar los demás registros MX una vez que el valor nuevo está puesto, porque el correo puede no funcionar bien si sobreviven entradas viejas, y dar hasta 72 horas para que los MX nuevos se reconozcan. Y el valor de DKIM se genera en la consola de administración, no se copia de otro lado: el prefijo de selector por defecto es google y la cadena es única para tu dominio.

Ahí aparece un problema de tamaño muy concreto. Una cadena TXT tiene un tope de 255 caracteres, y Google documenta que una llave de 2048 bits no cabe en una sola cadena, así que puede truncarse o llegar en desorden. La instrucción de Google es partir la llave en varias cadenas, cada una entre comillas, una tras otra dentro del mismo valor del registro, y bajar a 1024 bits solo si tu proveedor de DNS no puede guardar la forma larga.

Trampa 1: un hostname con proxy que lleva correo

El proxy de Cloudflare es la nube naranja. Con proxy, quien consulta tu nombre resuelve a las direcciones anycast de Cloudflare y el tráfico pasa primero por ahí. Solo DNS, la nube gris, significa que Cloudflare responde con el valor que escribiste y no se mete.

Para correo, solo DNS es la única opción que funciona. Cloudflare documenta que los registros MX siempre son solo DNS y no se pueden poner detrás del proxy, y, la parte que la gente pasa por alto, que el hostname al que apunta un MX también tiene que resolver a un destino sin proxy. Si pones proxy en un nombre que maneja correo, los servidores que te escriben intentan conectarse a Cloudflare en vez de a tu servidor de correo, y SMTP, IMAP y POP3 no pasan por un proxy HTTP.

Un dominio en Google Workspace se salva a medias por suerte, porque su MX apunta a un host de Google fuera de la zona. La versión que sí alcanza a estos dominios es el CNAME. Cloudflare aplana los CNAME con proxy y devuelve direcciones de Cloudflare en lugar del destino, que es justo lo que quieres para un sitio web y justo lo contrario de lo que necesita un CNAME de DKIM de Mailchimp, HubSpot o Klaviyo, o un registro de verificación de dominio de un proveedor. El proveedor consulta el nombre, recibe una dirección en vez de lo que publicó, y reporta el registro como faltante. La guía de Cloudflare dice que los registros usados para enrutamiento de correo o para verificación de dominio de terceros deben quedar en solo DNS, y que los CNAME que comprueban propiedad del dominio no deben ir con proxy.

Entonces: recorre los registros A, AAAA y CNAME y deja en solo DNS todos los que tengan que ver con correo, proveedores de envío o verificación de dominio. Los TXT nunca pasan por el proxy, así que los valores de SPF, DKIM y DMARC no corren riesgo. Los nombres alrededor de ellos sí.

Trampa 2: Email Routing adueñándose de tus MX

Email Routing de Cloudflare reenvía el correo dirigido a tu dominio hacia un buzón en otro lado. Es útil de verdad para un dominio que no tiene servicio de correo propio. Es un problema cuando el dominio ya tiene uno, porque Cloudflare documenta que activar Email Routing implica que Cloudflare administra tus registros MX y puede crear más registros DNS de forma automática, y que esos MX pueden entrar en conflicto con los que tu proveedor de correo necesita.

La dirección contraria es peor, porque es silenciosa. Cloudflare documenta que desactivar Email Routing elimina todos los registros relacionados que agregó en la raíz del dominio, incluidos MX, SPF y DKIM. Un dominio que dependía del registro SPF que publicó Cloudflare se queda sin SPF en el momento en que alguien apaga la función durante una limpieza, y nada se rompe de forma visible hasta que ya pasó una semana de correo filtrado.

El orden que Cloudflare documenta para cambiar de proveedor es el que usamos: desbloquea los registros de enrutamiento, agrega al lado los del proveedor nuevo, verifica que el correo fluya y hasta entonces elimina los viejos. Dos preguntas cubren esto en una auditoría. ¿La zona tiene registros MX que nadie recuerda haber creado? ¿Está activo Email Routing en un dominio que ya tiene proveedor de buzones?

Un solo registro SPF y el presupuesto de diez consultas

La guía de solución de problemas de Cloudflare lo dice sin rodeos: tener más de un registro SPF en el dominio no está permitido y deja de funcionar. Entra a DNS y Registros, filtra los TXT cuyo valor empiece con v=spf1, y si hay dos, la solución es fusionarlos en uno, no elegir el favorito. Esto no es una rareza de Cloudflare. El RFC 7208 define el comportamiento, y un servidor que encuentra dos registros SPF tiene un error permanente en lugar de una política.

Fusionar es donde pega el segundo límite. El RFC 7208 permite un máximo de diez consultas DNS al evaluar un registro SPF, y cada mecanismo include:, a, mx y redirect gasta de ese presupuesto. Fusionar el proveedor de correo, el CRM, la herramienta de facturación y la plataforma de newsletters en un solo registro es exactamente como un dominio termina en doce consultas, y los receptores pueden tomar el resultado como error permanente y rechazar o marcar el correo. La sección de DMARC Management de Cloudflare revisa tu registro contra ese límite. El método completo para volver a bajar del límite está en SPF: demasiadas consultas DNS.

Verifica desde fuera del panel

Un registro que existe en el editor de Cloudflare no necesariamente llegó al mundo, y el panel no te puede decir si a Gmail le gusta el resultado. Revisa desde fuera: resuelve cada nombre, confirma que hay exactamente un registro SPF, confirma que el selector de DKIM devuelve una llave y no una dirección, confirma que el registro DMARC se interpreta bien, y después manda un mensaje real a un buzón que controles y lee las cabeceras.

Si las cabeceras muestran DKIM pasando pero DMARC fallando, el problema es de alineación y no de DNS, y la guía de fallos de DKIM explica cómo se ve eso en Workspace.

TTL y la parte que es simplemente DNS

Cloudflare te deja poner un TTL por registro, y la versión honesta de la propagación es que los resolvers se quedan con la respuesta que ya tienen durante el tiempo que el registro anterior les indicó. Bajar el TTL después de hacer el cambio no sirve de nada para las cachés que ya guardaron el valor viejo. Bájalo uno o dos días antes de un cambio de MX planificado, haz el cambio y después vuelve a subirlo. La nota de Google de que un cambio de MX puede tardar hasta 72 horas en reconocerse es el número que hay que citar cuando alguien pregunta por qué el correo todavía no se mueve.

DMARC y leer los reportes antes de apretar nada

Arranca el registro DMARC en p=none con una dirección rua. En p=none no se rechaza nada, y los reportes agregados te dicen qué remitentes están fallando, que es justo la información que necesitas antes de pasar a quarantine o reject. La documentación de Cloudflare indica que DMARC Management está en el panel bajo Email y DMARC Management, y que una vez que el DNS del dominio está en Cloudflare la función queda disponible sin configuración ni costo adicional, consultado el 14 de septiembre de 2026. Si prefieres pegar un reporte y leerlo ya, nuestro analizador DMARC hace eso, y cómo leer un reporte agregado decodifica el XML campo por campo.

Dale unas semanas de tráfico real. Pasar a enforcement antes de identificar a todos los remitentes legítimos es la forma en que las facturas y el correo del CRM terminan rechazados por tu propia política, y esa secuencia está en pasar DMARC de p=none a p=reject.

El orden en que trabajamos una zona de Cloudflare

Confirmar que los nameservers apuntan de verdad a Cloudflare.
Dejar en solo DNS todos los registros A, AAAA y CNAME relacionados con correo.
Revisar si Email Routing está activo y si se adueñó de registros MX que no le tocan.
Arreglar los MX y confirmar que el correo fluye antes de tocar autenticación.
Fusionar hasta dejar un solo registro SPF y contar las consultas.
Generar DKIM en la consola del proveedor y publicar la llave completa, partida en cadenas entre comillas si hace falta.
Publicar DMARC en p=none con una dirección de reportes.
Verificar desde fuera y leer reportes unas semanas antes de endurecer.

Cómo ayuda Guanacos Tech

Hacemos esto de principio a fin para empresas pequeñas y medianas en Norteamérica y Latinoamérica: auditar la zona, encontrar el registro con proxy o la función de enrutamiento que está haciendo el daño, publicar y verificar los tres registros, rastrear a los remitentes que nadie recordaba, y leer reportes DMARC antes de mover la política a enforcement. Si tu correo se puso raro después de mover el DNS y prefieres no adivinar, corre las revisiones de arriba o agenda una llamada y revisamos la zona contigo. El servicio completo está descrito en entregabilidad de correo.

SPF, DKIM y DMARC en Cloudflare: los registros exactos y los dos ajustes que rompen el correo sin avisar