Por qué el reenvío de correo rompe SPF (y qué hacen SRS y ARC)

El reenvío de correo rompe SPF porque SPF compara la dirección IP que se conecta con el registro del dominio del remitente del sobre, y un reenviador simple cambia lo primero sin cambiar lo segundo. El receptor final ve al servidor del reenviador entregando correo "de" example.com, no encuentra ese servidor por ninguna parte en el registro SPF de example.com y devuelve fail. No hay nada mal configurado en ninguno de los dos lados: así está diseñado SPF. Que el mensaje supere de todos modos DMARC depende casi por completo de DKIM.

Esta guía sigue un mensaje a través de un reenviador y muestra qué cambia cada uno de SRS, DKIM y ARC.

Qué comprueba SPF en realidad

Una entrega SMTP tiene dos identidades de remitente:

el remitente del sobre, indicado en el comando MAIL FROM y registrado después como Return-Path. Los rebotes van ahí.
la cabecera From, que es la que muestra el cliente de correo del destinatario.

SPF (RFC 7208) solo conoce la primera. El receptor toma el dominio del remitente del sobre (o el nombre HELO como alternativa, por ejemplo cuando el remitente del sobre está vacío, como en los rebotes), descarga su registro SPF y pregunta: ¿está listada la dirección IP que se me está conectando en este momento?

Entrega directa:

alice@example.com  ->  mail server of example.com (192.0.2.10)  ->  receiver
MAIL FROM:<alice@example.com>      connecting IP 192.0.2.10      spf=pass

Qué hace un reenviador simple

Un reenviador simple es un alias, un archivo .forward, una regla de "reenviar todo el correo a" o el reenvío de correo que viene con el dominio en muchos registradores. Acepta el mensaje y lo vuelve a enviar a otra dirección, conservando el remitente del sobre original para que los rebotes vuelvan al autor.

alice@example.com  ->  forwarder (203.0.113.7)  ->  bob's real mailbox
MAIL FROM:<alice@example.com>      connecting IP 203.0.113.7     spf=fail

203.0.113.7 pertenece al reenviador. example.com nunca ha oído hablar de esa dirección y no debería listarla: un remitente no puede conocer todas las direcciones a las que reenvían sus destinatarios.

SRS: reparar SPF para el reenviador

El Sender Rewriting Scheme cambia el remitente del sobre por una dirección del propio dominio del reenviador antes de volver a enviar:

MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.example>

HHH es un hash corto, TT una marca de tiempo, y el dominio y la parte local originales se conservan para que un rebote enviado a esta dirección pueda desempaquetarse y pasarse a alice@example.com. El hash impide que terceros abusen del reenviador como relé de rebotes.

Ahora el receptor comprueba el registro SPF de forwarder.example, que sí lista 203.0.113.7. SPF pasa.

Dos cosas que conviene saber sobre SRS:

No es un estándar del IETF. Es una especificación de la comunidad surgida del proyecto SPF, y las implementaciones difieren en los detalles.
Arregla SPF, no DMARC. Tras la reescritura, el dominio autenticado por SPF es forwarder.example, mientras que la cabecera From sigue diciendo example.com. DMARC exige que el dominio autenticado esté alineado con el dominio del From, así que la rama SPF de DMARC sigue fallando. Simplemente falla en silencio en lugar de a gritos.

DKIM: la parte que sobrevive

Una firma DKIM forma parte del mensaje, no de la conexión. Cubre el cuerpo y un conjunto elegido de cabeceras, y se verifica con una clave pública en el DNS del firmante. Un reenviador que pasa el mensaje sin modificarlo deja la firma válida, se conecte desde la IP que se conecte. Si el dominio firmante (d=) está alineado con el dominio del From, DMARC pasa solo por la rama DKIM.

DKIM se rompe cuando cambia una parte firmada:

una lista de correo añade [nombre-de-la-lista] al asunto o un pie al cuerpo
una pasarela reescribe el cuerpo, por ejemplo añadiendo un aviso legal o reescribiendo los enlaces
un sistema recodifica el mensaje de una forma que la canonicalización de la firma no tolera

El reenvío simple no hace ninguna de estas cosas. Las listas de correo hacen la primera constantemente.

Tabla de escenarios

Supongamos que example.com publica SPF, firma con d=example.com y tiene p=reject.

Escenario	Resultado SPF	Resultado DKIM	Resultado DMARC
Entrega directa	pass, alineado	pass, alineado	pass
Reenvío simple, mensaje intacto	fail	pass, alineado	pass (vía DKIM)
Reenvío simple, remitente sin DKIM	fail	none	fail
Reenvío con SRS, mensaje intacto	pass para el reenviador, no alineado	pass, alineado	pass (vía DKIM)
Reenvío con SRS, remitente sin DKIM	pass para el reenviador, no alineado	none	fail
Lista de correo que modifica el asunto o el cuerpo	pass para la lista, no alineado	fail (rota)	fail, salvo que la lista reescriba el From
Lo mismo, con una cadena ARC en la que el receptor confía	como arriba	como arriba	fail, pero el receptor puede anularlo localmente

Las filas segunda y quinta son las que importan en la práctica: SRS no puede rescatar a un remitente que no tiene DKIM alineado, y un remitente con DKIM alineado no necesita SRS para que DMARC pase.

