SPF Softfail Vs SPF Hardfail: ¿Cuál es la diferencia?

Aprenda la diferencia entre SPF Softfail y Hardfail, las mejores prácticas y cómo proteger el correo electrónico de su empresa con PowerDMARC. Guía completa para responsables de TI y administradores de correo electrónico.

Con SPF (Sender Policy Framework), tienes la flexibilidad de configurar tu sistema para responder a los fallos de autenticación de dos maneras: Hardfail o Softfail. En este blog, nuestros expertos de PowerDMARC le explicarán las diferencias entre SPF hardfail y softfail, cómo configurar cada uno de ellos y casos de uso reales para equipos de TI y seguridad. ¡Empecemos!

¿Qué es un fallo de SPF?

Antes de profundizar en las diferencias entre fallo duro y fallo suave, es esencial comprender qué constituye un fallo SPF y cómo funciona la autenticación SPF.

SPF (Sender Policy Framework) es un protocolo de autenticación de correo electrónico que permite a los propietarios de dominios especificar qué direcciones IP están autorizadas para enviar correos electrónicos en nombre de su dominio. Cuando se recibe un correo electrónico, el servidor receptor comprueba la dirección IP del remitente con el registro SPF del dominio para determinar si el remitente está autorizado.

La comprobación SPF se realiza con respecto al dominio de la ruta de retorno, que representa la identidad dada que se está autenticando. Es fundamental que el registro SPF se publique correctamente para garantizar una autenticación SPF adecuada y evitar problemas de entrega del correo electrónico.

Resultados de la autenticación SPF

• Pasar: La IP del remitente está autorizada en el registro SPF.
• Fallo (fallo grave): la IP del remitente no está autorizada explícitamente (-all).
• Error leve: es probable que la IP del remitente no esté autorizada (~todos)
• Neutral: No hay declaración de política sobre el remitente (?all)
• Ninguno: No existe ningún registro SPF para el dominio.
• TempError: Error temporal en la búsqueda de DNS
• PermError: Error permanente en la sintaxis del registro SPF

Cada resultado SPF es una declaración explícita sobre el estado de autorización del remitente. Un «fallo» es una declaración explícita y contundente de que el remitente no está autorizado, mientras que un «fallo leve» es una declaración débil que indica una probable, pero no definitiva, falta de autorización.

Se produce un error SPF cuando la comprobación de autenticación devuelve un resultado «Fail» (Fallo) o «Soft Fail» (Fallo leve), lo que indica que es posible que el servidor de envío no esté autorizado para enviar correos electrónicos para ese dominio.

Fallo duro frente a fallo suave de SPF: explicación de las diferencias clave

La tabla que figura a continuación explica la diferencia básica entre SPF hardfail y softfail.

Nota: El mecanismo hardfail («-all») está diseñado para proporcionar la máxima protección contra el phishing y los correos electrónicos falsificados, rechazando los mensajes de remitentes no autorizados. Sin embargo, una configuración incorrecta puede dar lugar a correos electrónicos no entregables y a una tasa de rebote del 100 % para las fuentes no autorizadas.

En la sintaxis del registro SPF, solo la dirección o direcciones IP especificadas en el registro SPF están autorizadas para enviar correos electrónicos en nombre del dominio. Todas las demás fuentes se consideran remitentes no autorizados y pueden bloquearse o marcarse como sospechosas, dependiendo del tipo de fallo.

SPF Hardfail frente a Softfail: según se define en RFC 

Según RFC 7208:

• Un resultado "Fail" para SPF indica directamente que el remitente del correo electrónico no está autorizado por el dominio remitente. "Fail" es sinónimo del resultado Hardfail (-all) que es claramente indicativo del uso de un dominio no autorizado. 
• Sin embargo, un enfoque mucho más relajado es la configuración de SPF Softfail, que indica una «probable» indicación de uso no autorizado del dominio.

Gestión de fallos del destinatario en Hardfail y Softfail 

En la sección 8.4, el RFC define los siguientes escenarios de gestión de resultados para los resultados de fallo duro SPF frente a los resultados de fallo suave SPF: 

1. SPF Hardfail / Fail 

Para el resultado "Fail" o hardfail, el servidor del destinatario puede optar por rechazar el correo electrónico no autorizado. Si se trata de una transacción SMTP, debe devolverse un código de error 550 5.7.1 con una descripción de error adecuada. 

Si el servidor del destinatario no rechaza el correo electrónico durante la transacción SMTP, la RFC recomienda a los receptores que registren los resultados SPF en la cabecera Received-SPF o Authentication-Results. 

