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.

Lo esencial cabe en una frase: -all es la única cualificación que dice firmemente «lo que no está en la 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 este dominio». El SPF, que debería restringir, se transforma en una autorización universal. Cualquier spammer o suplantador lo pasa entonces sin esfuerzo. Es estrictamente peor que no tener SPF en absoluto, porque da un falso aval. Un +all localizado en un registro se corrige 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 el From:), y es la política publicada 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 la política DMARC;
• mantener ~all «porque DMARC hace el trabajo» es una relajación inútil: cuando las fuentes se conocen, 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 los emails.

Un ejemplo concreto

Imaginemos 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.

Con DMARC en p=reject en ambos lados, 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 el inventario de las fuentes está incompleto.

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. Inventariar todas las fuentes de envío a partir de los informes agregados: revelan cada IP que emite en nombre del dominio.
2. Verificar que todas figuran en el SPF (o que están alineadas en DKIM), sin superar el límite de las diez resoluciones.
3. Cambiar a -all una vez adquirida la certeza de que nada legítimo cae fuera de la lista.
4. Vigilar unos días: ninguna fuente legítima debe fallar de repente.

Mientras el paso 1 no esté hecho con serenidad, ~all sigue siendo lo indicado, 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 sale 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: publicar v=spf1 -all, sin el más mínimo mecanismo antes. El registro declara así que ningún servidor está autorizado a emitir en su nombre, lo cual es exactamente cierto, puesto que no emiten. 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 una empresa posee pero que ha olvidado proteger. El v=spf1 -all es la primera línea de defensa, gratuita y definitiva. Ningún dominio de la cartera debería quedarse 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 la cualificación en vigor

Un vistazo rápido basta para hacer balance. Nuestro analizador gratuito lee el registro, indica la cualificación terminal y señala las configuraciones peligrosas como +all. Para el detalle de los controles, ver cómo verificar un registro SPF. Y cuando el SPF devuelve un error en lugar de un simple resultado, ver el PermError, qué significa.

Preguntas frecuentes

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

Con 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 el remitente a corto plazo (menos riesgo de bloquear su propio correo cuando el 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 nada impide apuntar a -all una vez dominado el parque.

¿Qué hacer ante un ?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.

Thomas asegura la cualificación terminal

Saber si un dominio puede pasar a -all sin romper su correo supone conocer todas sus fuentes. Thomas, el CISO virtual, las nombra a partir de los informes, comprueba que todas están cubiertas por SPF o DKIM, e indica el momento preciso para cambiar a -all sin riesgo, y señala si un +all o un ?all peligroso ronda por el registro.

Analizar un dominio gratis o crear una cuenta para pasar a -all con confianza.