«Hard Fail» y «Soft Fail» en SPF: ¿Cuál es la diferencia?

Los resultados del SPF pueden parecer sencillos hasta que una decisión sobre la política empieza a afectar al filtrado, a la resistencia a la suplantación de identidad y a los resultados de entrega. En esta guía se explica qué significan los términos «fallo grave» y «fallo leve» en el contexto del SPF, en qué se diferencian, cuándo conviene utilizar cada uno de ellos y por qué el SPF funciona mejor como parte de una estrategia más amplia de autenticación del correo electrónico.

¿En qué consiste un fallo del SPF?

SPF comprueba si un servidor de correo está autorizado a enviar correos electrónicos en nombre de un dominio. En esta sección se explica cómo se produce un fallo de SPF y qué significan, por lo general, los resultados más habituales de la autenticación.

Cómo se produce el fallo del SPF

El SPF ( Sender Policy Framework) funciona comparando la dirección IP del remitente con el registro SPF publicado en el DNS para el dominio. Se produce un error de SPF cuando el servidor receptor no puede confirmar que la dirección IP remitente esté autorizada para el dominio utilizado en el campo «Mail From» de la norma RFC 5321, también conocido como «return-path».

Esa distinción es importante porque el SPF no siempre se evalúa en función de la dirección «De» visible que aparece en la bandeja de entrada. Un mensaje puede parecer legítimo para el destinatario y, sin embargo, no superar la verificación SPF debido al dominio de la ruta de retorno.

Resultados habituales de la autenticación SPF

Los resultados de la autenticación SPF pueden variar. Es posible que aparezca el siguiente mensaje:

• SPF válido: El servidor remitente está autorizado por el registro SPF del dominio, por lo que la autenticación SPF se ha realizado con éxito.
• SPF ausente: No se ha publicado ningún registro SPF para el dominio, por lo que el servidor receptor no tiene nada que evaluar.
• neutro: El dominio no indica claramente si el remitente está autorizado o no, por lo que el resultado no es concluyente.
• Error leve de SPF: Es probable que el remitente no esté autorizado, pero el dominio no solicita a los destinatarios que rechacen el mensaje de forma inmediata.
• Error grave de SPF: El remitente no está autorizado según el registro SPF, y el dominio está aplicando una política más estricta con respecto al mensaje.
• Error de SPF: No se ha podido comprobar el SPF en su totalidad debido a un problema temporal, como un tiempo de espera de DNS agotado o un error en la consulta.
• permerror: No se ha podido evaluar el SPF debido a un problema permanente en el registro SPF, como una sintaxis incorrecta o un número excesivo de consultas DNS.

Algunos resultados apuntan a un verdadero problema de autorización, mientras que otros indican la ausencia de políticas, políticas deficientes, problemas de sintaxis en el SPF o problemas relacionados con el DNS.

Por eso es recomendable comprobar el resultado exacto del SPF antes de proceder a la resolución de problemas. El resultado concreto suele indicar si el problema se debe a un remitente no autorizado, a la falta de un registro, a un fallo general del SPF o a un problema relacionado con un registro o una consulta.

Fallo grave (Hard Fail) frente a fallo leve (Soft Fail) en el SPF

Ambos resultados indican que el SPF no ha confirmado que la fuente de envío estuviera autorizada. La diferencia radica en el grado de insistencia con el que el propietario del dominio desea que los sistemas receptores interpreten dicho fallo.

Diferencias sintácticas

La diferencia técnica se aprecia ya en el propio registro SPF:

• El «soft fail» utiliza «~all»
• Error grave al utilizar la opción -all

Ese único carácter modifica la señal que el dominio envía a los sistemas receptores.

Diferencias semánticas

Un «error suave» significa que el dominio indica que es probable que el remitente no esté autorizado. Esto pone de manifiesto cierta preocupación, pero no constituye una declaración política lo suficientemente firme como para rechazarla basándose únicamente en el SPF.

Un «error grave» significa que el dominio indica que el remitente no está autorizado. Esta es la postura normativa más estricta y refleja una mayor confianza en que los flujos de correo legítimos ya están contemplados en el registro SPF.

Situación actual y objetivo de la política

Tanto el «soft fail» como el «hard fail» son resultados de fallo del SPF, pero «spf softfail» y «spf hardfail» reflejan una intención diferente en la política. El «soft fail» se utiliza a menudo cuando una organización aún está verificando todas las fuentes de envío o desea evitar rechazos erróneos mientras depura su inventario de remitentes. 

El «hard fail» resulta más adecuado cuando el propietario del dominio tiene una mayor confianza en la cobertura del SPF y está dispuesto a adoptar una postura más firme frente al correo electrónico no autorizado.

