¿Qué es ARF? Formato de notificación de abusos e informes de fallos de DMARC (RFC 5965)

¿Qué es el ARF (formato de notificación de abusos)?

ARF son las siglas de «Abuse Reporting Format» (Formato de notificación de abusos). Se trata de un formato estandarizado y legible por máquina destinado a notificar a los remitentes que un correo electrónico ha causado un problema. Se definió en el RFC 5965 allá por 2010, en un momento en el que las notificaciones de abusos consistían principalmente en correos electrónicos de texto sin formato, en gran parte incoherentes, que los administradores de correo tenían que leer manualmente. Eso funcionaba bien cuando el volumen era bajo, pero dejó de ser viable en cuanto los proveedores quisieron automatizar cualquier proceso. El ARF proporcionó a los destinatarios, a los proveedores de servicios de Internet (ISP) y a los proveedores de buzones de correo una estructura común para que los incidentes de abuso pudieran notificarse a los propietarios de los dominios y a los remitentes en un formato que los scripts y los analizadores sintácticos pudieran gestionar fácilmente.

Hoy en día, el ARF está presente en cuatro lugares principales:

• Informes de error de DMARC: cuando un mensaje no supera la autenticación DMARC, el destinatario puede enviar un informe ARF en el que se describa exactamente cuál ha sido el problema.
• Bucles de retroalimentación de los proveedores de servicios de Internet (ISP): cuando un destinatario hace clic en «esto es spam», algunos proveedores transmiten esa queja al remitente en formato ARF.
• Denuncias al servicio de abuso: informes manuales sobre usos indebidos que se canalizan a través de sistemas automatizados de gestión de abusos.
• Denuncias de phishing y fraude: denuncias que señalan un mensaje como fraudulento, y no simplemente como no deseado.

Vale la pena aclararlo desde el principio: este ARF no tiene nada que ver con ninguna otra sigla en la que puedas estar pensando. En el mundo del correo electrónico, ARF siempre hace referencia al «Abuse Reporting Format» (formato de notificación de abusos).

Cómo se estructura un informe de la ARF (las tres partes)

La RFC 5965 define el ARF como un mensaje MIME «multipart/report», lo que simplemente significa que es un correo electrónico compuesto por tres partes distintas agrupadas. Cada parte está destinada a un destinatario diferente: una es para una persona, otra para una máquina y la tercera constituye la prueba.

Parte 1: Resumen legible para el ser humano (text/plain)

La primera parte es un bloque de texto sin formato destinado a quienes echan un vistazo rápido a su bandeja de entrada. Suele ofrecer un resumen de una o dos líneas de lo que ha ocurrido, de modo que quien eche un vistazo al informe no tenga que analizar los campos legibles por máquina solo para comprender lo esencial.

Parte 2: Informe legible por máquina (message/feedback-report)

Esta es la parte fundamental del informe y la que los sistemas automatizados analizan realmente. Se trata de un bloque de campos de tipo «clave-valor», como «Feedback-Type», «Version», «User-Agent», «Source-IP» y «Arrival-Date», junto con campos específicos de la autenticación, como «Auth-Failure». Aquí es donde reside realmente el valor diagnóstico del informe.

Parte 3: El mensaje original (message/rfc822 o text/rfc822-headers)

La parte final incluye o bien el mensaje original completo o solo sus encabezados, dependiendo de cómo lo haya configurado el remitente y del nivel de detalle que el destinatario esté dispuesto a compartir. Dado que el contenido del mensaje puede incluir información personal, muchos destinatarios lo reducen únicamente a los encabezados o ocultan partes del mismo antes de reenviar el informe.

Tipos de comentarios del ARF

El campo «Tipo de comentario» te indica qué tipo de informe estás consultando:

A efectos de DMARC, aquí solo verás un valor: «auth-failure». Se pueden registrar tipos de respuesta adicionales en la IANA si surge un nuevo caso de uso, pero el caso de uso de DMARC se ha mantenido con «auth-failure» desde el primer día.

ARF, AFRF, RUF, informes forenses: aclarando la terminología

Si has estado leyendo sobre los informes de DMARC y has empezado a ver que los términos ARF, AFRF, RUF y «informe forense» se utilizan casi indistintamente, no te lo estás imaginando. Estos términos se solapan realmente, y así es como se relacionan en realidad:

