SPF -all o ~all: qué diferencia hay y cuál elegir

Qué hacen con él los destinatarios

La teoría solo vale por su efecto práctico. Ante un mensaje cuya IP no está autorizada:

• con -all, el destinatario tiene una señal clara para rechazar o filtrar con dureza;
• con ~all, tiene una señal blanda: la mayoría de los servidores no rechazan ante un softfail solo, lo usan como un indicio entre otros (a menudo para empujar hacia el spam, no para bloquear);
• con ?all, no tiene ninguna señal aprovechable;
• con +all, tiene una señal… que valida al suplantador. Catastrófico.

Quédate con lo esencial: -all es la única cualificación que dice firmemente «lo que no está en mi lista no soy yo».

-all vs ~all: el verdadero debate

¿Por qué tantos dominios permanecen en ~all cuando -all es el objetivo? Por miedo, exactamente igual que con la subida de política DMARC. Mientras un equipo no está seguro de haber listado todas sus fuentes de envío legítimas, pasar a -all le hace temer bloquear su propio correo (una plataforma olvidada, una nueva herramienta). El ~all es entonces un compromiso: señala rigor sin arriesgar el rechazo franco.

Ese compromiso es aceptable en transición, mientras se inventarían y alinean las fuentes. Pero no debe convertirse en un estado permanente: un dominio bloqueado eternamente en ~all se parece a un dominio bloqueado en p=none, documenta una buena intención sin llegar al final de la protección. El objetivo sigue siendo -all.

El error fatal: +all

Una palabra firme sobre +all, porque se cruza más a menudo de lo que debería, generalmente por accidente, un copia-pega desafortunado o una mala comprensión. +all significa «cualquier IP está autorizada a emitir para mi dominio». Transformas tu SPF, que debería restringir, en una autorización universal. Cualquier spammer o suplantador pasa entonces tu SPF. Es estrictamente peor que no tener SPF en absoluto, porque da un falso aval. Si ves +all en un registro, corrígelo de inmediato: es una puerta abierta de par en par.

La interacción con DMARC cambia las reglas

Aquí está el matiz que muchos artículos pasan por alto. Cuando DMARC está implementado y aplicado, es la política DMARC (p=quarantine, p=reject) la que decide la suerte del correo no autenticado, no directamente el cualificador SPF. DMARC se apoya en la alineación (SPF o DKIM alineado con tu From:), y es tu política la que dispone.

Consecuencia: para un dominio en p=reject con una alineación limpia, el debate -all vs ~all se vuelve menos crítico, porque DMARC decide de todas formas. Pero eso no significa que el cualificador ya no importe:

• no todos los destinatarios aplican DMARC: un SPF en -all protege también ante esos;
• un SPF riguroso es una señal de reputación coherente con tu política DMARC;
• mantener ~all «porque DMARC hace el trabajo» es una relajación inútil: si conoces tus fuentes, más vale afirmarlo.

La buena higiene consiste, pues, en apuntar a -all y p=reject: las dos capas se refuerzan, no se sustituyen. El camino hacia esa doble rigurosidad se describe en alcanzar p=reject sin romper tus emails.

Un ejemplo concreto

Imagina dos dominios idénticos en cuanto a fuentes, pero uno en ~all y el otro en -all. Un atacante suplanta su From: desde un servidor cualquiera.

• En el dominio ~all: un destinatario sin DMARC ve un softfail y, según su política antispam, puede aun así entregar el mensaje (en bandeja o en spam). La suplantación tiene una posibilidad de pasar.
• En el dominio -all: el mismo destinatario tiene una señal franca de fallo SPF, y el rechazo es mucho más probable.

Añade DMARC en p=reject en ambos lados, y la suplantación se rechaza en los dos casos, pero el dominio -all sigue mejor protegido ante los destinatarios que no aplican DMARC. El -all nunca es un lastre; solo tiene inconveniente si tus fuentes están incompletas.

Cómo pasar de ~all a -all sin riesgo

El método es el mismo que para endurecer DMARC, y se apoya en los datos:

1. Inventaría todas tus fuentes de envío a partir de tus informes agregados: revelan cada IP que emite en tu nombre.
2. Asegúrate de que todas están en tu SPF (o alineadas en DKIM), sin superar el límite de las diez resoluciones.
3. Cambia a -all una vez que estés seguro de que nada legítimo cae fuera de la lista.
4. Vigila unos días: ninguna fuente legítima debe fallar de repente.

Mientras el paso 1 no esté hecho con serenidad, quédate en ~all, pero con el objetivo claro de cambiar.

El caso de los dominios que no envían

Un caso merece mención aparte: los dominios desde los que no emites ningún correo —dominios aparcados, dominios de marca defensivos, antiguos dominios conservados—. Para ellos, la cualificación terminal no es un compromiso, es una evidencia: publica v=spf1 -all, sin el más mínimo mecanismo antes. Declaras así que ningún servidor está autorizado a emitir en su nombre, lo cual es exactamente cierto, puesto que no envías. Combinado con un DMARC p=reject (y, con DMARCbis, con np=reject para los subdominios inexistentes), es la configuración más estricta y la más fácil de mantener, porque no exige ningún mantenimiento: no hay ninguna fuente que seguir.

Es tanto más importante cuanto que los dominios dormidos son objetivos privilegiados de suplantación, precisamente porque nadie los vigila. A un atacante le encanta un dominio de marca que posees pero que has olvidado proteger. El v=spf1 -all es tu primera línea de defensa, gratuita y definitiva. No dejes ningún dominio que poseas sin esa línea: es uno de los gestos de seguridad con mejor relación esfuerzo/beneficio que existen, y se pone en un minuto.

Verificar tu cualificador

Un vistazo rápido basta para saber dónde estás. Nuestro analizador gratuito lee tu registro, te indica tu cualificación terminal y señala las configuraciones peligrosas como +all. Para el detalle de los controles, ve cómo verificar tu registro SPF. Y si tu SPF devuelve un error en lugar de un simple resultado, ve el PermError, qué significa.

Preguntas frecuentes

¿Puede -all bloquear correo legítimo? Solo si una fuente legítima no está listada en tu SPF (y no alineada en DKIM). Por eso se cambia a -all después de inventariar y listar todas las fuentes, no antes.

Si tengo DMARC en p=reject, ¿importa aún el cualificador? Menos, pero sí. DMARC decide para los destinatarios que lo aplican; -all protege además ante los que no lo aplican, y sigue siendo una señal de rigor coherente.

¿Es ~all «más seguro» que -all? Más seguro para ti a corto plazo (menos riesgo de bloquear tu propio correo si tu inventario está incompleto), pero menos protector contra la suplantación. Es un compromiso de transición, no un objetivo.

¿Por qué mi proveedor recomienda ~all? A menudo por prudencia, para no arriesgarse a romper el correo de clientes cuyo inventario de fuentes es incierto. Es defendible al arrancar, pero no te impide apuntar a -all una vez que dominas tu parque.

¿Qué hacer si encuentro ?all? Considerarlo casi equivalente a no tener SPF útil, y sustituirlo por ~all (transición) y después -all. ?all no afirma nada y no aporta ninguna protección.

Deja que Thomas asegure tu cualificación

Saber si puedes pasar a -all sin romper tu correo supone conocer todas tus fuentes. Thomas, tu CISO virtual, las nombra a partir de tus informes, comprueba que todas están cubiertas por SPF o DKIM, y te dice el momento preciso para cambiar a -all sin riesgo, y te avisa si un +all o un ?all peligroso ronda por tu registro.

Analiza tu dominio gratis → o crea una cuenta para pasar a -all con confianza.