Cómo los tratan los sistemas receptores

En la práctica, los mensajes de error leve suelen aceptarse, aunque se filtran, se marcan o se redirigen con mayor precaución. Los mensajes con errores graves tienen más probabilidades de ser rechazados, puestos en cuarentena o recibir una puntuación más baja en el conjunto de medidas de seguridad del correo electrónico.

Estas diferencias son importantes porque un modo de fallo incorrecto puede provocar, bien dificultades innecesarias en la entrega, bien una exposición innecesaria a la suplantación de identidad.

¿Qué modo de fallo del SPF debería utilizar?

El modo de fallo adecuado del SPF depende de lo completo que sea su inventario de remitentes y del nivel de riesgo de entrega que su organización esté dispuesta a aceptar. En los apartados siguientes se explica en qué casos el «soft fail» suele ser la opción más segura y en cuáles resulta más práctico el «hard fail».

Cuándo utilizar un «soft fail»

Si su organización aún no tiene la certeza de que todas las fuentes de envío legítimas estén incluidas en el registro SPF, «~all» suele ser la opción más segura para empezar. Esto reduce la probabilidad de rechazar correos electrónicos legítimos mientras lleva a cabo el inventario de remitentes y la limpieza del SPF.

Esto resulta especialmente útil durante las transiciones entre plataformas, cuando se incorporan herramientas SaaS de terceros o cuando distintas unidades de negocio gestionan diferentes flujos de correo. En esos casos, una política de «fallo suave» ofrece a los equipos margen para analizar los resultados de la autenticación SPF sin pasar inmediatamente a una postura estricta de «fallo duro».

Cuándo utilizar «Hard Fail»

El cambio a -all tiene más sentido una vez que las fuentes de envío legítimas se hayan documentado y validado por completo. Esto incluye la infraestructura interna de correo, los servicios de correo electrónico en la nube y los remitentes externos.

Una vez que la cobertura del SPF sea completa y estable, una política de rechazo absoluto puede ofrecer una mayor resistencia a la suplantación de identidad con un menor riesgo de rechazo erróneo. Para la mayoría de las organizaciones, la opción más práctica consiste en comenzar con un «soft fail» mientras se sigue verificando la cobertura del SPF, para pasar al «hard fail» únicamente cuando se tenga un alto grado de confianza en el registro.

Casos de uso habituales de los errores «hard fail» y «soft fail» de SPF

El caso de uso adecuado suele depender del grado de exhaustividad y estabilidad de su cobertura SPF. El «soft fail» suele resultar más práctico durante las fases de limpieza y detección, mientras que el «hard fail» resulta más adecuado una vez que las fuentes de envío están estrictamente controladas.

Casos en los que es habitual que se produzca un «fallo suave»

Los fallos leves son habituales durante los períodos de transición. Las organizaciones suelen utilizar «~all» mientras siguen identificando remitentes externos, actualizando mecanismos SPF obsoletos o consolidando los servicios de correo electrónico tras cambios de proveedor o de infraestructura.

Además, resulta adecuado para dominios con ecosistemas de remitentes complejos. Si varias plataformas SaaS, departamentos o sistemas regionales envían mensajes en nombre del mismo dominio, puede resultar más complicado mantener el SPF perfectamente actualizado en todo momento. En esos entornos, el «soft fail» ofrece una forma menos disruptiva de supervisar y perfeccionar la política SPF.

Donde son frecuentes los fallos graves

Los errores graves son más habituales en entornos de envío sometidos a un control estricto. Si un dominio envía mensajes únicamente a través de Microsoft 365, únicamente a través de Google Workspace o a través de otra plataforma estrictamente regulada con una infraestructura de remitentes bien documentada, resulta más sencillo gestionar todo ello de forma segura.

Además, resulta adecuado para organizaciones en las que la seguridad es una prioridad, que cuentan con un sistema de gestión de remitentes bien consolidado y una baja tolerancia al riesgo de suplantación de identidad. En esos entornos, una política de SPF más estricta contribuye a que los correos electrónicos no autorizados resalten con mayor claridad ante los sistemas receptores.

Estrategias para garantizar una implementación segura del SPF

El SPF funciona mejor cuando se gestiona como un control continuado, y no como una tarea puntual relacionada con el DNS. Las siguientes prácticas ayudan a reducir los errores de configuración y a mantener la política SPF en consonancia con el flujo real de correo.

Utilice una herramienta generadora de registros SPF

Una herramienta de comprobación o generación de registros SPF puede ayudar a los equipos a crear registros más limpios, comprobar la sintaxis de los registros SPF y detectar problemas antes de que los cambios entren en vigor. Esto resulta especialmente útil durante la limpieza del SPF, las migraciones de plataforma o la incorporación de remitentes.