• ARF es el formato básico de cable definido en el RFC 5965. Es genérico y nunca ha sido específico de DMARC.
• AFRF (Authentication Failure Reporting Format) es la extensión definida en el RFC 6591 que adapta el ARF específicamente para notificar los fallos de autenticación de SPF, DKIM y DMARC.
• RUF es la etiqueta DMARC (ruf=) que se incluye en el registro DNS para solicitar que los informes de error de cada mensaje se envíen a algún lugar.
• «Informe forense » es la denominación anterior de este mismo elemento, heredada de la especificación original de DMARC, el RFC 7489. En el conjunto actual de RFC, se denomina en su lugar «informe de error».

Así pues, cuando alguien pide un «ejemplo de informe forense» y otra persona lo denomina «informe de fallo de DMARC», se refieren a lo mismo. La denominación ha cambiado con la norma, no el mecanismo subyacente.

ARF y DMARC: explicación de los informes de fallos

Al añadir una etiqueta «ruf=» a tu registro DNS de DMARC, estás solicitando a los servidores de correo receptores que te envíen un informe cada vez que un mensaje que afirme proceder de tu dominio no supere la verificación de DMARC. A diferencia de los informes agregados, que agrupan el tráfico de todo un día en un único resumen XML, los informes de fallo están pensados para generarse poco después de que se produzca el fallo y abarcan un solo mensaje.

Un informe de error de DMARC te proporciona datos que un informe agregado no puede ofrecer: los resultados de la autenticación de ese mensaje concreto, detalles sobre qué mecanismo falló exactamente, información sobre la fuente de envío y, o bien el mensaje completo, o bien sus encabezados, para que puedas rastrear su origen real. Ese nivel de detalle es lo que hace que los informes de error sean útiles para detectar un intento de suplantación de identidad casi en tiempo real, siempre que realmente recibas uno, lo que nos lleva a la siguiente sección.

Qué cambió con el RFC 9991 (Actualización de 2026)

En mayo de 2026, el IETF publicó un nuevo conjunto de documentos DMARC que sustituyen al RFC 7489 original: el RFC 9989 (DMARC básico), el RFC 9990 (informes agregados/RUA) y el RFC 9991 (informes de fallos/RUF). En conjunto, dejan obsoleto el RFC 7489. Esto es lo que ha cambiado realmente en los informes de fallos:

• Se ha producido un cambio en la línea de documentos RFC: el RFC 9991 abarca ahora la notificación de fallos y deja obsoletas las secciones sobre notificación de fallos del RFC 7489. Además, actualiza el RFC 6591 (AFRF) con un conjunto más preciso de campos obligatorios.
• El formato de cable ARF en sí no ha cambiado: el RFC 5965 sigue siendo el formato base subyacente.
• Un nuevo campo obligatorio: «Identity-Alignment»: una lista separada por comas en la que se indica qué mecanismo, DKIM o SPF, no ha podido generar un identificador alineado, o «none» si el identificador alineado sí se ha autenticado. Este es el campo más útil para cualquiera que lea un informe, ya que indica directamente si se trata de una configuración errónea o de una suplantación de identidad propiamente dicha,
• Un nuevo tipo de error de autenticación: dmarc: se utiliza específicamente cuando ningún identificador alineado ha autenticado el mensaje, a diferencia de un error genérico de SPF o DKIM.
• Nuevos campos obligatorios para diagnosticar errores de alineación: «DKIM-Domain», «DKIM-Identity» y «DKIM-Selector» son obligatorios cuando falla una firma DKIM alineada. «SPF-DNS» es obligatorio cuando falla una comprobación SPF alineada.
• Nuevos campos opcionales para proporcionar más detalles: «Delivery-Result» y el par «DKIM-Canonicalized-Header/Body», disponibles cuando un destinatario desee incluir más información de diagnóstico.

Por qué es tan importante la alineación de la identidad

En realidad, DMARC nunca comprobaba si SPF o DKIM superaban la verificación por separado, sino que comprueba si un identificador autenticado coincide con el dominio que figura en la dirección «De:» visible. Un mensaje puede superar técnicamente tanto la verificación de SPF como la de DKIM y, aun así, no superar la de DMARC si ninguno de los dos coincide con el dominio «De:». Este campo lo explica claramente.

RUA frente a RUF: Informes agregados frente a informes de fallos

Recomendación (igual que antes)

Configura siempre «rua=» en tu registro DMARC. Los principales proveedores de correo electrónico admiten ampliamente los informes agregados de DMARC y te proporcionan la visibilidad diaria que necesitas para supervisar la autenticación. La configuración de «ruf=» es opcional y puede ofrecer información de diagnóstico adicional, pero muchos receptores no envían informes forenses, por lo que debes considerarlos como una fuente de datos complementaria.

Cómo leer un informe ARF (ejemplo campo por campo)

