Defaults.Exposed › Informes

SPF ~all vs -all: softfail o hardfail — qué eligieron 139 millones de registros (2026)

Publicado 2026-07-03

Cifras a 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Todas las cifras son agregadas — nunca publicamos el registro de una empresa concreta. Consulta cómo calificamos.

Todo registro SPF termina en un mecanismo “all” — el veredicto sobre el correo procedente de cualquier lugar que no esté en tu lista — y la mayoría abrumadora de internet ha elegido el suave: el 55,8% de los 139 millones de dominios que publican SPF termina en ~all (softfail), frente al 39,3% que termina en -all (hardfail). Un solo carácter separa “rechaza las falsificaciones” de “probablemente es una falsificación — entrégala de todos modos”. Cuál es la correcta para ti depende de un segundo ajuste que la mayoría de los propietarios nunca configura.

¿Qué le dicen en realidad ~all y -all a un receptor?

• -all (hardfail): “Rechaza el correo de cualquier otro origen.” Un no rotundo.
• ~all (softfail): “El correo de otros orígenes probablemente no sea legítimo — acéptalo, quizá márcalo.” Un encogimiento de hombros.
• ?all (neutral): “Sin opinión.” Elegido por el 3,0% de los publicadores; protección solo de nombre.
• +all: “Cualquiera puede enviar como si fuera yo.” Publicado por 36.014 dominios, y peor que no tener registro — el problema del felpudo de bienvenida tiene su propio informe.

¿Está mal ~all, entonces? Solo si está solo — y casi siempre lo está

El softfail tiene un argumento moderno defendible: las directrices para remitentes de Google, y con ellas la mayor parte de la práctica de entregabilidad, convergen en ~all combinado con una política DMARC que aplique medidas (p=reject). La combinación protege tan bien como -all en todo receptor que evalúa DMARC — que ahora incluye a todos los principales proveedores de buzón — sin rebotar de forma dura el correo legítimo reenviado, la víctima clásica de -all. En esa configuración el encogimiento de hombros tiene fuerza: DMARC aporta el veredicto que SPF se negó a dar.

Pero la combinación es lo esencial, y aquí está lo que añade el censo y que las guías de configuración no pueden: de los 77.484.057 registros softfail que hay en internet, solo 7,1 millones — alrededor de 1 de cada 11 — tienen detrás una política DMARC que aplica medidas. Para los otros 70,4 millones de dominios, ~all es exactamente lo que parece. Su registro identifica la falsificación y la deja pasar con un gesto de la mano.

¿No arreglaron esto los mandatos de 2024?

No — y la distinción importa más de lo que sugiere la mayor parte de la cobertura. Google y Yahoo empezaron a exigir autenticación a los remitentes masivos en febrero de 2024, y Microsoft les siguió en mayo de 2025: SPF o DKIM que pasen y estén alineados, más un registro DMARC como mínimo p=none. Los mandatos no llegan a exigir aplicación — un dominio con ~all, un registro p=none y DKIM alineado cumple por completo, y sigue siendo totalmente suplantable. Los mandatos normalizaron el papeleo, no la protección. Ese punto medio sin aplicación — conforme, publicado, falsificable — es precisamente la brecha que mide este censo, y es la población más numerosa en la seguridad del correo.

Entonces, ¿en qué debería terminar tu registro?

1. Envías correo y el reenvío importa (boletines, listas de correo, alias): ~all con DMARC p=reject detrás — la combinación recomendada más arriba.
2. Envías correo desde una configuración estrictamente controlada: -all funciona y declara la política en el propio registro. Mapea primero a tus remitentes — un final estricto sobre un registro sin mapear rompe correo real, o algo peor.
3. El dominio nunca envía: -all más p=reject, hoy mismo. No existe nada legítimo que proteger, así que no hay nada que romper.

Sea cual sea el final que elijas, la lección de una línea del censo se mantiene: el calificador solo importa tanto como lo que lo hace cumplir. Dónde te sitúas en esa escala es medible.

Preguntas frecuentes

¿Es mejor SPF ~all o -all? Ninguno, de forma universal. ~all con una política DMARC que aplique medidas es el patrón que recomiendan las directrices de Google — igual protección en los receptores que evalúan DMARC sin romper el correo reenviado. -all conviene a remitentes estrictamente controlados. ~all solo — el estado de todos los dominios softfail salvo 1 de cada 11 — es la opción débil.

¿Qué significa SPF softfail? ~all les dice a los receptores que el correo procedente de servidores no listados probablemente sea ilegítimo pero que aun así debe aceptarse, normalmente con recelo. Solo se convierte en protección real cuando una política DMARC actúa sobre el fallo; consulta SPF sin DMARC.

¿Romperá el hardfail -all mi correo reenviado? Puede: el reenvío reexpide tu correo desde el servidor del reenviador, que tu SPF no lista, y un hardfail invita al rechazo antes de que DKIM o DMARC intervengan. Ese riesgo es la razón de ser de la combinación ~all + p=reject.

¿Exigen ahora Google y Microsoft -all? No. Los mandatos para remitentes masivos exigen autenticación que pase y esté alineada y un registro DMARC como mínimo p=none — sin aplicación, sin un calificador concreto. El rechazo por parte de Google del correo masivo no conforme ya está en marcha; Microsoft ha estado enviando los fallos a la carpeta de correo no deseado y avanza hacia el rechazo directo. Cumplir no es proteger.

Comprueba en qué termina tu registro — y qué hay detrás

Dos consultas te dicen ambas cosas, gratis, en 30 segundos. Si eres uno de los 70,4 millones de encogimientos de hombros sin aplicación, la solución es un registro DNS, no una compra.

Comprueba tu dominio → · Arreglar SPF → · Arreglar DMARC → · El modelo de madurez de SPF → · El mapa de +all → · Solo datos agregados. Datos almacenados y procesados en la UE.