2. SPF Softfail

Como política más flexible, Softfail indica que el dominio de gestión administrativa sospecha que el correo electrónico no está autorizado, pero no desea rechazarlo directamente. En este caso, el mensaje se entrega, pero con una advertencia para una revisión posterior.  

¿Qué modo de fallo SPF debe utilizar?

La mayoría de los dominios, incluidos los de las principales organizaciones y empresas tecnológicas, utilizan una combinación de políticas SPF en función de sus necesidades específicas y prácticas de correo electrónico. La elección entre SPF hard fail y soft fail depende de la infraestructura de correo electrónico de su organización, los requisitos de seguridad y la tolerancia al riesgo. A continuación, le ofrecemos un marco de decisión que le ayudará a elegir:

Elija SPF Hard Fail (-all) cuando:

• Tienes control total sobre todas las fuentes de envío de correo electrónico.
• Tu infraestructura de correo electrónico está consolidada y bien documentada.
• La seguridad es la máxima prioridad por encima de la capacidad de entrega.
• Rara vez utilizas servicios de correo electrónico de terceros.
• Dispone de una supervisión DMARC completa.

Elija SPF Soft Fail (~all) Cuando:

• Estás implementando SPF por primera vez.
• Utilizas varios servicios de correo electrónico de terceros.
• La capacidad de entrega del correo electrónico es fundamental para las operaciones comerciales.
• Tienes configuraciones complejas de reenvío o retransmisión de correo electrónico.
• Todavía estás identificando todas las fuentes de correo electrónico legítimas.

Casos de uso comunes para SPF Hard Fail y Soft Fail

Casos de uso de SPF Hard Fail:

• Instituciones financieras: Bancos y cooperativas de crédito que exigen una autenticación estricta del correo electrónico.
• Organismos gubernamentales: Organizaciones con altos requisitos de seguridad
• Dominios para la protección de marcas: Dominios utilizados exclusivamente para la protección de marcas.
• Dominios de correo electrónico transaccional: Dominios dedicados para correos electrónicos automatizados

Casos de uso de SPF Soft Fail:

• Dominios de marketing: Dominios que utilizan múltiples plataformas de marketing por correo electrónico
• Empresas SaaS: Organizaciones con infraestructuras de correo electrónico complejas.
• Instituciones educativas: Universidades con múltiples departamentos y sistemas de correo electrónico.
• Entornos de prueba: Dominios en fase de implementación de SPF

Escenario real: si eres un administrador de TI que supervisa la seguridad del correo electrónico de una empresa SaaS de tamaño medio que utiliza Google Workspace, Salesforce y Mailchimp, puedes empezar con un fallo suave para garantizar que todos los correos electrónicos legítimos se entreguen mientras supervisas y perfeccionas tu registro SPF.

¿Cuándo se debe utilizar SPF Hard Fail o Soft Fail?

En el caso de la retransmisión de correo SMTP, puede considerar el softfail SPF como una apuesta más segura frente al hardfail. Averigüemos cómo: 

La retransmisión de correo electrónico SMTP es la transferencia automática de mensajes de un servidor a otra entrega. Esto significa que el correo electrónico se entrega a un servidor cuya dirección IP no figura en el registro SPF de su dominio. Esto lo convierte en un remitente no autorizado para su correo electrónico, aunque, en la práctica, es legítimo. 

¿Tiene usted algún control sobre esta actividad? La respuesta es no, ya que el correo electrónico se retransmite automáticamente por parte del destinatario. En estas circunstancias, SPF fallará para los correos electrónicos retransmitidos. 

Aquí es donde tener una política SPF hardfail puede traerle problemas. Como ya sabemos, los mecanismos de hardfail pueden provocar el rechazo de mensajes fallidos. Por lo tanto, estos correos electrónicos retransmitidos pueden no ser entregados si su dominio está configurado con una política hardfail. 

¿Lo peor? Las medidas tomadas por la política de gestión de fallos anularán los resultados de autenticación DMARC y DKIM . Básicamente, incluso si DKIM y posteriormente DMARC pasan la comprobación, el correo electrónico puede seguir sin entregarse.   

Como se especifica en RFC 7489 Sección-10.1 si las comprobaciones SPF se realizan antes de las operaciones DMARC, la presencia de un prefijo "-" en el mecanismo SPF de un remitente, como "-all", podría provocar el rechazo inmediato de los correos electrónicos. Este rechazo se produce al principio del proceso de gestión del correo electrónico, incluso antes de que tenga lugar cualquier procesamiento DMARC.

