El patrón es tan conocido que casi siempre adivinamos cuál fue el último cambio antes de que el cliente termine la frase. El correo funcionaba bien. Alguien leyó una lista de endurecimiento, cambió el final del registro SPF de ~all a -all, y uno o dos días después dejaron de llegar las facturas, los restablecimientos de contraseña y la campaña del mes. No se movió nada más. Solo un carácter.
Imagina una distribuidora de 14 personas: el correo del equipo está en Google Workspace, las facturas salen de un sistema contable y la campaña mensual se envía desde una plataforma de marketing. El registro SPF cubre Google. Nunca cubrió los otros dos, porque nadie los anotó. Con ~all ese correo contable llegaba igual, un poco golpeado. Con -all queda explícitamente no autorizado, y un receptor que se toma el registro en serio lo puede rechazar sin más.
Así que la respuesta honesta a "¿uso ~all o -all?" es: los dos, en ese orden, con un buen rato de leer reportes en medio. Esto es lo que dicen realmente los dos calificadores, qué hacen los receptores con ellos y la secuencia que seguimos en el dominio de un cliente.
Qué significan los calificadores en el RFC 7208
Un registro SPF es una lista de mecanismos que se evalúan de izquierda a derecha. Cada uno coincide con el servidor que se conecta o no coincide. Cuando uno coincide, la evaluación se detiene y el calificador de ese mecanismo se convierte en el resultado. Los calificadores que define el RFC 7208 en la sección 4.6.2 son + para pass, - para fail, ~ para softfail y ? para neutral, y el calificador es opcional: si no lo pones, se asume +.
El mecanismo all del final coincide con todo, así que es el veredicto por defecto para cualquier servidor que no hayas listado. Por eso estos dos registros autorizan exactamente a los mismos remitentes y se diferencian solo en lo que dicen del resto:
v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.google.com -allLéelos en voz alta. El primero dice: estos son mis remitentes, lo demás probablemente no soy yo, pero no estoy tan seguro como para pedirte que lo tires. El segundo dice: estos son mis remitentes, lo demás no soy yo, haz lo que quieras con eso. Los dos son afirmaciones verdaderas sobre un dominio, en etapas distintas de conocerse a sí mismo.
Qué hacen de verdad los receptores con un softfail
El RFC 7208 es poco ambiguo en este punto. Sobre el resultado fail, la sección 8.4 lo describe como una declaración explícita de que el cliente no está autorizado a usar el dominio en esa identidad. Sobre softfail, la sección 8.5 dice que el resultado debería tratarse como algo entre fail y neutral, que el dueño del dominio cree que el servidor no está autorizado pero no está dispuesto a hacer una declaración fuerte de política, y que el software receptor no debería rechazar el mensaje basándose solo en ese resultado, aunque sí puede revisarlo con más lupa de lo normal.
En la práctica esa diferencia es la diferencia entre la carpeta de spam y un rebote. Un softfail es una señal negativa que el filtro pesa junto con todo lo demás que sabe del remitente. Un fail es el resultado que le da al receptor permiso limpio para rechazar durante la conversación SMTP, que es justo lo que quieres cuando ya conoces a tus remitentes y justo lo que no quieres mientras todavía no.
La asimetría importa porque los dos errores cuestan distinto. Dejar ~all de más significa que algo de correo suplantado se filtra en vez de rechazarse. Publicar -all demasiado pronto significa que tus propias facturas rebotan, y nadie te avisa, porque el rechazo cae en un log o en un buzón de postmaster que en una empresa pequeña casi nunca se revisa.
Por qué usar -all antes de conocer tus remitentes provoca caídas
Casi todo dominio envía desde más lugares de los que su dueño recuerda. Cuando inventariamos el dominio de un cliente, la lista que aparece suele incluir varios de estos:
- El sistema contable o el ERP que manda facturas y estados de cuenta.
- La plataforma de comercio electrónico y, aparte, su proveedor de correo transaccional.
- El CRM o la mesa de ayuda que responde desde una dirección compartida.
- El formulario de contacto del sitio, que muchas veces sigue enviando por el servidor del hosting.
- La fotocopiadora de la oficina que alguien configuró hace años para escanear y enviar.
- Herramientas de monitoreo, respaldo y planilla que mandan alertas al personal.
- El proveedor de facturación electrónica, que en varios países de América Latina envía los documentos a nombre de la empresa.
- Un buzón viejo en la cuenta de hosting que alguien todavía usa.
Cada uno de esos tiene que estar en el registro antes de que el registro empiece a rechazar cosas. El reenvío agrega una segunda categoría que no puedes arreglar del todo: cuando alguien reenvía tu correo con un alias, el mensaje llega al siguiente salto desde el servidor de quien reenvía, una dirección que tu dominio nunca autorizó, así que SPF se evalúa contra el remitente equivocado. Con ~all eso es una señal para revisar con más cuidado. Con -all es una invitación a rechazar, y quien pierde el correo es un cliente que armó un reenvío que tú no ves.
La falla de la que -all no te protege
Hay un caso en el que el calificador del final del registro nunca se llega a leer. El RFC 7208, en la sección 4.6.4, limita una evaluación de SPF a 10 mecanismos que requieren consultas DNS, contando include, a, mx, ptr, exists y el modificador redirect, mientras que ip4 e ip6 no cuestan nada. Si te pasas, la evaluación devuelve permerror y el receptor nunca llega a tu mecanismo all. La propia documentación de administración de Google señala que los registros que incluyen varios servicios de terceros pueden cruzar ese límite.
Vale la pena interiorizarlo antes de endurecer nada: un dominio que se pasó del presupuesto de consultas no se vuelve más seguro cambiando a -all, porque el veredicto estricto es inalcanzable. Primero cuenta las consultas. Escribimos cómo hacerlo en la guía para bajar del límite de 10 consultas.
El orden de despliegue que no rompe el correo
Esta es la secuencia que corremos en dominios de clientes, y la razón por la que empujamos de vuelta cuando alguien quiere saltar directo al paso cinco.
- Inventaria cada remitente. Pregúntale por separado a contabilidad, a marketing, a operaciones y a quien administra el sitio, porque ninguna sola persona conoce la lista completa. Después compara el registro publicado con lo que encontraste, no con lo que suponías.
- Publica
~allcubriendo todo lo que encontraste. La documentación de Google Workspace recomiendav=spf1 include:_spf.google.com ~allpara dominios que envían solo por Google Workspace, y advierte que un hard fail hace más probable que los mensajes fallidos se rechacen y deja de servirte para diagnosticar el registro. - Activa DMARC en
p=nonecon una dirección para reportes agregados y déjalo ahí el tiempo suficiente para ver un ciclo completo de facturación y uno de campañas. Dos a cuatro semanas suele ser el mínimo que te dice algo. - Lee los reportes y arregla lo que muestren. Los reportes agregados son la forma en que los remitentes que nadie recordaba se presentan solos. Nuestro recorrido de eso está acá.
- Lleva DMARC hacia el enforcement antes de volver a tocar SPF. El despliegue por etapas de p=none a p=reject es la parte que de verdad frena la suplantación.
- Recién entonces cambia a
-ally observa una semana. A esa altura el cambio debería ser aburrido, que es justamente el punto de dejarlo para el final.
Cómo cambia el cálculo cuando ya tienes DMARC
Con DMARC en su lugar, el calificador importa menos de lo que sugiere casi todo el consejo de endurecimiento. DMARC solo cuenta un pass de SPF sobre una identidad alineada con el dominio del encabezado From. Softfail, fail y neutral le sirven igual de poco: ninguno contribuye a un pass de DMARC y ninguno se trata distinto de los otros. O sea que pasar de ~all a -all no cambia ni un solo resultado de DMARC.
Donde sí se gana su lugar es con receptores que evalúan SPF por fuera de DMARC, y como declaración clara de intención para un dominio que ya terminó su inventario. Es más o menos el razonamiento que publica Microsoft: su documentación de Microsoft 365 recomienda -all precisamente porque también recomienda DKIM y DMARC, para que DMARC pueda actuar sobre los mensajes que fallan SPF y además no traen firma DKIM. La recomendación de ~all de Google asume un dominio que todavía está descubriendo sus remitentes. Los dos son buen consejo, apuntados a días distintos del mismo proyecto.
También conviene contrastar con los requisitos para remitentes. Las guías de Gmail piden que quien envía más de 5,000 mensajes diarios a cuentas de Gmail configure SPF y DKIM, y DMARC para el dominio remitente, y basta con que uno de los dos, SPF o DKIM, esté alineado y con que la política DMARC sea p=none para cumplir el requisito. Nada ahí pide un hard fail. Lo que se exige es autenticación que funcione, no un calificador estricto.
Verifica y después déjalo quieto
Revisa el registro en vivo, no el de tus apuntes, porque los proveedores de DNS parten valores TXT largos sin avisar y la documentación de Google advierte que los cambios pueden tardar de 24 a 48 horas en aplicarse a nivel global:
dig +short TXT ejemplo.com
dig +short TXT _dmarc.ejemplo.comConfirma que existe exactamente un registro v=spf1, que el total está por debajo del límite de consultas y que un mensaje de prueba real vuelve con spf=pass en sus encabezados, no con softfail, fail, neutral ni permerror. Un mensaje que pasa es la única prueba que cuenta; que el registro parsee bien no es lo mismo. Puedes pasar un mensaje real por nuestro diagnóstico de correo gratis y ver qué están registrando los receptores.
Cómo ayuda Guanacos Tech
La mayoría de las emergencias por -all a las que nos llaman no son problemas de SPF. Son problemas de inventario que un calificador estricto convirtió en una caída. Mapeamos todos los remitentes del dominio, controlamos el conteo de consultas, llevamos DMARC de reporte a enforcement y solo entonces apretamos el calificador, para que el último paso sea aburrido. Si tu correo se rompió después de un cambio de DNS, o quieres llegar a -all sin descubrir a la mala quién más envía como tú, agenda una llamada y revisamos el registro contigo.
Fuentes
- RFC 7208, Sender Policy Framework (SPF) versión 1
- Set up SPF - Ayuda de administración de Google Workspace
- About SPF records - Ayuda de administración de Google Workspace
- Troubleshoot SPF issues - Ayuda de administración de Google Workspace
- Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Learn
- Email sender guidelines - Ayuda de Gmail
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)