ARC: transmitir lo que vio el intermediario

Authenticated Received Chain (RFC 8617, con estado Experimental) se ocupa de las filas de las listas de correo. Un intermediario que maneja el mensaje anota los resultados de autenticación que observó a la llegada y firma esa anotación. Cada salto añade un conjunto de tres cabeceras con un número de instancia:

ARC-Authentication-Results: i=1; lists.example.org;
   spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com;
   dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc1; …
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; …

Un segundo intermediario añade i=2, y así sucesivamente. El receptor final puede validar la cadena y ver que el mensaje pasaba DMARC cuando llegó a lists.example.org, antes de que la lista lo modificara.

La palabra importante es puede. ARC le dice al receptor lo que un sellador afirma haber visto. Creer o no a ese sellador es política local: los receptores PUEDEN respetar una cadena de un intermediario en el que confían, y son libres de ignorarla. ARC no es una garantía de entrega.

Por esta incertidumbre, las listas de correo suelen adoptar un enfoque más tosco para los remitentes cuyos dominios aplican DMARC de forma estricta: reescriben la cabecera From con una dirección del propio dominio de la lista, de modo que el mensaje se alinea con el SPF y el DKIM de la propia lista.

Leer la cabecera Authentication-Results

Envíe un mensaje a través del reenviador a un buzón que usted controle, abra el original y busque la cabecera Authentication-Results añadida por el receptor final (la que está más arriba):

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=forwarder.example;
   dkim=pass header.d=example.com header.s=s2026;
   dmarc=pass header.from=example.com;
   arc=pass
Return-Path: <SRS0=a1b2=XY=example.com=alice@forwarder.example>

Campo	Qué le dice
`smtp.mailfrom=`	El dominio contra el que se comprobó SPF. Si es el del reenviador, se está usando SRS.
`spf=`	Resultado para ese dominio y la IP que se conecta. `fail` con el dominio original significa un reenviador simple.
`header.d=`	El dominio cuya firma DKIM se validó. Compárelo con `header.from`.
`dmarc=`	El veredicto tras la alineación. Es el que decide.
`arc=`	Si había una cadena ARC y se validó.

Si prefiere pegar las cabeceras en lugar de leerlas, el analizador de cabeceras de correo las desglosa.

Consejos para remitentes

Firme todo con DKIM, alineado con su dominio del From. Cada servicio que envía en su nombre: proveedor de buzones, herramienta de boletines, facturación, soporte. Esto es lo que hace que su correo sobreviva al reenvío. SPF por sí solo nunca lo hará.
No añada las direcciones IP de los reenviadores a su registro SPF. No puede conocerlas todas, cambian, y cada include que añade cuenta para el límite de 10 consultas.
Pase a p=reject solo cuando los informes DMARC muestren alineación DKIM en todas sus fuentes legítimas. A un dominio en p=reject que dependa solo de SPF le rechazarán el correo reenviado.
Cuente con un pequeño residuo de fallos procedentes de listas de correo. El orden de despliegue de MX, SPF, DKIM y DMARC explicados lo tiene en cuenta.

Consejos si usted reenvía correo

Use un reenviador que implemente SRS, y a ser posible sellado ARC. Sin SRS, cada mensaje de un dominio con -all llega con spf=fail.
Considere recoger el correo en lugar de reenviarlo. Si el buzón de destino puede recuperar el correo de la cuenta antigua por POP o IMAP, no hay reenvío alguno y ninguna autenticación se ve alterada.
No reenvíe spam. El receptor final ve la IP de su reenviador entregándolo y se lo apunta al reenviador. Filtre antes de reenviar.
Considere alojar el buzón en lugar de reenviarlo. Un dominio que solo reenvía a un buzón gratuito es la configuración frágil de la mayoría de los avisos de "me falta correo": consulte la lista de comprobación DNS para correo que llega a spam.

Errores frecuentes

Tomar un spf=fail en un mensaje reenviado como prueba de suplantación. Mire dkim= y dmarc= antes de decidir.
Creer que SRS arregla DMARC. Arregla SPF para el dominio del reenviador; la alineación sigue perdida.
Añadir entradas include: para los reenviadores de sus destinatarios en su propio registro SPF.
Pasar a p=reject con autenticación solo por SPF porque "SPF pasa en todas nuestras pruebas". Las pruebas rara vez incluyen un reenviador.
Suponer que ARC obliga al receptor a aceptar. Es una evidencia que se ofrece a un receptor que puede confiar o no en el sellador.
Añadir un aviso legal en una pasarela de salida después de la firma DKIM. Eso rompe su propia firma antes de que el mensaje haya salido.

Compruébelo con OrbitProbe

La verificación SPF de OrbitProbe muestra el registro SPF que publica un dominio y señala los problemas estructurales habituales: varios registros, +all, un mecanismo all ausente, demasiadas consultas DNS. Ante un problema de reenvío, compruebe dos nombres: el dominio del remitente original (¿termina en -all, lo que hace que el reenvío simple falle de forma tajante?) y el dominio del reenviador (¿tiene siquiera un registro válido, para que el correo reescrito con SRS pueda pasar?). Una comprobación DNS lee la política publicada. Lo que le ocurrió a un mensaje concreto solo consta en la cabecera Authentication-Results de ese mensaje, así que lea ambas cosas.