A continuación se muestra un ejemplo de cómo podría ser un informe de error de DMARC en el caso de una suplantación de dominio directo, en la que un atacante envía un correo electrónico que aparenta proceder de tu dominio sin que haya ningún SPF ni DKIM válidos que lo respalden:

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

Paseando por los campos que más importan:

• El tipo de comentario «auth-failure» confirma que se trata de una queja relacionada con la autenticación, y no de una denuncia de spam o abuso.
• Error de autenticación: dmarc indica que el error se debe concretamente a un fallo de alineación DMARC, el tipo introducido por el RFC 9991.
• Alineación de identidad: «dkim, spf» es la línea de diagnóstico clave. Ninguno de los dos mecanismos ha podido generar un identificador alineado, lo que, junto con la ausencia de una firma DKIM válida y el fallo en la comprobación SPF, apunta claramente a una suplantación de identidad, más que a un error de configuración por tu parte.
• Los campos «Source-IP» y «Original-Mail-From» indican de dónde procede realmente el mensaje, lo cual resulta útil para incluirlo en listas de bloqueo o para realizar investigaciones más exhaustivas.
• «Reported-Domain» te permite saber cuál de tus dominios ha sido objeto de un ataque, lo cual resulta muy útil si gestionas varios.
• SPF-DNS muestra el registro SPF con el que el destinatario ha realizado la evaluación, lo que te ayuda a confirmar si tu propio registro se ha leído correctamente.

Si, por el contrario, se tratara de un remitente externo legítimo al que te hubieras olvidado de autorizar, lo normal sería que «Identity-Alignment» solo indicara un mecanismo, mientras que el otro mostraría un «aprobado», lo que te indicaría que se trata de un problema de configuración y no de un ataque.

Por qué es posible que no recibas informes de errores

Si has configurado «ruf=» y los informes nunca aparecen, o apenas llegan de forma esporádica, hay varias razones válidas:

1. La mayoría de los principales proveedores no los envían

Gmail y Yahoo, que se encuentran entre las principales fuentes de correo entrante para la mayoría de los dominios, no suelen generar informes de errores...

2. Privacidad y supresión de datos

Los informes de errores pueden revelar información personal procedente de los encabezados o del cuerpo de los mensajes, lo que expone al remitente a incumplimientos del RGPD y la CCPA. La norma RFC 6590 aborda la supresión de datos sensibles de los informes de abuso, y aplicar dicha supresión puede eliminar gran parte de la información que hacía que el informe fuera útil en primer lugar.

3. Es necesario verificar los destinos externos

Si tu dirección «ruf=» apunta a algún lugar fuera del dominio de tu propia organización, la RFC 9991 exige que el destinatario realice una comprobación de verificación de destino externo (el mismo mecanismo que define la RFC 9990 para los informes agregados) antes de enviar nada a esa dirección. Sin ese registro de autorización, los informes no llegarán.

4. Se prevé que se produzca una limitación de la velocidad

La RFC 9991 insta a los remitentes a limitar el número de informes de error que envían a un mismo destinatario, en parte para evitar saturar el buzón y en parte para prevenir los bucles de notificación.

5. Si no hay fallos, no hay informes

Si tu correo legítimo se autentica correctamente, no hay nada que pueda provocar un informe de error en primer lugar.

6. La configuración de tu etiqueta «fo»

La etiqueta «fo=» controla exactamente cuándo se genera un informe: «fo=0» (el valor por defecto) solo genera un informe cuando tanto SPF como DKIM fallan o no coinciden; «fo=1» genera un informe si falla cualquiera de los dos; «fo=d» genera un informe específicamente sobre el fallo de DKIM, y «fo=s» genera un informe específicamente sobre el fallo de SPF. La mayoría de los dominios que realmente desean obtener diagnósticos útiles establecen «fo=1».

Bucles de retroalimentación por correo electrónico y ARF

Los informes de errores no son el único lugar donde aparece el ARF. Los circuitos de retroalimentación de los proveedores de servicios de Internet (entre ellos,el «Complaint Feedback Loop» de Yahoo y los programas JMRP/SNDS de Microsoft ) utilizan exactamente el mismo formato ARF, solo que con el campo «Feedback-Type» establecido en «abuse» en lugar de «auth-failure».

Estos informes se activan cuando un destinatario marca un mensaje como spam, y constituyen una señal temprana útil de posibles problemas de entrega, aunque no estén relacionados en absoluto con DMARC.

Cómo configurar ARF / Notificación de fallos para tu dominio

Si quieres empezar a recopilar informes de errores para tu dominio:

1. Añade una etiqueta «ruf=» a tu registro DNS de DMARC que apunte a un buzón dedicado o a una dirección de notificación.

