guía · dmarc en cloudflare
¿Cómo debe implementar un equipo de producto DMARC en Cloudflare de forma segura?
Configure DMARC en Cloudflare haciendo un inventario de todos los servicios que envían con sus dominios From visibles, verificando la alineación de SPF o DKIM en mensajes controlados y agregando una única política TXT en el nombre _dmarc exacto. Empiece con los informes, conserve el estado anterior del DNS, valide las respuestas autoritativas y recursivas, y revise los informes agregados antes de solicitar quarantine o reject. Cloudflare aloja o analiza la política DNS; no alinea a un remitente ni demuestra la entrega.
Separe el DNS de Cloudflare de la configuración del remitente
Cloudflare puede operar el DNS autoritativo mientras otro proveedor envía y firma el correo de la aplicación. Documente esos límites antes de editar nada. La zona publica la política TXT de DMARC; cada proveedor de correo controla su return path, el dominio de firma y el selector de DKIM, la verificación y, a veces, los informes; la aplicación controla el tenant, la clase de mensaje, el destinatario, la plantilla, la dirección From visible y la ruta del proveedor. Un registro DNS válido no puede reparar un remitente no autorizado, una firma DKIM ausente, un return path no alineado ni un valor From de otro tenant. Haga un inventario de los sistemas de producción, staging, soporte, facturación, identidad, monitoreo, CRM, marketing y correo de personas según el dominio From visible. Asigne a cada uno un responsable y un contacto para la reversión, y clasifique las fuentes desconocidas de los informes antes de aumentar el nivel de cumplimiento.
Consulte el nombre de política que evalúan los receptores
Para el correo de alerts@notify.example.test, empiece con el TXT en _dmarc.notify.example.test. No publique la política por error en el host del sitio web, en el servidor de correo (MX), en el selector de DKIM ni en el nombre del return path. El mecanismo actual de descubrimiento de DMARC puede seleccionar una política aplicable del dominio organizacional o del sufijo público cuando el dominio del autor no tiene un registro válido, así que anote tanto el nombre consultado como el dominio de política seleccionado. Consulte las respuestas autoritativas y recursivas existentes antes de abrir Cloudflare. Varios registros de política en el mismo nombre, una sintaxis de etiquetas mal formada o un CNAME en conflicto pueden hacer que el resultado sea inutilizable. Registre el contenido anterior, el TTL, la salida del resolvedor, el responsable y el valor esperado tras el cambio, para que la reversión sea exacta y no haya que reconstruirla durante un incidente.
Cree un único registro TXT revisado en Cloudflare
Abra la cuenta y la zona correctas de Cloudflare, vaya a DNS Records, elija Add record y seleccione TXT. Use _dmarc como nombre relativo para una política del dominio raíz (apex) o la etiqueta _dmarc exacta para el subdominio previsto. Introduzca un único valor revisado sin comillas incoherentes; Cloudflare documenta que agrega comillas de cierre al contenido TXT nuevo que se guarda sin ellas. Elija un TTL coherente con el despliegue y la recuperación, agregue una referencia del cambio que respete la privacidad si procede, y guarde solo después de comprobar la zona, el nombre, el valor anterior y el nuevo. Las políticas TXT son datos DNS, no rutas web con proxy. Si un socio de hosting u otro proveedor autoritativo gestiona la zona, haga el cambio allí en lugar de suponer que el panel de Cloudflare es el autoritativo.
Construya el valor de DMARC a partir de decisiones explícitas
Un registro en fase de observación puede empezar con v=DMARC1; p=none y una URI aprobada para informes agregados, pero eso es un ejemplo y no un valor universal. Mantenga la versión en primer lugar, haga que la política solicitada sea intencionada y autorice cada destino de informes. Revise la política de subdominios, el modo de alineación, el porcentaje y las etiquetas de informes solo cuando exista un requisito documentado y una interpretación vigente del estándar. No copie un ejemplo de un proveedor que contenga el buzón rua de otra persona ni salte a p=reject porque la sintaxis sea válida. Un registro válido expresa el tratamiento que se solicita al receptor; no demuestra que SPF o DKIM autentiquen, que alguno de los identificadores autenticados esté alineado con el dominio From, que se hayan inventariado todas las rutas de envío legítimas ni que algún mensaje haya llegado a una bandeja de entrada.
Verifique la alineación de SPF y DKIM en mensajes reales
Envíe ejemplos controlados desde cada ruta de la aplicación a destinatarios cuyos encabezados sin procesar pueda inspeccionar. Anote el From visible, el SMTP MAIL FROM, la IP de envío, el dominio d= y el selector de DKIM, Authentication-Results, el identificador del proveedor, la clase de mensaje, el entorno y la hora. DMARC puede dar pass mediante un SPF autenticado y alineado o mediante una firma DKIM verificada y alineada. SPF evalúa una identidad SMTP y puede cambiar con el reenvío; DKIM verifica una firma sobre un contenido seleccionado. Ninguno de los dos sustituye la autorización de la aplicación. Pruebe deliberadamente la alineación relajada o estricta, incluidos los subdominios y las rutas de conmutación por error. La aceptación por la API del proveedor, la aceptación por el servidor de destino, un resultado DMARC pass, la ubicación en el buzón y la interacción son observaciones distintas. Mantenga esos estados separados para que una llamada a la API correcta o un indicador de política en verde nunca se conviertan en una prueba de entrega más sólida de lo que son.
Valide el DNS y los informes fuera del panel
Después de guardar, consulte los servidores de nombres autoritativos de Cloudflare y varios resolvedores recursivos independientes para el TXT en el nombre _dmarc exacto. Guarde las respuestas sin procesar, el dominio de política seleccionado, el TTL, el resolvedor, la marca de tiempo y el resultado del analizador. Confirme que existe exactamente un registro utilizable, que v=DMARC1 va primero, que los valores obligatorios son válidos y que las URI de informes están aprobadas. Repita la comprobación cuando termine el periodo de caché previsto. Vuelva a enviar mensajes controlados e inspeccione los encabezados del receptor. Cloudflare documenta DMARC Management como una forma de ver las fuentes de envío y los resultados agregados de SPF, DKIM y DMARC, pero los informes son observaciones diferidas que aportan los receptores, no un censo completo en tiempo real. Correlaciónelos con la evidencia del proveedor. Deténgase ante desacuerdos entre resolvedores, tráfico poco frecuente que falte, fuentes legítimas desconocidas, mensajes controlados no alineados o cambios inesperados en el volumen de informes.
Trate Cloudflare DMARC Management como un cambio de DNS
Cloudflare indica que activar DMARC Management puede proponer la creación de un registro cuando no existe ninguno o agregar una dirección de informes agregados de Cloudflare a una etiqueta rua existente. Revise esa modificación propuesta como si fuera infraestructura de producción: exporte el valor anterior, confirme que los destinos existentes siguen siendo intencionados, verifique el alcance del dominio y conserve la opción de reversión. Su documentación de activación también describe el alcance actual limitado al dominio raíz y una salvedad sobre registros SPF externos. No deduzca que la función puede reescribir de forma segura una ruta SPF alojada en otro lugar. Que aparezca una fuente o una IP no demuestra qué aplicación, tenant o persona la autorizó, y la ausencia de una fila no demuestra que no haya tráfico. Use esta vista para recopilar evidencia, conservando a la vez la evidencia del DNS autoritativo, de los mensajes sin procesar, de los registros del proveedor y de la auditoría de la aplicación.
Aumente el nivel de cumplimiento con evidencia por etapas
Observe durante el tiempo suficiente para cubrir cada remitente legítimo, clase de mensaje, patrón semanal, tarea por lotes, ruta de conmutación por error y flujo de trabajo poco frecuente. Clasifique las fuentes como propias, proveedor aprobado, reenviadas, desconocidas o abusivas. Corrija la alineación del tráfico legítimo antes de solicitar un tratamiento más estricto. Un punto de decisión (go/no-go) debe incluir DNS válido, mensajes controlados con resultado pass, una cobertura alineada aceptable, ninguna fuente legítima desconocida, responsables de incidentes asignados, un equipo de soporte preparado y una reversión probada. Endurezca la política solo mediante un cambio acotado y aprobado, y monitoree tanto los fallos de autenticación como los fallos de negocio. Revierta o haga una pausa ante el rechazo de mensajes legítimos, la pérdida de informes, fuentes inesperadas, inconsistencias entre resolvedores, una migración de proveedor o sorpresas en la herencia de políticas de subdominios. Cuando sea posible, cambie SPF, DKIM y DMARC por separado para poder atribuir claramente cualquier regresión.
Evite los fallos habituales de DMARC en Cloudflare
Entre los fallos frecuentes están editar la zona equivocada, publicar en el nombre _dmarc incorrecto, dejar dos registros de política, agregar comillas mal formadas, reemplazar una lista rua aprobada, suponer que las políticas del dominio raíz y de los subdominios son idénticas y usar p=reject antes de que aparezcan los remitentes poco frecuentes. Otro error es tratar el estado guardado o detectado en el panel como una prueba a nivel de mensaje. Use diferencias exactas, destinatarios controlados, consultas independientes, encabezados sin procesar y registros de incidentes limitados al destinatario. Mantenga las direcciones de los clientes, el cuerpo de los mensajes, las claves de API y los datos de informes sin acotar fuera de los tickets y de las analíticas. Si las respuestas autoritativas y en caché siguen siendo incoherentes más allá de lo previsto en el plan, falta un remitente esperado o un mensaje real no supera la alineación, deténgase y diagnostique por separado la delegación, la caché, la sintaxis del registro, el inventario de remitentes, SPF y DKIM.
Cómo encaja SendHQ
El límite seguro es independiente del proveedor: la aplicación autoriza un mensaje, el proveedor de envío lo autentica, Cloudflare publica o analiza el estado de DNS y los receptores evalúan el mensaje. Confíe en la documentación oficial actual de Cloudflare, el estándar DMARC actual, las respuestas de DNS observadas y la evidencia controlada de mensajes recibidos.
Preguntas frecuentes
¿Qué nombre de Cloudflare contiene la política DMARC del dominio raíz?
Cree el TXT en _dmarc para la zona, que se resuelve como _dmarc.example.com. Para una identidad From de un subdominio, evalúe ese dominio del autor y las reglas de descubrimiento vigentes.
¿El valor TXT debe incluir comillas manuales?
Cloudflare indica que el contenido TXT nuevo que se guarda sin comillas se entrecomilla automáticamente. Evite comillas manuales incoherentes y luego verifique la respuesta autoritativa sin procesar y el resultado del analizador.
¿Cloudflare pasa por proxy un registro TXT de DMARC?
Para esta política TXT no interviene ninguna decisión de proxy HTTP. Publíquela en el DNS autoritativo y valídela externamente; el comportamiento del proxy web es una función diferente.
¿Puede DMARC Management cambiar el registro?
La documentación de activación de Cloudflare indica que puede ofrecer agregar un registro o un destino rua de Cloudflare. Revise, conserve, verifique y revierta ese cambio de forma explícita.
¿p=none rechaza el correo que falla?
No. Es una política solicitada orientada a la observación. Haga un inventario de los remitentes legítimos y corríjalos con ayuda de los informes y de mensajes controlados antes de plantearse una solicitud más estricta al receptor.
¿Que DMARC dé pass demuestra la llegada a la bandeja de entrada?
No. Demuestra que se aprobó la evaluación de autenticación alineada aplicable. La aceptación por el proveedor, la aceptación por el receptor, la carpeta de destino y la interacción requieren evidencia independiente y acotada.
¿Por qué SPF puede aprobarse mientras DMARC falla?
Es posible que la identidad SMTP autenticada no esté alineada con el dominio From visible, o que se aplique otro error de evaluación. Inspeccione las identidades exactas y los resultados sin procesar del receptor.
¿Un registro DMARC demuestra una integración con un proveedor de correo?
No. Un registro DMARC por sí solo no demuestra una integración con un proveedor de correo.
Fuentes
- Administrar registros DNS — Cloudflare
- Tipos de registros DNS de Cloudflare — Cloudflare
- Descripción general de Cloudflare DMARC Management — Cloudflare
- Activar Cloudflare DMARC Management — Cloudflare
- Revisar las estadísticas de DMARC de Cloudflare — Cloudflare
- RFC 9989: DMARC — RFC Editor
- RFC 7208: SPF — RFC Editor
- RFC 6376: DKIM — RFC Editor