Informes de fallos de DMARC (RUF): qué son, cómo funcionan y cómo activarlos de forma segura

Publicar un registro DMARC es un paso importante para proteger tu dominio contra la suplantación de identidad, el phishing y el uso no autorizado del correo electrónico. Sin embargo, el verdadero valor operativo reside en los informes que indican si los remitentes legítimos superan la autenticación del correo electrónico y dónde se producen los fallos.

Muchos equipos empresariales recurren a los informes agregados de DMARC para supervisar el estado general del dominio, pero es posible que esos resúmenes no ofrezcan suficiente detalle para la respuesta ante incidentes, las investigaciones de cumplimiento normativo o la resolución de problemas complejos relacionados con remitentes externos. Los informes de fallos de DMARC (RUF) aportan contexto a nivel de mensaje que puede ayudar a los equipos de seguridad y de TI a identificar más rápidamente el origen de los fallos de autenticación. 

En esta guía se explica qué son los informes RUF, en qué se diferencian de los datos agregados y cómo utilizarlos de forma eficaz.

¿Qué es un informe de error de DMARC?

Un informe de fallo de DMARC (también denominado «informe de fallo» o «informe RUF») es una notificación detallada y casi en tiempo real que envían los servidores de correo electrónico receptores cuando un mensaje no supera la autenticación DMARC. Proporciona información de diagnóstico a nivel de mensaje, incluidos los resultados de la autenticación, el origen del envío y los encabezados del mensaje, de modo que los propietarios de los dominios puedan investigar posibles intentos de suplantación de identidad y resolver problemas relacionados con la autenticación del correo electrónico.

Nota terminológica: Los términos «informe de fallo de DMARC», «informe de fallo de DMARC» e «informe RUF» se refieren todos al mismo tipo de informe. El formato subyacente es el AFRF (Authentication Failure Reporting Format), definido en el RFC 6591, que es una extensión específica de DMARC del ARF (Abuse Reporting Format, RFC 5965). Estos términos se utilizan a menudo de forma intercambiable en el sector.

• ¿Quién lo genera? Los servidores de correo de recepción, los proveedores de servicios de Internet (ISP), las pasarelas de correo corporativas y los dispositivos de seguridad, pero solo cuando son compatibles con RUF y detectan un fallo de autenticación. Los propietarios de los dominios solicitan informes mediante la etiqueta «ruf=», aunque son los destinatarios quienes deciden si enviarlos o no en función de sus propias políticas de privacidad y configuración.
• ¿A dónde va? Se envía a la dirección de correo electrónico especificada en la etiqueta «ruf=» de tu registro DNS de DMARC.
• ¿Qué formato utiliza? A diferencia de los informes agregados, que se entregan como archivos XML, los informes RUF utilizan el formato AFRF (Authentication Failure Reporting Format) para proporcionar datos detallados sobre los errores de autenticación en una estructura más legible para el usuario.

¿Qué información se incluye en los informes de fallos de DMARC?

Debido a RUF los informes DMARC están diseñados para un análisis en profundidad de los problemas, contienen metadatos específicos sobre el mensaje rechazado que no encontrarás en los informes agregados. Un informe típico de RUF incluye:

• Dirección IP del remitente: la dirección IP exacta desde la que se intentó enviar el mensaje
• Direcciones «From» y «Return-Path»: el campo «De» del encabezado y el remitente del sobre
• Asunto: el asunto real del correo electrónico que no se ha enviado
• Resultados de la autenticación: detalles específicos sobre por qué SPF o DKIM han fallado y si se ha logrado se ha logrado
• Encabezados del correo: los encabezados completos de respuesta del mensaje
• Hora de recepción: la marca de tiempo en la que el mensaje llegó al servidor receptor
• Política DMARC aplicada: la política que se aplicó al mensaje, ya sea «ninguna», «cuarentena» o «rechazo».
• Resultado de la entrega: si el mensaje se ha entregado, se ha puesto en cuarentena o se ha rechazado
• Información de identificación personal (PII): dado que estos informes pueden incluir asuntos y direcciones de destinatarios, a menudo contienen PII

Nota sobre la privacidad