2. Establece fo=1 si deseas recibir informes tanto en caso de fallo de SPF como de DKIM, en lugar de solo cuando fallen ambos.

3. Si la dirección «ruf=» se encuentra fuera del dominio de tu organización, asegúrate de que el registro de autorización de destino externo esté configurado; de lo contrario, los destinatarios no enviarán nada a esa dirección.

4. Inscríbete por separado en los programas de bucle de retroalimentación de los principales proveedores de servicios de Internet, ya que estos funcionan al margen total de DMARC.

5. No pienses en leerlos manualmente en grandes cantidades. Incluso una pequeña cantidad de correo puede generar más informes ARF sin procesar de los que resulta práctico analizar manualmente. Aquí es donde un analizador automático de informes DMARC simplifica las cosas.

Resumen

Los informes de fallos son una aplicación específica de ARF dentro de DMARC. RUF te ofrece información detallada y exhaustiva por mensaje en el momento de su recepción, pero una parte significativa de los destinatarios no lo envía, lo que convierte a los informes agregados (RUA) en tu fuente fiable y cotidiana de visibilidad. Ahora que el estándar DMARC se ha formalizado en los documentos RFC 9989, RFC 9990 y RFC 9991, es más importante que nunca utilizar correctamente la terminología y los detalles, especialmente si estás resolviendo un incidente real de suplantación de identidad en lugar de un simple error de configuración.

Si es la primera vez que configuras los informes o quieres consultar estos datos sin tener que analizar tú mismo los mensajes ARF sin procesar, nuestro DMARC Report Analyzer está diseñado precisamente para eso. ¡Regístrate hoy mismo para obtener una prueba gratuita y consulta tus informes sin complicaciones!

Preguntas frecuentes

¿Qué es un informe de fallos de DMARC (forense)?

Se trata de un informe ARF por mensaje que se genera cuando un correo electrónico no supera la autenticación DMARC. Contiene detalles sobre el mensaje concreto, incluyendo qué mecanismos de autenticación fallaron y si generaron un identificador que coincidiera con el dominio del campo «De:». «Informe forense» es la denominación anterior para lo mismo, heredada del RFC 7489.

¿Cuál es la diferencia entre RUA y RUF en DMARC?

Los informes RUA (agregados) son resúmenes diarios en formato XML que recogen todo el correo recibido de un dominio, tal y como se define actualmente en el RFC 9990. Los informes RUF (de error) son informes ARF casi en tiempo real sobre mensajes concretos que no se han entregado, tal y como se define en el RFC 9991. El protocolo RUA cuenta con una amplia compatibilidad; el RUF es opcional y su envío no es sistemático.

¿Quién envía los informes de fallos de DMARC?

Solo algunos servidores de correo las generan, y los principales proveedores de correo electrónico, como Gmail y Yahoo, por lo general no lo hacen. La compatibilidad varía según el servidor de correo, y las preocupaciones en materia de privacidad, los requisitos de limitación de frecuencia y las normas de verificación de destino establecidas en la RFC 9991 reducen la frecuencia con la que llegan realmente.

¿Cuál es la diferencia entre ARF y XARF?

ARF (RFC 5965) es el formato estandarizado por la IETF que se utiliza en los informes de errores de DMARC y en los bucles de retroalimentación de los proveedores de servicios de Internet (ISP). XARF es una extensión propietaria, creada por un proveedor, que añade una carga útil en formato JSON para facilitar su análisis. No es un estándar de la IETF y los principales proveedores no la utilizan para la generación de informes DMARC.

¿Por qué no recibo ningún informe de error de DMARC?

Entre las posibles razones se incluyen el envío a proveedores importantes que no generan dichos informes, la supresión de datos por motivos de privacidad que reduce el contenido del informe, la falta de un registro de verificación del destino externo si tu dirección «ruf=» pertenece a un dominio distinto, la limitación de frecuencia obligatoria por parte del receptor o, simplemente, que no haya fallos de autenticación que notificar. La configuración de tu etiqueta «fo=» también determina exactamente cuándo se activa un informe.

• Acerca de
• Últimas publicaciones

Ahona Rudra

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.

Últimas publicaciones de Ahona Rudra (ver todas)

• ¿Qué es el ARF? Formato de notificación de abusos e informes de fallos de DMARC (RFC 5965) - 24 de julio de 2026
• La mayoría de las entidades financieras cuentan con DMARC. Casi ninguna está protegida. - 22 de julio de 2026
• ¿Qué es la «fatiga de MFA» (push bombing)? - 21 de julio de 2026