El mecanismo neutro del FPS "todo" es un mecanismo de los registros del Marco de directivas del remitente (SPF) que da lugar a una evaluación neutral. Ordena a los servidores receptores que no tomen una decisión de aprobado o suspenso basándose en SPF.
- Ejemplo de registro SPF con ?all:
v=spf1 include:_spf.google.com ?all
En este ejemplo, el dominio incluye la configuración SPF de Google pero termina con `?all`, que indica a los servidores receptores que adopten una postura neutral con respecto a otros remitentes. No los aprueba ni los rechaza, no ofrece un juicio claro.
Aunque técnicamente válido, `?all` puede crear una ambigüedad que debilite la confianza, dificulte la aplicación de DMARC y pueda dar lugar a problemas de entrega si se utiliza incorrectamente.
Puntos clave
- El mecanismo neutral SPF no especifica claramente si un correo electrónico es legítimo o no.
- El mecanismo ?all puede seguir siendo útil en algunos casos, como para pruebas y configuraciones heredadas.
- Sin embargo, cuando se utiliza en producción, puede crear ambigüedad para los servidores de correo.
- No se recomienda utilizar el mecanismo SPF neutral en producción, ya que puede facilitar la suplantación de identidad y provocar fallos de autenticación y entrega de correo electrónico.
- Para mejorar la seguridad del correo electrónico de tu dominio, se recomienda sustituir el mecanismo ?all por el softfail (es decir, ~all).
SPF Mecanismo neutral (?todos) frente a otros mecanismos
"El propietario del dominio ha declarado explícitamente que no puede o no quiere afirmar si la dirección IP está autorizada o no. Un resultado "Neutral" DEBE tratarse exactamente igual que el resultado "Ninguno"; la distinción sólo existe a efectos informativos. Tratar "Neutral" con más dureza que "Ninguno" desanimaría a los propietarios de dominios a probar el uso de registros SPF." - RFC 4408
Los "?todos"difiere de otros calificadores SPF porque no proporciona un resultado de pasa/no pasa, lo que puede dificultar la evaluación DMARC y la toma de decisiones del servidor de correo.
El "?todos" puede confundir a los servidores de correo receptores, que no sabrán si deben confiar en el correo electrónico o no. La siguiente tabla ofrece un resumen conciso de los efectos y casos de uso de los distintos mecanismos.
Mecanismo | Efecto | Caso práctico |
---|---|---|
?todo (mecanismo neutro) | Neutral - sin juicio de aprobado o suspenso | Raramente utilizado y no recomendado. A veces se utiliza durante las configuraciones de transición. |
~todos (enfoque recomendado) | Suspenso leve - marca como sospechoso | Se utiliza durante el despliegue de SPF, ya que señala a los remitentes no autorizados sin bloquearlos, lo que permite a DMARC aplicar políticas sin arriesgarse a falsos positivos. |
-todos | Hard fail - puede ser rechazado por los servidores de correo | Se utiliza para una aplicación estricta y una fuerte seguridad. Utilícelo con precaución. Asegúrese de que su registro SPF está completo antes de aplicar -all para evitar rechazar correos legítimos. |
Cuándo utilizar el mecanismo neutro del FPS
El mecanismo neutral SPF no se recomienda para la mayoría de las configuraciones modernas de correo electrónico. Puede seguir utilizándose en algunos casos, pero con precaución y planificando con antelación la transición a mecanismos más seguros.
Sistemas heredados
Es posible que algunas infraestructuras y sistemas antiguos no dispongan de políticas de remitente claras o de una gestión SPF adecuada. En tales casos, necesitará una postura neutral, como con el mecanismo neutral SPF, para mantener la funcionalidad.
Fase de pruebas
También puede utilizar este mecanismo durante la implementación inicial del SPF. Permitirá a los propietarios de dominios supervisar el tráfico de correo electrónico manteniendo intacta la entrega, por lo que es seguro utilizarlo como punto de partida.
Casos excepcionales
A veces, otros mecanismos como ~all o -all pueden causar problemas inesperados de entregabilidad. Para diagnosticar estos problemas, puede utilizar temporalmente el mecanismo ?all.
⚠️ Los mecanismos del SPF se evalúan secuencialmente, y colocar ?all antes que otros mecanismos puede hacer que la evaluación del SPF se detenga antes de tiempo, eludiendo potencialmente las comprobaciones previstas.
¿Cuáles son los riesgos de usar ?all
El mecanismo "todos" impide obtener resultados de autenticación claros, lo que socava tanto la seguridad del correo electrónico (por ejemplo, la protección contra la suplantación de identidad) como la entregabilidad del mismo. Los posibles riesgos incluyen:
Falsificación del correo electrónico
Dado que ?all devuelve un resultado neutro, no proporciona ninguna defensa contra la suplantación de identidad. Por el contrario, ~all y -all devuelven señales de error identificables. Cuando se combinan con una política DMARC aplicada, estas señales permiten a los servidores receptores poner en cuarentena o rechazar correos electrónicos no autorizados.
Conflictos DMARC
Los resultados SPF neutrales de "todos" aún pueden alinearse técnicamente con DMARC si los dominios coinciden, pero no proporcionan ninguna señal de aprobado/desaprobado, que DMARC requiere para tomar medidas de aplicación.
Problemas de entregabilidad
Algunos servidores de correo interpretan el mecanismo ?all (neutral) de SPF como una política débil o no comprometida. Esto puede indicar una aplicación deficiente de la identidad del remitente, lo que puede reducir la confianza. Los proveedores de correo como Gmail utilizan múltiples señales, y una política SPF débil puede ser solo uno de los muchos factores.
Cómo sustituir ?all por ~all o -all
Para mejorar la postura de seguridad del correo electrónico de tu dominio, debes sustituir el mecanismo ?all por otro más definitivo. Estos son los principales pasos que deberás seguir en el proceso.
1. Audite su registro SPF actual
Utilice el comprobador SPF para comprobar su configuración actual. Si no tiene un registro, nuestro generador gratuito de generador SPFr gratuito le ayudará a crear uno adaptado a sus fuentes de envío.
2. Sustituir ?all por ~all
El mecanismo de fallo suave (~all) es un enfoque prudente y práctico. DMARC con p=reject aún puede rechazar correos electrónicos basados en SPF ~all si falla la comprobación SPF (~all activa "fail").
3. Supervisar los informes DMARC
También es importante realizar un seguimiento regular de la actividad del correo electrónico mediante informes agregados DMARC. El analizador de informes DMARC ofrece informes DMARC fáciles de usar y en tiempo real para ayudarle a mantenerse informado y seguro.
Errores comunes del mecanismo neutral del FPS
Si utiliza mal el mecanismo "todo", es probable que experimente brechas de seguridad no deseadas y problemas de entregabilidad. Estos son algunos errores frecuentes que debes evitar.
Error 1: Utilizar "todo" en la producción
Las políticas neutrales no ofrecen protección. Esto permite que los mensajes falsos parezcan legítimos. Como resultado, tanto su reputación como la seguridad de sus destinatarios pueden estar en peligro.
Error 2: Combinar "todo" con políticas DMARC estrictas
Una política DMARC como p=reject depende de que SPF (o DKIM) proporcione un claro aprobado o suspenso. Con un SPF neutro, DMARC no sabrá qué hacer, y puede producirse un fallo DMARC innecesario.
Error 3: Suponer que "todo" equivale a "todos".
~all al menos señala a los remitentes no autorizados. El mecanismo "todos", por otro lado, no proporciona ningún juicio en absoluto. Muchos confunden los dos, y por lo tanto experimentan problemas de autenticación y entrega de correo electrónico.
Preguntas frecuentes
1. ¿Es lo mismo que no tener registro SPF?
No. ?todo indica una postura neutral. Sin registro SPF, por otro lado, no proporciona ninguna orientación. Los servidores de correo los tratan de forma diferente.
2. ¿Puedo utilizar ?all con DMARC?
Técnicamente sí, pero se desaconseja. DMARC se basa en resultados claros de SPF pasa/no pasa para su aplicación. El uso de "todo" a menudo da lugar a resultados neutros, lo que reduce la eficacia de DMARC.
Reflexiones finales
El mecanismo ?all de los registros SPF puede parecer inofensivo a primera vista, pero puede ser peligroso. No se recomienda en la práctica y puede exponer su dominio a la suplantación de identidad y reducir la eficacia de las políticas DMARC.
Si actualmente utilizas ?all, planea sustituirlo por ~all (soft fail) para una mayor seguridad y una autenticación de correo electrónico más fiable.
Para una fiabilidad SPF a largo plazo, simplifique la gestión y evite los límites de búsqueda de DNS con PowerDMARC's SPF alojado solución. Está diseñada para gestionar registros complejos y optimizarse automáticamente para proporcionar autenticación de dominios sin errores.
- Explicación del mecanismo neutro del FPS: Cuándo y cómo utilizarlo - 23 de junio de 2025
- Fallos en la alineación de dominios DKIM - Correcciones RFC 5322 - 5 de junio de 2025
- Explicación de DMARCbis: qué cambia y cómo prepararse - 19 de mayo de 2025