Debido a la inclusión de datos de carácter personal (PII), muchos de los principales proveedores de correo electrónico han decidido no enviar informes RUF para proteger la privacidad de los usuarios. PowerDMARC resuelve este problema al admitir el cifrado PGP en los informes RUF, de modo que los datos confidenciales permanecen cifrados y solo tú puedes acceder a ellos. Algunos destinatarios que sí envían informes RUF ocultan primero las partes confidenciales del cuerpo del mensaje o del asunto, por lo que algunos informes de error llegan vacíos o contienen cadenas como [OCULTADO].

Ejemplo de informe de error de DMARC: cómo interpretar cada campo

Para comprender qué ocurre «entre bastidores», revisa los datos sin procesar. Cuando un correo electrónico falla, el destinatario genera un informe en formato AFRF. A continuación se muestra un que utiliza dominios reservados y rangos de IP según el RFC 5737.

Interpretación campo por campo

Consejo práctico

Al revisar un informe de RUF, responde a estas cuatro preguntas por orden. ¿Figura la dirección IP de origen en tu lista de remitentes autorizados? ¿Ha fallado el SPF, el DKIM o ambos? ¿Coincide el campo «Original-Mail-From» con tu dominio? ¿Parece tratarse de un caso de reenvío o de retransmisión desde una lista de correo? Si no puedes responder a estas preguntas con seguridad, remite el informe a tu equipo de seguridad para que lo investigue.

Cómo se ve el registro en tu DNS

Para recibir estos informes, tu registro DMARC debe incluir la etiqueta ruf=. Un ejemplo representativo:

Si envías informes a un dominio distinto al tuyo, el dominio de destino debe publicar un registro DNS que lo autorice a recibir informes en tu nombre. Desglose de las etiquetas:

• v=DMARC1: la etiqueta de versión estándar que identifica el protocolo DMARC
• p=none: modo de supervisión; los mensajes no se rechazan ni se ponen en cuarentena, y se solicita a los destinatarios que informen de los resultados de la autenticación
• rua=: la ruta de destino de los informes diarios agregados que resumen toda la actividad de autenticación
• ruf=: el destino de los informes de fallos; redirígelos a una plataforma de procesamiento segura y específica, en lugar de a una bandeja de entrada general
• fo=1: indica a los destinatarios que generen un informe si falla SPF o DKIM

Informe agregado de DMARC frente a informe de fallos: RUA frente a RUF

Ambos tipos de informes se configuran dentro del mismo registro DMARC, pero tienen finalidades distintas. El RUA ofrece una visión general del dominio a lo largo del tiempo; el RUF proporciona detalles a nivel de mensaje sobre fallos concretos. Para una distinción más detallada, consulta esta comparación de informes RUA frente a RUF.

Cómo activar los informes de errores de DMARC en tu registro DNS

Para habilitar RUF, es necesario actualizar tu registro TXT de DMARC actual en el DNS. Sigue estos pasos.

1. Accede a tu proveedor de DNS. Inicia sesión en la consola de gestión de DNS de tu dominio.
2. Busca tu registro TXT de DMARC. Busca el registro TXT publicado en _dmarc.tudominio.com.
3. Añade el destino RUF. Introduce una dirección ruf=mailto: a la que se deban enviar los informes de fallos compatibles.
4. Configurar las opciones en caso de fallo. Añade la etiqueta «fo=» para definir cuándo deben generarse los informes, tal y como se explica en la siguiente sección.
5. Utiliza un procesamiento seguro. Envía los informes a una plataforma segura, como PowerDMARC, en lugar de a una bandeja de entrada general.
6. Guarda los cambios y espera a que se propaguen. Los cambios en el DNS pueden tardar hasta 48 horas en propagarse a nivel mundial.

El envío de informes RUF a una bandeja de entrada estándar genera ruido y aumenta el riesgo de exposición de los datos. Una plataforma de generación de informes centraliza los datos de DMARC, transforma los datos de autenticación sin procesar en paneles de control fáciles de interpretar y correlaciona los fallos con los resultados de la alineación de SPF, DKIM y DMARC, de modo que los equipos puedan identificar los problemas más rápidamente.

