← RFC Reference

RFC 6591: Informe de Fallos de Autenticación (AFRF)

Por qué existe

Los mecanismos de autenticación de correo electrónico como SPF, DKIM y DMARC detectan mensajes falsificados o no autorizados. Cuando estas verificaciones fallan, el servidor receptor toma medidas (rechazar, poner en cuarentena o permitir). Pero el propietario del dominio — el que está siendo falsificado — necesita saber sobre estos fallos para:

• Detectar el uso no autorizado de su dominio (phishing, falsificación)
• Identificar remitentes legítimos mal configurados (p. ej., una plataforma de marketing que no firma con DKIM)
• Depurar problemas de registros de autenticación (SPF incluye rotos, clave DKIM incorrecta)
• Crear una imagen de patrones de ataque antes de cambiar DMARC a p=reject

Los informes agregados de DMARC (rua) proporcionan resúmenes estadísticos, pero no incluyen detalles de mensajes. Los informes forenses de DMARC (ruf) utilizan el formato AFRF definido por esta RFC para proporcionar detalle por mensaje: los encabezados reales, los resultados de autenticación y la razón de fallo específica.

RFC 6591 extiende RFC 5965 (ARF) al agregar el tipo de informe Feedback-Type: auth-failure y definir campos adicionales para datos específicos de autenticación.

Cómo funciona

Un informe AFRF es un mensaje ARF (multipart/report con report-type=feedback-report) donde la parte legible por máquina utiliza Feedback-Type: auth-failure e incluye campos específicos de autenticación.

Ejemplo de informe AFRF

From: dmarc-reporter@receiver.example.com
To: dmarc-ruf@example.com
Subject: Auth failure report for example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="AFRF-BOUNDARY-001"

--AFRF-BOUNDARY-001
Content-Type: text/plain

Authentication failure report for a message claiming
to be from example.com, received from IP 192.0.2.55.

--AFRF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-DMARC/2.0
Version: 1
Original-Mail-From: spoofed@example.com
Arrival-Date: Tue, 10 Mar 2026 16:42:00 -0500
Source-IP: 192.0.2.55
Auth-Failure: dmarc
Authentication-Results: receiver.example.com;
    dkim=fail header.d=example.com;
    spf=fail smtp.mailfrom=spoofed@example.com;
    dmarc=fail header.from=example.com
Reported-Domain: example.com
DKIM-Domain: example.com
Delivery-Result: reject

--AFRF-BOUNDARY-001
Content-Type: text/rfc822-headers

From: ceo@example.com
To: finance@receiver.example.com
Subject: Urgent wire transfer needed
Message-ID: <fake-msg-001@192.0.2.55>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
    s=selector1; b=INVALID...

--AFRF-BOUNDARY-001--

Detalles técnicos clave

Campos agregados por RFC 6591

Estos campos aparecen en la parte message/feedback-report junto con los campos ARF estándar:

Valores de Auth-Failure

Relación con la informática de DMARC

DMARC (RFC 7489) define dos direcciones de informe en su registro DNS:

• rua — informes agregados (XML). Resúmenes estadísticos de resultados de autenticación en todos los mensajes.
• ruf — informes forenses. Detalle por mensaje utilizando el formato AFRF definido por esta RFC.

En la práctica, la informática forense a través de ruf tiene una adopción limitada. Muchos proveedores grandes de buzones (Gmail, Yahoo) no envían informes forenses debido a preocupaciones de privacidad. Los que lo hacen a menudo redactan el cuerpo del mensaje y la dirección del destinatario. Los informes agregados (rua) siguen siendo la fuente principal de retroalimentación de DMARC.

Errores comunes

• Esperar informes forenses de todos los receptores. La mayoría de los proveedores grandes de buzones no envían informes AFRF. No confíe en ruf como su única fuente de datos de fallo de autenticación. Los informes agregados de DMARC (rua) son mucho más ampliamente compatibles.
• Confundir AFRF con informes de abuso de ARF. Ambos utilizan multipart/report con report-type=feedback-report, pero tienen valores de Feedback-Type diferentes. Un informe auth-failure significa que una verificación de autenticación falló; un informe abuse significa que un usuario hizo clic en "Reportar spam". Manejelos de manera diferente.
• Ignorar el campo Auth-Failure. El campo Auth-Failure le dice exactamente qué verificación falló. Un fallo de dkim sugiere un problema de firma; un fallo de spf sugiere una IP faltante en su registro SPF; un fallo de dmarc significa que ninguno de los dos mecanismos se alineó.
• No publicar una dirección ruf. Aunque la mayoría de los receptores no la usarán, algunos proveedores más pequeños y puertas de enlace empresariales sí envían informes forenses. Incluir ruf en su registro DMARC no cuesta nada y puede proporcionar datos útiles.
• Tratar los informes forenses como devoluciones. Un informe de fallo de autenticación no significa que el mensaje no haya sido entregado. Verifique el campo Delivery-Result — el mensaje puede haber sido entregado a la carpeta de spam a pesar del fallo.

Impacto en la entregabilidad

• Detección temprana de campañas de suplantación. Cuando alguien está haciendo phishing con su dominio, los informes AFRF (donde están disponibles) proporcionan los encabezados específicos y las IPs de origen de los mensajes falsificados, permitiendo una respuesta a incidentes más rápida.
• Depuración de errores de configuración de autenticación. Un informe forense que muestra Auth-Failure: dkim con un selector y dominio específico le dice exactamente qué clave DKIM o configuración de firma está rota.
• Implementación segura de DMARC. Al pasar de p=none a p=quarantine o p=reject, los informes forenses lo ayudan a identificar remitentes legítimos que están fallando en la autenticación antes de que esos mensajes comiencen a ser bloqueados.
• Complementando datos agregados. Los informes agregados de DMARC le muestran que 50 mensajes fallaron en la autenticación desde la IP 192.0.2.55. Un informe forense le muestra los encabezados reales de uno de esos mensajes, revelando si fue un phish o un sistema legítimo mal configurado.

Related RFCs