Utilice mecanismos de SPF adecuados

Cada mecanismo SPF debe corresponder a una fuente de envío real. El uso excesivo de la directiva «include», el hecho de dejar entradas obsoletas sin eliminar o la autorización de rangos de direcciones IP demasiado amplios pueden debilitar la política y aumentar la complejidad a la hora de resolver problemas.

Mantenimiento y optimización del registro SPF

Los registros deben ser concisos. Elimine los remitentes obsoletos, evite las inclusiones anidadas innecesarias y preste atención al límite de consultas DNS. Si la evaluación del SPF requiere demasiadas consultas DNS, puede devolver un «permerror» en lugar de un resultado de autorización correcto. 

Asimismo, es importante evitar los registros SPF múltiples, ya que publicar más de una política SPF para el mismo host puede generar problemas de validación en lugar de un resultado correcto.

Aplique las políticas de gestión de fallos con cautela

La elección entre «soft fail» y «hard fail» debe reflejar la cobertura real de los remitentes. Una política más estricta no es necesariamente mejor si los datos disponibles son incompletos. La política de SPF más eficaz es aquella que se ajusta al flujo real de correo.

Supervisar los resultados de la autenticación SPF

El análisis de los resultados de la autenticación SPF a lo largo del tiempo ayuda a los equipos a detectar desviaciones, remitentes que no se detectan y errores de configuración antes de que se conviertan en problemas más graves de entregabilidad, especialmente cuando se cuenta con el apoyo de una herramienta de generación de informes DMARC. La realización periódica de comprobaciones del SPF también facilita la detección de fallos recurrentes en el SPF antes de que se conviertan en problemas más graves relacionados con la autorización de los remitentes.

Combine SPF con DMARC

El SPF por sí solo no es suficiente. DMARC aporta alineación y aplicación de políticas, lo que hace que SPF resulte más relevante en entornos de producción en los que la resistencia a la suplantación de identidad es fundamental. Estas prácticas recomendadas ayudan a las organizaciones a utilizar el SPF como parte de una estrategia de autenticación más sólida y completa.

Por qué es posible que el SPF no sea suficiente

El SPF resulta útil, pero por sí solo no resuelve todos los problemas de autenticación del correo electrónico. Las principales limitaciones que se exponen a continuación explican por qué funciona mejor como parte de una estrategia más amplia.

El reenvío puede seguir afectando a la validación del SPF

Una de las mayores limitaciones es el reenvío. Un mensaje reenviado puede seguir siendo legítimo, pero el SPF puede dar un resultado negativo porque la dirección IP del servidor de reenvío no está autorizada en el registro SPF del dominio original. Si el registro TXT correspondiente del DNS no tiene en cuenta esa ruta, el reenvío puede seguir provocando un error en el SPF, incluso cuando el origen del mensaje original fuera legítimo.

El SPF no valida la dirección del remitente visible

El SPF comprueba la dirección IP de origen comparándola con el dominio «envelope-from», que no siempre coincide con la dirección «De» visible para el usuario. Esto significa que el SPF por sí solo no resuelve por completo los problemas relacionados con la identidad del remitente y la alineación.

SPF funciona mejor junto con DKIM y DMARC

Por ello, el SPF debe considerarse como un elemento más dentro de una estrategia más amplia de autenticación y cumplimiento de la norma PCI DSS. DKIM añade una firma criptográfica, mientras que DMARC incorpora normas de alineación y la aplicación de políticas, lo que contribuye a reducir el riesgo de una configuración incorrecta de DMARC. En conjunto, estas medidas ofrecen una protección mayor que la que puede proporcionar el FPS por sí solo.

Cómo elegir el modo de fallo SPF adecuado con mayor seguridad

La diferencia entre un «hard fail» y un «soft fail» en el SPF se reduce a la intención de la política, la confianza en el remitente y la tolerancia al riesgo. Las señales de error leve suelen indicar que se trata de un correo no autorizado y suelen resultar útiles durante las tareas de limpieza y detección. Las señales de error grave indican sin lugar a dudas que se trata de un correo no autorizado y se ajustan mejor una vez que la cobertura del SPF sea completa y esté estrictamente controlada.

La estrategia más eficaz consiste en fomentar la confianza en la cobertura del SPF antes de pasar a un rechazo definitivo y, a continuación, reforzar esa política con DKIM y DMARC para lograr una mayor coherencia y protección. Para aquellas organizaciones que necesiten una mayor visibilidad de SPF, DKIM y DMARC en todas las fuentes de envío, Mimecast puede ayudar a reducir los errores de configuración y reforzar la protección en todo el entorno de correo electrónico en general.