Cuando el reenvío de correo rompe SPF (y lo que SRS repara)
Por Thomas · CISO virtual · 21 de agosto de 2026
En los informes DMARC de un dominio bien configurado, una línea acaba siempre por llamar la atención: un mensaje perfectamente legítimo, enviado por un empleado identificado, y sin embargo un fallo SPF rotundo. La IP de origen no pertenece ni al servidor de correo de la organización ni a ningún proveedor de envío conocido: pertenece a una universidad, a un alojamiento compartido, a un operador de buzones personales. La explicación cabe en una palabra: reenvío. En algún punto de la cadena, un destinatario configuró una regla para hacer seguir el correo hacia otro buzón, y ese simple salto basta para que SPF falle.
No es un error de configuración ni un ataque. Es una limitación estructural del protocolo, conocida desde el diseño: SPF valida la dirección IP del último servidor que entrega el mensaje, y un reenvío inserta exactamente un servidor más en el camino. El mecanismo SRS (Sender Rewriting Scheme) se inventó para amortiguar el golpe — pero repara menos de lo que suele creerse.
Este artículo desmonta la mecánica del fallo, explica por qué DKIM sobrevive al viaje en la mayoría de los casos, y detalla lo que SRS corrige realmente — y lo que deja intacto, empezando por la alineación DMARC. Al final espera una pregunta muy operativa: qué política publicar cuando una parte del tráfico legítimo pasa, inevitablemente, por reenvíos.
La mecánica: un reenvío desde la IP equivocada
SPF (RFC 7208) responde a una pregunta sencilla: ¿está la dirección IP que presenta este mensaje autorizada a enviar en nombre del dominio del sobre? El servidor receptor lee el dominio del MAIL FROM — el Return-Path —, consulta el registro TXT correspondiente y compara la IP entrante con la lista publicada. En el envío directo, todo va bien: el mensaje sale de ejemplo.es a través de un servidor o de una plataforma de emailing cuya IP figura en el SPF, y la comprobación pasa.
Un reenvío cambia el panorama. El buzón que hace seguir el correo — un alias, una regla de reenvío automático — primero acepta el mensaje y después lo reexpide hacia el destino final desde infraestructura propia. El reenvío ingenuo conserva el sobre original: el Return-Path sigue mostrando garcia@ejemplo.es, pero la IP que se conecta al servidor final es ahora la del reenviador. Esa IP no figura, evidentemente, en el SPF de ejemplo.es — y no tiene ninguna razón legítima para figurar ahí. Resultado mecánico: fallo, por mucho cuidado que se haya puesto en el registro original.
La severidad del castigo depende del calificador que cierra el registro: un -all expone el mensaje a un rechazo en la propia etapa SPF, un ~all produce un softfail más indulgente — matiz desmenuzado en la guía del mecanismo all de SPF. Desde el punto de vista de DMARC, sin embargo, el veredicto es el mismo en ambos casos: la contribución de SPF se ha perdido.
Por qué DKIM sobrevive al viaje
DKIM (RFC 6376) no mira la IP. La prueba viaja dentro del propio mensaje: una cabecera DKIM-Signature cubre criptográficamente un conjunto de cabeceras y el cuerpo. Da igual cuántos servidores se atraviesen — si el mensaje llega intacto, la firma se verifica, DKIM pasa, y como el dominio firmante (d=ejemplo.es) se alinea con el From visible, DMARC queda satisfecho. Ahí está la diferencia de diseño en una frase: SPF autentica un camino, DKIM autentica un contenido.
La condición cabe en una palabra: intacto. Un reenvío limpio, que retransmite el mensaje byte a byte, preserva la firma. Cualquier relevo que modifique el contenido la rompe: un banner «mensaje analizado» inyectado en el cuerpo, una recodificación MIME, un asunto con prefijo, un pie de página añadido. Las listas de discusión, que acumulan etiquetas de asunto y pies de página, son el caso patológico por excelencia — un campo de minas lo bastante denso como para merecer un examen aparte, el de las listas de correo frente a DMARC.
La consecuencia estratégica pesa mucho: a través de un reenvío, DKIM es la única línea de defensa que se mantiene en pie. Un dominio que firma con DKIM la totalidad de sus flujos atraviesa la mayoría de los reenvíos sin daño; un dominio que solo cuenta con SPF lo pierde todo en cuanto un destinatario crea una regla de reenvío.
SRS: reescribir el sobre para salvar SPF
El reenvío ingenuo crea en realidad dos problemas. El primero es el fallo SPF ya descrito. El segundo es el enrutamiento de los rebotes: si el mensaje reenviado es rechazado al final de la cadena, la notificación de fallo vuelve al Return-Path original — hacia un remitente que no sabe nada del reenvío y recibe rebotes incomprensibles. SRS, formalizado a principios de los años 2000 como respuesta al despliegue de SPF, resuelve ambos de un solo gesto.
El principio: en el momento de reexpedir, el reenviador reescribe el Return-Path a nombre propio, encapsulando la dirección original en la parte local. Un mensaje de garcia@ejemplo.es reenviado por reenvio-ejemplo.es vuelve a salir con un sobre de esta forma:
MAIL FROM: SRS0=k3v7=T9=ejemplo.es=garcia@reenvio-ejemplo.es
Doble efecto. Por un lado, el servidor final evalúa ahora SPF contra reenvio-ejemplo.es, cuyo registro sí autoriza la IP del reenviador: la comprobación pasa. Por otro, un eventual rebote vuelve al reenviador, que desencapsula la dirección y encamina la notificación hacia el remitente original. Las implementaciones están maduras — módulos SRS en las grandes suites de correo, demonios dedicados en el lado de Postfix — y la mayoría de los alojadores serios reescriben hoy los reenvíos que operan.
Lo que SRS no repara: la alineación DMARC
Hasta aquí la fontanería. Queda la identidad — y ahí es donde el entusiasmo se enfría. DMARC no exige solo un SPF que pase: exige que el dominio validado por SPF se alinee con el dominio del From visible, el que lee el destinatario. Ahora bien, tras la reescritura SRS, el Return-Path pertenece al reenviador (reenvio-ejemplo.es) mientras el From sigue mostrando ejemplo.es. Dos dominios sin vínculo organizativo: la alineación falla, tanto en modo estricto como en modo relajado — y el DNS Tree Walk de DMARCbis, que determina el dominio organizativo, jamás emparentará dos zonas ajenas entre sí.
El resultado es un patrón tan frecuente en los informes que merece expediente propio: un SPF que pasa mientras DMARC falla. SPF luce en verde — para el dominio del reenviador. DMARC, en cambio, juzga el dominio de origen, y ya solo le queda DKIM para dictar veredicto.
Dicho de otro modo: SRS repara la entregabilidad del reenviador y el enrutamiento de los rebotes; no repara la autenticación del dominio de origen. Tras un reenvío con SRS, la suerte DMARC de un mensaje descansa al 100 % en la supervivencia de la firma DKIM. Incluso equipos curtidos lo descubren tarde: SRS es indispensable para el reenvío moderno, y perfectamente neutro para la alineación DMARC del remitente.
Tres situaciones muy concretas
El alias universitario. Las universidades reparten direcciones vitalicias (nombre.apellido@alumni-ejemplo.es) que no almacenan nada: todo se reenvía a un buzón personal, a menudo Gmail. Cada mensaje enviado a un antiguo alumno atraviesa por tanto la infraestructura de la universidad antes de llegar a Google. En los informes del dominio emisor, eso dibuja líneas características: IP académicas, un SPF que falla (o que pasa sobre un dominio de terceros vía SRS), y un DKIM que salva la situación siempre que la firma haya llegado intacta.
El buzón de contacto reenviado. Una pyme hace seguir contacto@ejemplo.es hacia la cuenta Gmail personal de la gerencia. Aquí el dominio juega el papel del reenviador: lo que se reexpide son los mensajes de los clientes, y es la autenticación de esos mensajes la que se degrada. Sin SRS, Gmail ve llegar correo de terceros desde una IP que el SPF de esos terceros nunca autorizó — con la carpeta de spam como precio probable, pagado por el correo de los clientes, no por el propio. Operar un reenvío crea obligaciones hacia los dominios ajenos.
La redistribución interna. Una dirección de servicio (pedidos@ejemplo.es) que reexpide a tres empleados, o un dominio antiguo redirigido al nuevo tras una fusión: la misma mecánica, salvo que el tráfico es previsible y la infraestructura está bajo control. Es el caso más fácil de sanear — y a menudo el primero visible en los informes.
ARC, la red complementaria
Para las cadenas de reenvío que ni SRS ni DKIM logran salvar, entra en escena un tercer estándar: ARC (Authenticated Received Chain, RFC 8617). La idea: cada intermediario sella, en cabeceras dedicadas, el resultado de las comprobaciones que él mismo efectuó al recibir. El receptor final puede así constatar que el mensaje pasaba SPF y DKIM antes del reenvío, y decidir pasar por alto un fallo DMARC constatado a la llegada.
La palabra clave es «decidir»: ARC no obliga a nada, documenta. El receptor solo tiene en cuenta la cadena si confía en los intermediarios que la firmaron — Gmail y Microsoft 365 la evalúan, cada uno según criterios propios. El funcionamiento detallado, sello a sello, está descrito en la guía dedicada a ARC. Una red valiosa, pues, pero solo una red: nada sustituye a una firma DKIM que sobrevive al trayecto.
Lo que muestran los informes RUA
La buena noticia: el reenvío deja una huella muy reconocible en los informes agregados. Las líneas afectadas combinan volúmenes modestos, IP dispersas y cambiantes — universidades, alojadores, operadores de buzones personales —, un SPF que falla contra el dominio de origen (o que pasa sin alinear sobre un dominio de relevo, la marca delatora de SRS), y un DKIM alineado que, por sí solo, mantiene el veredicto DMARC en verde.
Las líneas que conviene vigilar de cerca son las otras: aquellas en las que DKIM falla también. Un relevo que modifica el contenido — banner, recodificación — produce correo legítimo que suspende en toda regla: exactamente el correo que se perderá cuando la política se endurezca. Estimar esa parte residual, relevo a relevo, es precisamente el trabajo preparatorio del paso a la aplicación efectiva — y una plataforma de análisis que pone nombre a las IP (tal operador de buzones, tal infraestructura académica) convierte líneas anónimas en un diagnóstico accionable.
Qué política cuando el reenvío forma parte de la vida
¿Descarta el reenvío de los destinatarios llegar a p=reject? No — pero el paso merece darse con los ojos abiertos. Tres principios se imponen. Primero, firmar con DKIM absolutamente todos los flujos, correo transaccional y aplicativo incluidos: es la única autenticación que atraviesa los reenvíos, y cada flujo sin firmar está condenado al primer salto. Segundo, cuantificar antes de endurecer: los informes dicen con precisión qué parte del tráfico legítimo transita por relevos que destruyen la firma — a menudo una fracción marginal, a veces un punto ciego significativo. Tercero, aceptar un residuo: un dominio en p=reject perderá los raros mensajes reenviados cuya firma se rompió por el camino. Es un coste real, generalmente mínimo, que se sopesa frente a todo lo que la aplicación efectiva cierra a los suplantadores.
DMARCbis no ha cambiado este equilibrio — el reenvío sigue siendo el límite asumido del modelo —, pero el modo de prueba (t=y), que sustituye a la antigua etiqueta pct, ofrece un peldaño intermedio limpio para observar el efecto de una política antes de hacerla plenamente vinculante.
En resumen
Un reenvío reexpide el mensaje desde la IP del relevo, ausente — y con razón — del SPF del remitente original: el fallo SPF es estructural, no accidental. DKIM sobrevive mientras el contenido no se altere, lo que lo convierte en la única autenticación fiable a través de un salto. SRS reescribe el Return-Path a nombre del reenviador: salva la entregabilidad del reenvío y el enrutamiento de los rebotes, pero no restaura nada de la alineación DMARC del dominio de origen — tras SRS, todo descansa en DKIM, con ARC como red documental que los grandes receptores son libres de honrar. En los informes, el patrón se lee con claridad, y se gestiona: firma DKIM generalizada, cuantificación del residuo, y después endurecimiento.
El punto de partida queda al alcance de la mano: una pasada del dominio por el análisis DMARC gratuito revela el estado de SPF, de DKIM y de la política publicada, reenvíos incluidos. Para seguir después esos flujos reenviados semana tras semana y llevar el dominio hacia p=reject sin sacrificar correo legítimo, la creación de una cuenta abre el acceso a los informes descodificados, con las fuentes identificadas — incluidas las que no hacen más que hacer seguir el correo.
Guías relacionadas
- DMARC falla aunque SPF pasa: entender la alineación
Un informe agregado puede mostrar spf=pass y dmarc=fail en el mismo mensaje. La explicación se llama alineación, y cambia la lectura de los informes.
- Inventariar los remitentes terceros de un dominio: el mapa antes de DMARC
Ningún proyecto DMARC sobrevive a un tercero olvidado: familias de remitentes, tres fuentes de verdad y un método para mapear los envíos antes de p=reject.
- ARC: la cadena de recepción autenticada (Authenticated Received Chain)
Las listas de distribución y los reenvíos rompen SPF y DKIM, y DMARC falla sobre correo legítimo. ARC permite recuperarlo: lo que hace y lo que no cubre.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.