Explicación de DMARC para «Tag»: cuándo se activan los informes de fallo

La etiqueta «fo» es un componente del registro DMARC que indica al servidor receptor cuándo debe generar un informe de error.

La mayoría de los profesionales de la seguridad utilizan fo=1 porque ofrece la máxima visibilidad de los fallos de autenticación. Dicho esto, fo=1 debería redirigirse a una plataforma de procesamiento segura y dedicada, en lugar de a una bandeja de entrada de un usuario. El volumen de informes que genera puede llegar a ser inmanejable sin automatización, y enviarlos a una bandeja de entrada desprotegida aumenta la exposición de los datos confidenciales de los mensajes. A fallo de DKIM , en particular, puede generar una avalancha de informes que conviene aislar de un buzón compartido.

Por qué es posible que no estés recibiendo informes de fallos de DMARC

Si has activado RUF pero el destino de los informes está vacío, esto no tiene por qué indicar un error de configuración. Hay varios factores habituales que pueden provocar que no se reciban informes.

Por eso, según informes RUA se consideran la fuente de referencia para la supervisión general del estado del dominio, mientras que los informes RUF sirven como herramienta de investigación complementaria para casos concretos de fallo.

Cuestiones relacionadas con la privacidad y la seguridad

Dado que los informes de RUF pueden contener asuntos, direcciones de destinatarios, encabezados y, en ocasiones, el contenido de los mensajes, deben gestionarse con cuidado en el marco de normativas de privacidad como el RGPD y la CCPA. En el caso de las organizaciones de sectores regulados, como el financiero, el sanitario, el educativo, el minorista y el público, los datos de fallos deben procesarse a través de sistemas seguros y con acceso controlado que garanticen el cumplimiento de las obligaciones en materia de privacidad y normativa.

Para las organizaciones que deben cumplir los requisitos de autenticación de correo electrónico de Google, Microsoft, PCI DSS, el RGPD o las autoridades públicas, es fundamental contar con flujos de trabajo seguros para la generación de informes. Los datos de RUF pueden servir de apoyo en las investigaciones, pero la visibilidad global de DMARC, el progreso en la aplicación de las normas y la gestión de los remitentes autenticados siguen siendo esenciales para garantizar el cumplimiento normativo a largo plazo.

Buenas prácticas

• Utiliza una plataforma de notificación específica y segura.
• Habilitar el cifrado PGP: un modelo de «trae tu propia clave» implica que solo los usuarios autorizados que dispongan de la clave privada pueden ver el contenido confidencial de los informes de fallos.
• Limita el acceso a los datos sobre fallos en función del rol y las necesidades operativas.
• Definir políticas de conservación de datos para los datos RUF almacenados, de conformidad con la normativa de protección de datos aplicable.
• Realice una revisión jurídica antes de habilitar RUF en jurisdicciones con requisitos estrictos en materia de protección de datos.

Cómo utilizar los informes RUF para detectar suplantaciones de identidad y solucionar fallos

Una vez que empieces a recibir datos de errores, considera cada informe como una señal que requiere investigación, en lugar de un veredicto definitivo. Contrasta los resultados con los listados de remitentes autorizados, las tendencias agregadas de DMARC, los registros de la pasarela de correo y la información sobre amenazas antes de tomar decisiones sobre las medidas correctivas. Hay cinco escenarios que abarcan la mayor parte de lo que revelan los datos de errores.

Detección de la suplantación de dominios

Si un informe de fallos identifica una dirección IP de origen no reconocida que utiliza su dominio en la dirección «De» del encabezado, considérelo una señal que requiere investigación. En primer lugar, compruebe la dirección de origen cotejándola con los listados de remitentes autorizados, las tendencias agregadas, los registros de la pasarela y la información sobre amenazas. Si se confirma que no está autorizada, la dirección IP puede añadirse a las listas de bloqueo y puede notificarse a su centro de operaciones de seguridad.

Solucionar fallos legítimos

