Defaults.Exposed › Soluciones › Guides

El correo reenviado falla SPF — por qué no puede arreglarlo y qué funciona de verdad (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Vea cómo calificamos.

No puede hacer que SPF pase para el correo reenviado — el reenvío rompe SPF por diseño, y la solución honesta es DKIM alineado, que sobrevive al reenvío. La escala abarca todo el censo: 7.355.985 de 138.927.207 dominios que publican SPF autorizan únicamente el include de reenvío de Namecheap, con una proporción de SPF estricto del <0.1%, según el censo de Defaults.Exposed de 261 millones de dominios.

A continuación: por qué ningún registro SPF que pudiera escribir sobrevive al reenvío, por qué SRS y ARC no son herramientas que usted controle, y la solución que sí se sostiene — la firma DKIM con su propio dominio como su pass de DMARC — además del único caso que también rompe DKIM (las listas de correo que reescriben los mensajes) y qué hacer con ese remanente.

¿Por qué el reenvío rompe SPF?

Los sistemas receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no contra la cabecera From. Cuando usted envía directamente, la IP de su servidor está en su registro SPF y la comprobación pasa. Cuando su destinatario reenvía automáticamente el mensaje — a un Gmail personal, a través de un alias universitario, mediante el producto de reenvío de un registrador — el servidor del reenviador lo retransmite, normalmente conservando su dominio en el Return-Path. El receptor final ahora pregunta: ¿está este servidor de reenvío autorizado en su registro SPF?

No lo está, y nunca lo estará: usted no eligió al reenviador, no sabe que existe, y el mismo mensaje reenviado mañana por otro servicio fallaría desde otra IP. SPF responde a una sola pregunta — “¿vino esta IP de un servidor autorizado por el dominio del Return-Path?” — y para el correo reenviado la respuesta verdadera es no. El fallo es SPF funcionando según lo especificado, no un error de su registro.

El censo muestra lo habitual que es esta vía: 7.355.985 dominios autorizan el include de reenvío de correo de Namecheap (spf.efwd.registrar-servers.com) — el producto de reenvío de un solo proveedor, extraído de los 139 millones de publicadores de SPF — con una proporción de SPF estricto del <0.1% y solo un 0,2% aplicando DMARC. Esa plantilla laxa no es descuido: el reenvío es precisamente donde un -all estricto falla por exceso, y el proveedor cuyo producto es el reenvío la configura en consecuencia. La historia completa del calificador está en nuestro informe ~all vs -all, y el panorama proveedor por proveedor en qué proveedor de correo ofrece el SPF más sólido.

¿No puedo simplemente añadir el servidor del reenviador a mi registro SPF?

No — y el porqué es todo este artículo:

1. No puede enumerar a los reenviadores. Cualquier destinatario, en cualquier lugar, puede reenviar su correo a través de cualquier servicio. Su registro SPF tendría que listar servidores que usted no puede conocer de antemano.
2. Listarlos anularía el propósito. Los grandes servicios de reenvío retransmiten correo de millones de clientes. Ponga sus rangos en su registro y cada mensaje que cualquiera de sus usuarios retransmita — incluido el de un suplantador — pasará SPF como si fuera usted.

La misma lógica descarta relajar su calificador para “hacer que el reenvío funcione”: el calificador no es la razón por la que falla el correo reenviado, y una vez que DMARC entra en juego cambia menos de lo que afirman la mayoría de las guías — vea los datos del calificador. El registro no es la palanca aquí. Deje de tirar de ella.

¿Y SRS y ARC? ¿No arreglan el reenvío?

Lo abordan — pero ninguno de los dos está en sus manos desplegarlo:

Datos y estado de los mecanismos a fecha de 2026-06-29.

SRS hace desaparecer el problema de SPF del reenviador, no el suyo: reescribir el Return-Path cambia qué SPF se comprueba, mientras que su cabecera From — el dominio que DMARC defiende — queda intacta. ARC es una decisión de confianza entre operadores de infraestructura. Si una guía le dice que “implemente SRS” como propietario de dominio, le ha confundido con el proveedor de reenvío.

¿Cómo hago que mi correo sobreviva al reenvío?

Haga de DKIM, alineado con su dominio, su pass de DMARC. Una firma DKIM es criptografía que viaja en las cabeceras del mensaje: se verifica dondequiera que el mensaje acabe, por muchos servidores que lo hayan retransmitido, siempre que el contenido firmado no se haya modificado. DMARC solo necesita un pass alineado — SPF o DKIM — así que cuando el reenvío mata la pata de SPF, el DKIM alineado mantiene el mensaje autenticado.

1. Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Le muestra si tiene DKIM siquiera, si firma con su dominio y en qué punto está su DMARC — para que corrija la brecha real en lugar de pelearse con su registro SPF.
2. Confirme que el reenvío es realmente su problema. En la cabecera Authentication-Results de un mensaje afectado, el correo directo pasa SPF mientras que la copia reenviada falla desde la IP del servicio de reenvío. Si SPF y DKIM pasan pero DMARC sigue fallando, lo que tiene es un problema de alineación — vea DMARC falla pero SPF y DKIM pasan.
3. Active la firma DKIM con su propio dominio en cada servicio de envío — primero el proveedor de correo, después los ESP y los remitentes transaccionales. Los valores por defecto de los proveedores suelen firmar con el dominio del proveedor, que no se alinea; usted quiere d=yourdomain. Empiece por cómo arreglar DKIM, con rutas de clics para Google Workspace y Microsoft 365.
4. Verifique la alineación, no solo un pass. El dominio d= de la firma debe coincidir con su dominio From; un dkim=pass sobre el dominio de otro no hace nada por su DMARC.
5. Deje su registro SPF en paz. Manténgalo preciso para su correo directo — sigue autenticando la mayor parte de su tráfico y sigue siendo su segunda pata de DMARC. Simplemente deje de intentar que cubra a los reenviadores.
6. Vuelva a analizar y escalone después la aplicación de DMARC de forma deliberada — siguiente sección, y la guía de despliegue de p=none a p=reject.

Esta combinación — SPF más un DMARC en aplicación apoyado en DKIM alineado — es el patrón a prueba de reenvío, y es poco frecuente: de los 77,5 millones de dominios que publican ~all, solo el 9,2% (7.116.774) lo respalda con una política DMARC de aplicación, y apenas el 3,87% de los 261 millones de dominios calificados (10.092.481) completa la tríada íntegra SPF + DKIM + DMARC aplicado, según el censo (2026-06-29).

¿Y las listas de correo que reescriben los mensajes?

La única vía de reenvío que el DKIM alineado no sobrevive: las listas de correo que modifican el mensaje — una etiqueta [list-name] en el asunto, un pie de página para darse de baja, un adjunto eliminado. Cambie el contenido firmado y el hash del cuerpo ya no coincide, así que DKIM también falla (dkim=fail: body hash did not verify es la guía propia de ese fallo). Ahora las dos patas de DMARC están muertas, y solo la lista puede mitigarlo (reescritura del From, sellado ARC).

Este remanente es exactamente para lo que existe la aplicación escalonada de DMARC. Pasar por p=quarantine con una rampa de pct mientras vigila los informes agregados le muestra cuánto de su correo real fluye por listas que reescriben antes de que una política p=reject empiece a rebotarlo. No salte a reject en un dominio cuyos usuarios viven en listas de correo; tampoco se quede estancado en p=none para siempre. La guía de despliegue escalonado recorre la rampa.

Preguntas frecuentes

¿El reenvío también rompe DKIM? El reenvío simple, no: la firma viaja con el mensaje y se verifica en el receptor final. DKIM se rompe solo cuando el contenido firmado se modifica en tránsito — las etiquetas de asunto y los pies de página de las listas de correo son el caso clásico — y por eso el remanente de las listas se gestiona con el escalonado de la política DMARC, no con nada en el DNS.

¿Debería cambiar de -all a ~all para que el reenvío deje de fallar? Cambiar el calificador no hará que los reenviadores pasen — no es la razón por la que fallan. Es revelador que el include de reenvío de Namecheap, con 7.355.985 dominios y la mayor población de reenvío dedicado del censo (2026-06-29), venga con una proporción de SPF estricto del <0.1%: el SPF laxo es posiblemente la plantilla correcta para un producto de reenvío. Vea el informe ~all vs -all para saber qué cambia realmente el calificador.

¿Por qué mi correo pasa SPF cuando lo envío directamente pero falla cuando alguien lo reenvía? El receptor comprueba si la IP del último servidor transmisor está autorizada por el registro SPF del dominio de su Return-Path. Directo: su servidor, en su registro, pass. Reenviado: el servidor del reenviador, fuera de su registro, fail. Su registro no cambió — cambió la IP transmisora.

¿Puedo configurar SRS para arreglar esto? Solo si usted es el reenviador. SRS se ejecuta en el servidor que hace el reenvío, e incluso donde se ejecuta, el pass de SPF resultante pertenece al dominio del reenviador y no se alinea con su From — su DMARC sigue necesitando la pata de DKIM.

¿SPF es inútil si el reenvío lo rompe de todos modos? No. La mayor parte del correo se entrega directamente, donde SPF funciona exactamente como está previsto, y sigue siendo una de sus dos patas de DMARC. De los 261.086.232 dominios del censo (2026-06-29), 138.927.207 publican SPF — mantenga el suyo preciso mediante la página de corrección de SPF, y deje que DKIM se encargue del resto reenviado.

Envíe el informe al propietario

Si está arreglando esto para un cliente o para su empresa, cierre el círculo con pruebas. Una vez que el DKIM con dominio personalizado esté activo y DMARC esté escalonado, vuelva a ejecutar el análisis gratuito y reenvíe el informe calificado al propietario del negocio: fechado, en lenguaje claro, mostrando que el dominio permanece autenticado incluso cuando su correo se reenvía. Ese es el documento para la renovación del ciberseguro y el próximo cuestionario de seguridad de proveedores — un antes y después documentado, no un “activé algo”.

Compruebe su dominio → · DMARC falla pero SPF y DKIM pasan → · Arreglar DKIM → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.