Por lo tanto, si la política SPF del remitente de un correo electrónico incluye un mecanismo «-all», que indica una política estricta para rechazar los correos electrónicos que no superan las comprobaciones SPF, esto podría dar lugar al rechazo del mensaje antes de que se apliquen las políticas DMARC o se realice cualquier procesamiento. Este rechazo temprano puede producirse independientemente de si el correo electrónico acaba superando la autenticación DMARC.

Por lo tanto, en estas circunstancias, el mecanismo SPF Soft fail prevalece sobre el Hard fail. Se trata de un enfoque de riesgo considerablemente bajo que deja margen para la revisión, ya que simplemente marca los correos electrónicos autorizados en lugar de rechazarlos. 

Vulnerabilidades de omisión y retransmisión de SPF

Comprender las posibles vulnerabilidades en la implementación de SPF es fundamental para mantener una seguridad sólida del correo electrónico:

Escenarios comunes de elusión del SPF:

• Reenvío de correos electrónicos: los correos electrónicos legítimos reenviados a través de servicios de terceros pueden fallar el SPF.
• Servidores de listas de correo: los mensajes enviados a través de listas de correo suelen cambiar la IP del remitente.
• Servicios de correo electrónico en la nube: los rangos de IP dinámicos en los servicios en la nube pueden provocar fallos de SPF.
• Clientes de correo electrónico móvil: correos electrónicos enviados desde dispositivos móviles a través de diferentes redes.

Mejores prácticas de mitigación:

• Implementa DKIM junto con SPF para obtener una autenticación adicional.
• Utilice DMARC para gestionar los fallos de SPF con elegancia.
• Auditar y actualizar periódicamente los registros SPF.
• Supervisar los informes de autenticación de correo electrónico en busca de anomalías.

¿Cómo funcionan los registros SPF?

Para implementar SPF para sus correos electrónicos, necesita crear y publicar un registro SPF en el DNS de su dominio. Un ejemplo típico de registro SPF es el siguiente:

v=spf1 include:_spf.google.com ~all

En este registro SPF, estás autorizando todos los correos electrónicos que se originan en las direcciones IP que aparecen en el registro SPF de Google. El mecanismo de fallo se define al final del registro (~all), es decir, Softfail. 

Por lo tanto, un registro SPF define la versión de protocolo utilizada, las fuentes de envío que está autorizando y el mecanismo de fallo. Cuando publica este registro en su DNS, se asegura de que sólo los remitentes autorizados pueden enviar correos electrónicos en nombre de su dominio. Si una fuente no autorizada intenta hacerse pasar por usted, SPF falla con el tipo de mecanismo de fallo definido en su registro. 

Estrategias de aplicación segura del SPF

La implementación óptima del SPF es esencial para proteger la comunicación por correo electrónico contra el suplantación de identidad y phishing . Siguiendo las mejores prácticas, las organizaciones pueden mejorar su postura de seguridad del correo electrónico y proteger la reputación de su marca. A continuación se presentan algunas estrategias y directrices para implementar SPF de forma segura:

1. Utilice una herramienta de generación de registros SPF

El proceso de implementación de SPF comienza con la generación del registro. Puede crear su registro manualmente si conoce bien las etiquetas SPF. Sin embargo, este método es propenso a errores humanos. Lo ideal es utilizar nuestro generador SPF automatizado. Esto le ayuda a crear un registro SPF sin errores, preciso y personalizado para las necesidades de su organización.

2. Utilizar mecanismos SPF adecuados

Utilice mecanismos SPF como "include", "a" e "IP4" para especificar las fuentes de envío permitidas. Sea prudente a la hora de seleccionar los mecanismos en función de su infraestructura de correo electrónico y asegúrese de que reflejan fielmente sus prácticas de envío de correo electrónico.

3. Mantenga y optimice su registro SPF

Es necesario mantener y optimizar su registro del Marco de políticas del remitente (SPF) para evitar que funcione mal. El SPF tiende a fallar cuando los remitentes autorizados superan el límite de 10 búsquedas DNS por parte del destinatario. Para mantener un límite de búsqueda óptimo, nuestro SPF alojado es su mejor opción. Ayudamos a los propietarios de dominios a optimizar el SPF con un solo clic, para mantenerse por debajo de los límites de búsqueda y anulación y mantener un SPF sin errores. 

4. Combinar SPF con DMARC