A veces, los correos electrónicos legítimos no se envían correctamente porque un remitente externo no está configurado adecuadamente, un selector DKIM está mal configurado o el registro SPF del dominio se ha vuelto demasiado complejo. Una plataforma de generación de informes ayuda a los equipos a identificar estos fallos en su contexto y a simplificar la gestión del SPF mediante el SPF alojado y la simplificación automatizada, lo que reduce el riesgo de problemas de entrega a medida que se añaden nuevas herramientas SaaS.

Diagnóstico de fallos relacionados con el reenvío

El reenvío de correo electrónico suele provocar fallos en el SPF, ya que la dirección IP del servidor de reenvío no figura en el registro SPF del remitente original. Si un informe RUF muestra fallos procedentes de un servicio de reenvío reconocido o de un relé de lista de correo, es probable que la causa sea un fallo en el SPF y no un intento de suplantación de identidad. En estos casos, comprueba si DKIM sigue superando la validación, ya que las firmas DKIM suelen mantenerse intactas tras el reenvío, y si la política DMARC puede cumplirse únicamente mediante la alineación de DKIM.

Detección de la «TI en la sombra» y de remitentes no autorizados

Los informes de RUF pueden revelar fuentes de envío que los equipos de TI no han autorizado o de las que no tienen constancia, como por ejemplo un equipo de marketing que haya conectado una nueva herramienta de automatización sin actualizar el registro SPF. Si un informe de fallos muestra un fallo procedente de una dirección IP perteneciente a una plataforma SaaS adoptada recientemente, se trata de una deficiencia de configuración y no de un ataque. Añade el servicio a tu lista de remitentes autorizados y actualiza tu registro DMARC en consecuencia.

Flujo de trabajo de la investigación

1. Identifica la dirección IP de origen en el informe RUF.
2. Comprueba la autorización: ¿está esta dirección IP asociada a alguna herramienta o servicio que utilice tu organización?
3. Comprueba la alineación: revisa los resultados de SPF y DKIM en el campo «Authentication-Results».
4. Comprueba si se trata de un reenvío o de una lista de correo: evalúa si el error de SPF se debe a un servidor de retransmisión intermedio.
5. Clasificar el riesgo: remitente autorizado con una configuración incorrecta, remitente no autorizado, mensaje reenviado o fuente de «TI en la sombra».
6. Solución: si está autorizado pero falla, corrige la configuración de SPF o DKIM. Si no está autorizado, utiliza tu política DMARC con p=quarantine o p=reject para aplicar la protección.
7. Realizar un seguimiento mediante informes agregados: comprueba que las medidas correctivas son eficaces revisando los informes RUA posteriores.

Cuándo conviene activar RUF y cuándo es mejor no hacerlo

RUF no es una configuración predeterminada para todos los dominios. Que resulte útil o no depende de quién vaya a leer los informes y para qué sirvan. Hay tres situaciones en las que resulta útil y dos en las que no lo es.

• Actívalo cuando cuentes con un equipo de seguridad que pueda actuar en función de los datos. Los analistas del SOC y el personal de respuesta a incidentes utilizan los detalles a nivel de mensaje para investigar los casos confirmados de suplantación de identidad, lo cual constituye el principal uso de este informe.
• Actívalo durante la resolución activa de problemas. Cuando un remitente externo sigue fallando y los datos agregados no son lo suficientemente específicos, los detalles del fallo sobre la IP exacta y el resultado de la alineación agilizan el diagnóstico.
• Actívalo en entornos regulados que ya cuenten con un procesamiento seguro. Si ya utilizas un sistema de generación de informes cifrado y con control de acceso, la mayor profundidad de la investigación conlleva un riesgo marginal mínimo.
• Reconsidéralo si los informes se enviaran a una bandeja de entrada compartida. Sin cifrado ni controles de acceso, recibir informes que contengan datos de carácter personal supone un riesgo de incumplimiento normativo que supera los beneficios.
• Reconsidéralo si nadie se hace responsable del resultado. Un volumen elevado de fo=1 sin ningún analista que lo clasifique se convierte en ruido, y los informes agregados ya cubren la supervisión del estado del dominio.

Por defecto, la mayoría de los equipos optan por dar prioridad al análisis agregado. Se ejecuta RUA para evaluar el estado del dominio y el progreso en la aplicación de las normas; a continuación, se activa RUF de forma deliberada cuando una investigación o un fallo persistente de un remitente requiere un análisis en profundidad a nivel de mensaje, que se deriva a una plataforma diseñada para gestionar la información sensible.

