SPF Softfail Vs SPF Hardfail: ¿Cuál es la diferencia?
por
Tiempo de lectura: 5 min
Con SPF (Sender Policy Framework), tiene la flexibilidad de configurar su sistema para responder a los fallos de autenticación de una de estas dos maneras: Hardfail o Softfail. n este blog, vamos a discutir las diferencias entre SPF hardfail y softfail, la sintaxis para configurar ambos, y sus casos de uso. Así que, ¡vamos al grano!
Puntos clave
- SPF hardfail indica que un remitente de correo electrónico no está autorizado, lo que a menudo provoca el rechazo del correo.
- SPF softfail sugiere que el correo electrónico aún puede proceder de un remitente no autorizado, pero no lo rechaza directamente, lo que permite una revisión posterior.
- Implantar políticas SPF estrictas es esencial para evitar la suplantación no autorizada del correo electrónico y proteger la reputación de la marca.
- Combinar SPF con DMARC añade una capa esencial de seguridad, permitiendo una mejor gestión de los fallos de autenticación del correo electrónico.
- Supervisar regularmente los resultados de la autenticación SPF puede ayudar a mantener una postura óptima de seguridad del correo electrónico y evitar posibles vulnerabilidades.
La diferencia entre Softfail y Hardfail de SPF
La tabla que figura a continuación explica la diferencia básica entre SPF hardfail y softfail.
| Sintaxis SPF | Tipo de fallo | Estado | Medida correspondiente adoptada por el destinatario |
|---|---|---|---|
| v=spf1 include:dominio1.es -all | Hardfail | Remitente no autorizado | El correo electrónico puede ser rechazado |
| v=spf1 include:dominio1.es ~all | Softfail | El remitente puede no estar autorizado | El correo electrónico se entrega pero se marca como sospechoso o potencialmente fraudulento |
SPF Hardfail Vs Softfail : Como 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 configurar SPF Softfail, que indica un indicio "probable" de uso no autorizado del dominio.
¡Simplifique el FPS con PowerDMARC!
Gestión de fallos del destinatario en Hardfail y Softfail
En la sección 8.4la RFC define los siguientes escenarios de gestión de resultados para SPF hardfail frente a SPF softfail:
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.
SPF Softfail Vs Hardfail: ¿Qué recomendamos?
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.
¿Y lo peor? La acción tomada por la política de gestión de fallos SPF anulará los resultados de autenticación DMARC y DKIM. Esencialmente, incluso si DKIM y posteriormente DMARC pasan - el correo electrónico todavía puede fallar para ser entregado.
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 de un remitente de 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, podría provocar el rechazo del mensaje antes de que se produzca cualquier política o procesamiento DMARC. Este rechazo prematuro puede ocurrir independientemente de si el correo electrónico podría pasar finalmente la autenticación DMARC.
Por lo tanto, en estas circunstancias, SPF Softfail triunfa sobre el mecanismo Hardfail. Se trata de un enfoque de riesgo considerablemente bajo que deja margen para la revisión al limitarse a marcar los correos electrónicos autorizados en lugar de rechazarlos.
¿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 los ataques no autorizados de suplantación de identidad y phishing. Siguiendo las mejores prácticas, las organizaciones pueden mejorar la seguridad de su correo electrónico y proteger la reputación de su marca. He aquí algunas estrategias y directrices para implantar el 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
Su registro Sender Policy Framework necesita ser mantenido y optimizado para evitar que funcione mal. SPF tiende a romperse cuando sus remitentes autorizados exceden el límite de 10 búsquedas DNS en el lado del receptor. Para mantener un límite de búsqueda óptimo, nuestro SPF alojado alojada es su mejor opción. Ayudamos a los propietarios de dominios a optimizar el SPF con un solo clic, para permanecer por debajo de los límites de búsqueda y anulación y mantener el 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.
La plataforma avanzada de autenticación de dominios y generación de informes PowerDMARC ofrece soluciones SPF y DMARC completas para empresas de todos los tamaños. Regístrese hoy para una prueba gratuita.
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)
- ¿Qué es BIMI? Guía completa sobre los requisitos y la configuración del logotipo BIMI - 21 de abril de 2025
- Reglas de envío de correo masivo para Google, Yahoo, Microsoft y Apple iCloud Mail - 14 de abril de 2025
- Email Salting Attacks: Cómo el texto oculto burla la seguridad - 26 de febrero de 2025
