La diferencia entre SPF -all y ~all
por
Última actualización: Tiempo de lectura: 8 min
Comprender los mecanismos SPF -all y ~all es fundamental para la autenticación del correo electrónico. Descubra cómo estas terminaciones de registros SPF afectan a la entrega del correo electrónico y cuál elegir para la seguridad de su dominio.
Índice
- SPF -todos vs ~todos
- Explicación de la sintaxis y los mecanismos del registro SPF
- ¿Cómo funcionaba el mecanismo SPF all (Softfail vs Fail) antes de DMARC?
- Cómo simplificar la gestión de registros SPF
- ¿Cómo manejan ahora los proveedores de servicios de correo electrónico el mecanismo SPF -all vs ~all?
- ¿Qué recomendamos? SPF -todos o SPF ~todos
- Errores comunes en los registros SPF y solución de problemas
- Preguntas frecuentes sobre el SPF Todas
Puntos clave
- ~todos y -all ambos indican un fallo del SPF para remitentes no autorizados, pero -all indica una intención de aplicación más estricta.
- Los servidores receptores pueden tratar -all de forma más agresiva que ~all, dependiendo de la política y las señales de reputación.
- Comience con ~all durante la supervisión para reducir el riesgo de rechazar correos electrónicos legítimos mientras confirma todas las fuentes de envío.
- Uso -all solo después de que las fuentes SPF estén completas y los informes DMARC confirmen que no hay lagunas de autenticación.
- DMARC define cómo se gestionan los fallos de autenticación (supervisar, poner en cuarentena o rechazar).
- Una optimización adecuada del SPF ayuda a evitar el límite de 10 búsquedas DNS a medida que crece su infraestructura de correo electrónico.
Comprender el SPF -all vs ~all es una parte importante de la autenticación del correo electrónico, ya que estos mecanismos indican cómo deben tratar los servidores de correo receptores los correos electrónicos enviados desde fuentes no autorizadas. Ambos mecanismos indican un fallo de SPF, pero comunican diferentes niveles de intención de aplicación y pueden influir en cómo se filtra o rechaza el correo en función de la política del destinatario.
El todo el aparece al final de un registro SPF y va precedido de un calificador como – (hardfail) o ~ (softfail). La elección entre uno u otro depende de lo completo que sea su registro SPF y de si está supervisando activamente los resultados de la autenticación mediante DMARC.
Este artículo explica cómo SPF -all y ~all , cómo los interpretan actualmente los proveedores de buzones de correo y cuándo utilizar cada uno de ellos de forma segura sin poner en riesgo la entrega de correos electrónicos legítimos.
| Respuesta rápida: Utiliza ~all al validar remitentes y supervisar con DMARC. Cambie a -all solo cuando SPF esté completo y los informes DMARC no muestren fallos legítimos. |
Explicación de la sintaxis y los mecanismos del registro SPF
Antes de profundizar en las diferencias entre SPF -all y ~all, es fundamental comprender la sintaxis completa del registro SPF y todos los mecanismos disponibles.
Un registro SPF sigue un formato específico que indica a los servidores de correo receptores qué direcciones IP y dominios están autorizados para enviar correos electrónicos en nombre de su dominio.
La sintaxis básica del registro SPF es: v=spf1 [mecanismos] [modificadores] [todos]
Opciones de todos los mecanismos SPF
El mecanismo «all» al final de su registro SPF determina lo que ocurre cuando un correo electrónico no coincide con ninguno de los remitentes autorizados. Estas son las cuatro opciones:
| Mecanismo | Nombre | Resultado | Acción |
|---|---|---|---|
| ¿NOMBRE? | Pasar | APROBADO | Aceptar todos los correos electrónicos (no recomendado) |
| ?todos | Neutral | NEUTRO | No se ha especificado ninguna política. |
| ~todos | Softfail | FALLO LEVE | Marcar como sospechoso pero entregar |
| -todos | Hardfail | FALLO | Rechazar correos electrónicos no autorizados |
Ejemplos de registros SPF
A continuación se muestran ejemplos prácticos de registros SPF que utilizan diferentes mecanismos:
- SPF básico con Softfail: v=spf1 include:_spf.google.com ~all
- Inclusiones múltiples con Hardfail: v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all
- Direcciones IP con Softfail: v=spf1 ip4:192.168.1.0/24 ip6:2001:db8::/32 ~all
- Mecanismos mixtos: v=spf1 a mx include:_spf.google.com ip4:203.0.113.0/24 -all
SPF -todos vs ~todos
Tanto el mecanismo SPF -all como el SPF ~all significan un «NO APROBADO» para la autenticación SPF. En los últimos tiempos, los proveedores de correo electrónico utilizan los resultados de SPF como uno de los muchos datos que tienen en cuenta, y las políticas DMARC y las señales de reputación influyen en gran medida en las decisiones finales sobre la entrega.
Sin embargo, hace unos años no era así.
¿Qué significa v=spf1 -all?
El registro SPF que termina en «-all» (hardfail) indica a los servidores de correo receptores que rechacen cualquier correo electrónico que no provenga de remitentes autorizados incluidos en su registro SPF. Se trata de la política SPF más estricta y ofrece la mayor protección contra la suplantación de identidad en el correo electrónico.
¿Qué significa «todo» en SPF?
El mecanismo «~all» (softfail) indica a los servidores receptores que los correos electrónicos de remitentes no autorizados deben marcarse como sospechosos, pero que deben entregarse al buzón del destinatario, a menudo en la carpeta de correo no deseado.
¿Cómo funcionaba el mecanismo SPF (Softfail vs Fail) antes de DMARC?
DMARC se creó mucho tiempo después de que SPF ya estuviera en el mercado como protocolo de autenticación de correo electrónico estándar. En ese momento, el mecanismo de falla suave de SPF funcionaba de la siguiente manera:
Supongamos que su registro SPF fuera
v=spf1 include:spf.domain.com ~all (donde ~all significa SPF Softfail)
El servidor de correo electrónico del destinatario habría realizado una búsqueda DNS para consultar el DNS del remitente en busca de su registro SPF. Si el dominio de la ruta de retorno del correo electrónico no figuraba en el registro del remitente, el servidor receptor habría devuelto un resultado SPF «NOT PASS», pero habría entregado el correo electrónico en la bandeja de entrada del destinatario.
Ahora supongamos que su registro SPF fuera:
v=spf1 include:spf.domain.com -all (donde -all significa SPF Fail)
El servidor de correo electrónico del destinatario habría realizado una búsqueda DNS para consultar el DNS del remitente en busca de su registro SPF. Si el dominio de la ruta de retorno del correo electrónico no figuraba en el registro del remitente, el servidor receptor habría devuelto un resultado SPF «NOT PASS», pero en este caso, el correo electrónico habría sido rechazado y no se habría entregado en la bandeja de entrada del destinatario.
Más información sobre la historia del Marco de políticas del remitente.
Cómo simplificar la gestión de registros SPF
La gestión de los registros SPF puede resultar compleja a medida que las organizaciones crecen y añaden más servicios de envío de correo electrónico. El límite de 10 búsquedas DNS es un problema habitual que provoca fallos en la autenticación SPF cuando se supera. La solución de gestión automatizada de SPF de PowerDMARC aborda estos retos mediante técnicas de optimización avanzadas.
La tecnología de aplanamiento SPF de PowerDMARC optimiza automáticamente sus registros SPF para mantenerse dentro de los límites de búsqueda de DNS, al tiempo que mantiene una cobertura completa de autenticación de correo electrónico. Esto garantiza que sus correos electrónicos legítimos sigan autenticándose correctamente incluso cuando añada nuevos servicios de correo electrónico y herramientas de marketing.
¡Simplifique el FPS con PowerDMARC!
¿Cómo gestionan ahora los proveedores de servicios de correo electrónico el mecanismo SPF -all frente a ~all?
Los proveedores de servicios de correo electrónico modernos, como Gmail, Outlook y Yahoo, gestionan los mecanismos SPF de forma diferente a como se hacía en la era anterior a DMARC. La mayoría de los principales proveedores se centran ahora en las políticas DMARC en lugar de en los resultados SPF individuales a la hora de tomar decisiones de entrega.
- El enfoque de Gmail: Gmail trata los softfail de SPF (~all) como una señal de autenticación más débil, mientras que considera el hardfail (-all) puede aumentar la sospecha sobre los mensajes que no coinciden con las fuentes de envío autorizadas. Las decisiones finales sobre la entrega dependen de la política DMARC y otras señales de filtrado.
- Gestión de Microsoft Outlook: Outlook.com y Microsoft 365 tienen en cuenta los resultados de SPF como parte de su evaluación de filtrado y autenticación. Un error grave (-all) puede tratarse de forma más estricta que un softfail (~all), pero el manejo final sigue dependiendo de la política DMARC y de señales adicionales.
Aunque actualmente puede utilizar SPF -all o ~all con la mayoría de los proveedores de correo electrónico sin tener que preocuparse por fallos en la entrega de correos electrónicos legítimos, puede darse el caso de que un servidor rechace su correo electrónico si utiliza el atributo -all. Para mayor seguridad, puede evitar utilizar el mecanismo SPF hard fail -all al crear su registro SPF. Para ello, siga estos pasos:
- Abre el generador de registros PowerDMARC generador de registros SPF para empezar a crear un registro de forma gratuita.
- Después de incluir las direcciones IP y los dominios de sus remitentes de correo electrónico, desplácese hasta la última sección designada para indicar al servidor de correo electrónico lo estricto que debe ser al verificar sus correos electrónicos
- Elija la opción "Soft-fail" antes de pulsar el botón "Generar registro SPF"
¿Qué recomendamos? SPF -all o SPF ~all
Utilice SPF ~all (softfail) si:
- Eres nuevo en la autenticación de correo electrónico y deseas minimizar los riesgos de entrega.
- Tu organización añade con frecuencia nuevos servicios de envío de correos electrónicos.
- Aún no ha implementado la supervisión DMARC.
- Estás en una fase de prueba y quieres observar los resultados de la autenticación.
Utilice SPF -all (hardfail) si:
- Tienes DMARC correctamente configurado y supervisado.
- Tu registro SPF incluye todas las fuentes de envío legítimas.
- Quieres la máxima protección contra la suplantación de identidad en el correo electrónico.
- Tu infraestructura de correo electrónico es estable y está bien documentada.
Los problemas de entrega de correo electrónico relacionados con el mecanismo SPF -all pueden ocurrir en muy raras ocasiones. No es un problema recurrente con el que se encuentre a menudo. Para asegurarse de que nunca se encuentre con este problema, puede seguir los siguientes pasos:
- Configurar DMARC para tus correos electrónicos y habilita los informes DMARC.
- Configure su política DMARC en supervisión e inspeccione minuciosamente los resultados de la autenticación SPF para detectar cualquier inconsistencia en la capacidad de entrega del correo electrónico.
- Si todo está bien, puede utilizar el mecanismo -all en su registro SPF. Recomendamos utilizar el atributo hard fail ya que afirma que está seguro de la autenticidad de sus correos electrónicos, lo que puede impulsar la reputación de su dominio
Si no está seguro de utilizar el SPF -all, puede seguir estos pasos:
- Configure un registro SPF utilizando el mecanismo ~all
- Configure DMARC para tus correos electrónicos y habilita los informes DMARC.
- Establezca su política DMARC para rechazar
Cómo solucionar errores comunes en los registros SPF
Los errores SPF suelen clasificarse en cuatro categorías: registro faltante, registro duplicado, registro no válido o fallos en las búsquedas DNS. Utilice la etiqueta de error que aparece a continuación para identificar rápidamente la solución.
Los errores comunes de SPF incluyen:
- SPF PermError: Su registro SPF no es válido. Esto suele ocurrir debido a errores de sintaxis o porque el registro supera el límite de 10 búsquedas DNS (por ejemplo, demasiados mecanismos de inclusión ).
- SPF TempError: un problema temporal de resolución de DNS (tiempos de espera agotados, fallos transitorios de DNS). Es posible que se resuelva por sí solo, pero los errores temporales repetidos suelen indicar problemas de inestabilidad del DNS o del servidor de nombres.
- SPF Ninguno: No se ha encontrado ningún registro SPF para el dominio que se está comprobando. Esto suele significar que SPF no se ha publicado, se ha publicado en un dominio incorrecto o el DNS no se ha propagado.
- Múltiples registros SPF: existe más de un registro SPF TXT para el mismo dominio, lo que interrumpe la evaluación SPF y suele provocar errores de autenticación.
Si ves con frecuencia «No se ha encontrado ningún registro SPF», significa que el servidor receptor devolvió un resultado nulo al consultar el DNS en busca de su registro SPF TXT. Esto puede deberse a un registro que falta, a que se está comprobando un dominio incorrecto (Return-Path frente a From) o a problemas de publicación/propagación del DNS. (Enlace a su artículo «No se ha encontrado ningún registro SPF» aquí).
Si tiene DMARC configurado junto con SPF, los servidores receptores también evaluarán su política DMARC para decidir cómo tratar los mensajes que no superen la autenticación. Según su política, los mensajes rechazados pueden entregarse, ponerse en cuarentena o rechazarse. Una política de rechazo DMARC puede reducir significativamente los ataques de suplantación de identidad, como el spoofing y el phishing, al indicar a los receptores que bloqueen el correo no autenticado.
La supervisión SPF de PowerDMARC le ayuda a detectar estos errores de forma temprana, señalando los problemas de autenticación, revelando la causa raíz y guiándole a través de las soluciones antes de que se vea afectada la capacidad de entrega.
Preguntas frecuentes
¿Qué significa v=spf1 -all?
El registro SPF «v=spf1 -all» significa que solo las direcciones IP y los dominios que figuran explícitamente en el registro SPF están autorizados a enviar correos electrónicos para su dominio. Cualquier correo electrónico procedente de fuentes no autorizadas será rechazado (hardfail). Se trata de la política SPF más estricta y proporciona la máxima protección contra la suplantación de identidad en el correo electrónico.
¿Cuál es la diferencia entre SPF y DKIM?
SPF (Sender Policy Framework) valida que los correos electrónicos provienen de direcciones IP autorizadas, mientras que DKIM (DomainKeys Identified Mail) utiliza firmas criptográficas para verificar la integridad y autenticidad del correo electrónico. SPF comprueba el servidor de envío, mientras que DKIM comprueba que el contenido del correo electrónico no haya sido manipulado durante el tránsito.
¿El SPF es igual en todos los proveedores de correo electrónico?
No, los distintos proveedores de correo electrónico pueden interpretar los resultados de SPF de forma diferente. Aunque la mayoría de los proveedores modernos siguen estándares similares, algunos pueden ser más indulgentes con los resultados de softfail (~all), mientras que otros aplican estrictamente las políticas de hardfail (-all). DMARC ayuda a estandarizar estos comportamientos entre los distintos proveedores.
¿Qué hace +all en SPF?
El mecanismo «+all» en SPF significa «pasar todo»: permite que cualquier dirección IP envíe correos electrónicos en nombre de su dominio. Esto no es recomendable, ya que no ofrece protección contra la suplantación de identidad por correo electrónico y, en esencia, hace que su registro SPF sea ineficaz.
¿Debo usar SPF -all o ~all para mi dominio?
Comience con ~all (softfail) mientras sigue confirmando todas las fuentes de envío legítimas o su configuración está cambiando. Cambie a -all (hardfail) solo después de que su registro SPF esté completo y los informes DMARC muestren que los correos electrónicos legítimos no están fallando en la autenticación, para que pueda aplicar una protección más estricta con menor riesgo.
¿Cómo puedo solucionar los errores de autenticación SPF?
Las soluciones habituales incluyen: añadir direcciones IP o dominios que faltan a su registro SPF, reducir las búsquedas DNS para mantenerse por debajo del límite de 10 búsquedas, eliminar registros SPF duplicados y garantizar la sintaxis adecuada del registro SPF. La gestión automatizada de SPF de PowerDMARC puede ayudar a resolver estos problemas de forma automática.
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)
- Nivel de confianza de spam (SCL) -1 Bypass: qué significa y cómo gestionarlo - 4 de marzo de 2026
- «No supera la verificación DMARC y tiene una política DMARC de rechazo»: qué significa y cómo solucionarlo - 26 de febrero de 2026
- 550 La dirección del remitente infringe la política de mayúsculas y minúsculas en los nombres de usuario: causas y soluciones - 11 de febrero de 2026