Limitaciones de los informes de fallos de DMARC

Entender lo que los informes RUF no pueden hacer es tan importante como saber lo que sí pueden. Considera los informes de fallos como una herramienta de investigación complementaria, en lugar de como la señal principal para tomar decisiones sobre el programa DMARC.

• Asistencia limitada por parte de los proveedores: los principales proveedores de correo electrónico, como Gmail y Microsoft 365, no suelen enviar informes RUF por motivos de privacidad, por lo que la cobertura de los fallos es, por naturaleza, incompleta
• Datos ocultados: los destinatarios que sí envían informes pueden ocultar el asunto, el cuerpo del mensaje o las direcciones de los destinatarios antes de la entrega
• Falsos positivos debidos al reenvío: los servidores de retransmisión de listas de correo y los servicios de reenvío suelen provocar errores de SPF que parecen fallos de autenticación, pero que no son intentos de suplantación de identidad
• Volumen de informes y ruido: con fo=1, los remitentes que envían gran volumen de mensajes pueden recibir un número inmanejable de informes, muchos de los cuales reflejan un comportamiento de reenvío esperado en lugar de amenazas reales
• No sustituye a RUA: los informes agregados siguen siendo la fuente de referencia para evaluar el estado de la autenticación en todo el dominio, por lo que el RUF debería complementar, en lugar de sustituir, la supervisión continua de la RUA.
• Riesgo de exposición de datos personales: sin cifrado ni controles de acceso, el mero hecho de recibir informes RUF puede, por sí mismo, generar obligaciones de cumplimiento en virtud del RGPD, la CCPA y marcos normativos similares

Cómo pueden los MSP utilizar los informes de fallos de DMARC en los dominios de sus clientes

Para los MSP y los MSSP, los informes de fallos resultan muy útiles cuando un cliente notifica la pérdida de mensajes, sospechas de suplantación de identidad o fallos de autenticación inexplicables. Sin embargo, los informes RUF sin procesar son difíciles de gestionar a gran escala. Pueden contener datos confidenciales de los clientes, proceder de varios dominios a la vez y requerir una correlación con otras señales de autenticación para que resulten útiles.

• Visibilidad multidominio: agregar informes de decenas o cientos de dominios de clientes sin una plataforma centralizada requiere un esfuerzo manual considerable
• Tratamiento de datos sensibles: Los informes RUF procedentes de los dominios de los clientes pueden contener información de identificación personal (PII) de los clientes finales, lo que genera obligaciones de cumplimiento normativo para el MSP.
• Gestión del volumen de informes: los dominios de clientes con un gran volumen pueden generar un gran número de informes de fallos que saturan los flujos de trabajo de los técnicos
• Acceso basado en roles: los técnicos solo deben ver los informes correspondientes a los dominios de los clientes que se les hayan asignado

Una plataforma centralizada como PowerDMARC para MSP y MSSP ayuda a los proveedores de servicios a procesar los datos de RUF de forma segura, a separar los dominios de los clientes, a reducir el tiempo dedicado a las investigaciones manuales y a ofrecer a los técnicos una visión rápida de qué remitente, dirección IP o mecanismo de autenticación ha provocado un fallo, sin exponer datos confidenciales de forma innecesaria.

Cómo ayuda PowerDMARC con los informes de errores de DMARC

PowerDMARC procesa de forma segura los datos de errores de DMARC y convierte los errores de autenticación sin procesar en información útil. En lugar de enviar informes RUF confidenciales a una bandeja de entrada estándar, los equipos consultan los informes en un panel de control centralizado, protegen los datos confidenciales mediante cifrado PGP y correlacionan los errores con los resultados de la alineación de SPF, DKIM y DMARC.

