← RFC Reference

RFC 6652: Informe de Fallos de Autenticación SPF

Por qué existe esto

SPF (RFC 7208) valida que una IP de envío esté autorizada para el dominio del remitente de sobre. Cuando SPF falla, podría significar:

• Un falsificador está suplantando tu dominio
• Un remitente legítimo de terceros (plataforma de marketing, CRM) falta en tu registro SPF
• Un servidor de reenvío está retransmitiendo tu correo (rompiendo la alineación SPF)
• Tu registro SPF tiene un error de sintaxis o excede el límite de 10 búsquedas

Sin informes de fallos, estás ciego a estos eventos. Los informes agregados de DMARC (RFC 7489) te ofrecen resúmenes diarios, pero RFC 6652 proporciona informes forenses por mensaje específicamente para fallos de SPF. Estos informes utilizan el formato ARF (RFC 5965) con el tipo de retroalimentación auth-failure extendido por RFC 6591.

Cómo funciona

El propietario del dominio publica un registro DNS TXT especial en _spf._report.<domain> que le indica a los receptores dónde enviar los informes de fallo de SPF.

Registro DNS

; Solicitar que los informes de fallo de SPF se envíen a esta dirección
_spf._report.example.com.  IN TXT  "v=spf-report1; ra=spf-reports; rp=100; rr=all"

Campos del registro

Ejemplo de informe de fallo (formato ARF)

From: arf-generator@receiver.example
To: spf-reports@example.com
Subject: SPF failure report for example.com
Content-Type: multipart/report; report-type=feedback-report;
    boundary="SPF-REPORT-001"

--SPF-REPORT-001
Content-Type: text/plain

SPF authentication failure report for a message
claiming to be from example.com.

--SPF-REPORT-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-MTA/2.0
Version: 1
Auth-Failure: spf
Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=example.com
Original-Mail-From: user@example.com
Source-IP: 198.51.100.50
Reported-Domain: example.com
Delivery-Result: reject

--SPF-REPORT-001
Content-Type: text/rfc822-headers

From: user@example.com
To: recipient@receiver.example
Subject: Important update
Message-ID: <msg-001@example.com>

--SPF-REPORT-001--

Detalles técnicos clave

Valores del campo Auth-Failure para SPF

El campo Auth-Failure distingue los informes de SPF de los informes de fallo de DKIM o DMARC que también utilizan el tipo de retroalimentación auth-failure (definido en RFC 6591).

Relación con los informes de DMARC

DMARC (RFC 7489) tiene su propio mecanismo de informe con dos tipos:

• Informes agregados (rua) — resúmenes XML diarios de resultados de autenticación, enviados a la dirección en el registro DMARC.
• Informes forenses (ruf) — informes de fallo por mensaje. Los informes forenses de DMARC cubren fallos de alineación tanto de SPF como de DKIM.

Los informes de RFC 6652 son específicos de SPF e independientes de DMARC. En la práctica, la mayoría de los receptores generan informes agregados de DMARC (ampliamente compatibles) pero pocos generan informes de RFC 6652 o forenses de DMARC debido a preocupaciones de privacidad. Sin embargo, donde se admitan, los informes de RFC 6652 proporcionan los datos más detallados por fallo específicamente para SPF.

Consideraciones de privacidad

Los informes de fallo pueden contener direcciones de destinatarios y encabezados de mensajes, lo que genera preocupaciones de privacidad. Muchos receptores limitan lo que incluyen o no generan estos informes en absoluto. La etiqueta rp permite al propietario del dominio solicitar un porcentaje inferior a 100 para reducir el volumen de informes.

Errores comunes

• Esperar una adopción generalizada. Muy pocos receptores generan informes de RFC 6652 en la práctica. La mayoría de la visibilidad de fallos de SPF proviene de informes agregados de DMARC. Publica el registro de informe, pero no confíes en él como tu única visibilidad en fallos de SPF.
• No monitorear el buzón de informe. Si publicas una dirección de informe, monitoréala. Los informes no leídos no proporcionan valor. Analízalos automáticamente o utiliza un servicio de informe DMARC/SPF.
• Confundir con informes de DMARC ruf. Los informes forenses de DMARC (ruf) e informes de RFC 6652 son mecanismos separados. Ambos utilizan formato ARF, pero se activan por registros diferentes y pueden ser generados por receptores diferentes.
• Establecer rp=100 en dominios de alto volumen. Para dominios que envían millones de mensajes, solicitar informe de fallo al 100% puede generar un volumen abrumador. Comienza con un porcentaje bajo y aumenta según sea necesario.
• Olvidar el prefijo _spf._report. El registro DNS debe estar en _spf._report.yourdomain.com, no en el registro SPF en sí. Este es un registro TXT separado de tu política SPF.

Impacto en la entregabilidad

• Identifica remitentes no autorizados. Los informes de fallo revelan qué IPs están enviando correo con tu dominio en el remitente de sobre pero fallando SPF. Esto podría ser suplantación de identidad o un servicio legítimo olvidado.
• Respalda el refinamiento del registro SPF. Antes de endurecer tu política SPF de ~all a -all, los informes de fallo te ayudan a identificar cualquier remitente legítimo que aún no hayas autorizado.
• Complementa los informes de DMARC. Mientras los informes agregados de DMARC te indican las proporciones de éxito/fallo, los informes forenses de RFC 6652 te ofrecen los encabezados específicos e IPs de origen para fallos individuales — crítico para investigar nuevas campañas de suplantación.
• Alerta temprana para rotura de reenvío. Cuando una lista de correo o servicio de reenvío retransmite tus mensajes, SPF fallará porque la IP del servidor de reenvío no está en tu registro SPF. Los informes de fallo te ayudan a identificar estos casos para poder ajustar tu estrategia de autenticación (por ejemplo, confiar en DKIM para correo reenviado).

Related RFCs