Despliegue de DMARC (Domain-based Message Authentication, Reporting, and Conformance) junto con SPF proporciona una capa adicional (aunque esencial) de seguridad. DMARC permite a los propietarios de dominios especificar las políticas de gestión del correo electrónico, incluidas las medidas que deben tomarse con los mensajes que no superen el SPF.

DMARC ha demostrado resultados probados en la minimización del fraude por correo electrónico, el compromiso y los ataques de suplantación de identidad. 

5. Implementar políticas estrictas de gestión de fallos de SPF

Configure su registro para tratar fallos de autenticación SPF con políticas estrictas, como rechazar o marcar correos electrónicos de dominios con fallos. Para ello, puede implementar SPF hardfail o SPF softfail en lugar de una política neutral.

6. Supervisar los resultados de autenticación SPF

Implemente informes DMARC para supervisar los resultados de autenticación SPF, como SPF pass y fail, así como los errores de alineación. A analizador DMARC puede ayudarle a analizar los datos de autenticación SPF de forma organizada y legible.

Palabras finales

No hay una respuesta directa a la pregunta "¿Qué es mejor? SPF hardfail o softfail". Aunque la etiqueta hardfail puede proporcionarle una mayor seguridad, la elección de la solución correcta para supervisar sus fuentes de envío se vuelve crucial. 

Autenticación de dominio avanzada de PowerDMARC autenticación de dominio y de informes de PowerDMARC proporciona soluciones SPF y DMARC para empresas de todos los tamaños. 

Prueba la plataforma con certificación SOC2 en la que confían miles de organizaciones en todo el mundo. ¡Comience hoy mismo su prueba gratuita hoy mismo!

Preguntas frecuentes

1. ¿Cuál es la razón del fallo suave de SPF?

El fallo suave SPF se produce cuando se envía un correo electrónico desde una dirección IP que no está autorizada explícitamente en el registro SPF del dominio, pero el propietario del dominio ha configurado un mecanismo «~all» en lugar de «-all». Esto indica que el remitente «probablemente no está autorizado», pero permite que el correo electrónico se entregue con una bandera de advertencia en lugar de ser rechazado directamente.

2. ¿Qué es un fallo grave 550 5.7.0 SPF?

El error «550 5.7.0 SPF hard fail» se produce cuando un servidor de correo electrónico rechaza un mensaje porque la dirección IP del remitente no está autorizada en el registro SPF del dominio que termina en «-all». Se trata de un error permanente que impide la entrega del correo electrónico e indica que el servidor receptor tiene políticas estrictas de aplicación de SPF.

3. ¿Cuándo se produciría un fallo grave del SPF?

Se produce un error grave de SPF cuando: 1) La IP de envío no aparece en el registro SPF del dominio, 2) El registro SPF termina con «-all» (política de error grave), 3) El correo electrónico se envía desde un servidor o servicio no autorizado, 4) Hay errores de configuración en el registro SPF, o 5) El dominio ha implementado políticas estrictas de autenticación de correo electrónico.

4. ¿Qué es el símbolo de fallo grave en SPF?

El símbolo de fallo grave en SPF es el signo menos «-» seguido de «all» (escrito como «-all»). Este mecanismo indica a los servidores de correo electrónico receptores que rechacen cualquier correo electrónico que no coincida con las direcciones IP o los dominios autorizados que figuran en el registro SPF. Es la política SPF más estricta y proporciona el máximo nivel de seguridad en la autenticación del correo electrónico.

5. ¿Debería utilizar SPF hard fail o soft fail para mi negocio?

Para la mayoría de las empresas, comience con SPF soft fail (~all) durante las fases de implementación y prueba para evitar bloquear correos electrónicos legítimos. Una vez que haya identificado todas las fuentes de envío autorizadas y haya realizado pruebas exhaustivas, considere pasar a hard fail (-all) para obtener la máxima seguridad. Las organizaciones con infraestructuras de correo electrónico complejas o servicios de terceros deben evaluar cuidadosamente el riesgo de bloquear correos electrónicos legítimos antes de implementar un hard fail.

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico de PowerDMARC

Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.

Últimos mensajes de Yunes Tarada (ver todos)

• DMARCbis explicado: qué va a cambiar y cómo prepararse - 16 de abril de 2026
• El formato del número de serie de SOA no es válido: causas y cómo solucionarlo - 13 de abril de 2026
• Cómo enviar correos electrónicos seguros en Gmail: guía paso a paso - 7 de abril de 2026