• Visibilidad clara: identifica más rápidamente las fuentes de envío fallidas, los resultados de autenticación y las direcciones IP sospechosas en todos tus dominios
• Gestión segura: El cifrado PGP con un modelo de «trae tu propia clave» reduce la exposición de los datos confidenciales sobre fallos, de modo que ni siquiera PowerDMARC puede leer el contenido cifrado.
• Gestión centralizada: supervisa DMARC, SPF, DKIM, BIMI, MTA-STS y TLS-RPT desde una única plataforma sin necesidad de cambiar de herramienta ni analizar código XML sin procesar
• Solución más rápida: resuelve los fallos de remitentes legítimos y los intentos de suplantación de identidad sin necesidad de analizar manualmente los informes AFRF, gracias al SPF alojado y al «flattening» automatizado, lo que reduce los fallos de entrega a medida que se añaden nuevas herramientas SaaS.
• Preparación para el cumplimiento normativo: registros de auditoría, controles de acceso basados en roles y compatibilidad con los requisitos de Google, Microsoft, PCI DSS, el RGPD y los requisitos gubernamentales para los remitentes

Preguntas frecuentes

¿Qué es exactamente un informe de error de DMARC?

Un informe de errores casi en tiempo real que se genera cuando un correo electrónico concreto no supera las comprobaciones de autenticación definidas en tu política DMARC y tus opciones de gestión de errores. Incluye detalles a nivel de mensaje, a diferencia de los informes agregados, que resumen la actividad de todos los mensajes a lo largo de 24 horas.

¿En qué se diferencia el RUF del RUA?

RUA ofrece un resumen diario en formato XML que abarca todo el dominio y todos los mensajes. RUF proporciona información casi en tiempo real sobre mensajes concretos con errores en formato AFRF (RFC 6591, que amplía el formato ARF de la RFC 5965), contiene detalles específicos de cada mensaje y puede incluir información de carácter personal (PII). RUA no lo hace.

¿Cómo activo estos informes?

Añade ruf=mailto:[email protected] a tu registro TXT de DMARC en _dmarc.tudominio.com. Incluye «fo=1» para recibir un informe cuando falle SPF o DKIM. Envía los informes a una plataforma segura en lugar de a una bandeja de entrada estándar.

He configurado RUF, pero no me sale nada. ¿Está estropeado?

No necesariamente. Muchos proveedores no envían RUF por motivos de privacidad, y no se genera ningún informe cuando se transmiten los mensajes. Si se reciben informes RUA agregados, es probable que tu registro sea correcto. Consulta la tabla de resolución de problemas para ver otras posibles causas.

¿Todos los proveedores de correo electrónico envían informes de errores de DMARC?

No. Por lo general, ni Gmail ni Microsoft 365 lo hacen, alegando motivos de privacidad de los usuarios. La cobertura se limita a los destinatarios que han implementado la compatibilidad con RUF, normalmente algunas pasarelas de correo corporativas, proveedores de servicios de Internet (ISP) y servidores de correo independientes. Se trata de una limitación clave.

¿Es seguro recibir informes de errores de DMARC?

Pueden contener datos de carácter personal, como el asunto de los mensajes, las direcciones de los destinatarios y los encabezados. Recibirlos sin los controles adecuados puede dar lugar a obligaciones en virtud del RGPD y la CCPA. Lo más seguro es redirigirlos a una plataforma segura que cuente con cifrado PGP, acceso basado en roles y un plazo de conservación definido.

¿Para qué sirve la etiqueta «fo»?

Son las siglas de «Failure Options» (Opciones de fallo) y definen cuándo los receptores generan un informe. fo=0 (valor predeterminado) requiere que fallen tanto SPF como DKIM. fo=1 envía el informe ante cualquiera de los dos fallos. fo=d se activa solo ante un fallo de DKIM; fo=s, solo ante un fallo de SPF.

• Acerca de
• Últimas publicaciones

Milena Baghdasaryan

Especialista en contenidos en PowerDMARC

Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.

Últimos mensajes de Milena Baghdasaryan (ver todos)

• «Responder» frente a «Responder a todos»: normas de etiqueta y riesgos de seguridad - 14 de agosto de 2026
• Informes de fallos de DMARC (RUF): qué son, cómo funcionan y cómo activarlos de forma segura - 11 de agosto de 2026
• Autenticación de correo electrónico en las mayores empresas de IA del mundo - 10 de agosto de 2026