SPF Softfail vs Fail: Elija la configuración que no le fallará

Qué es SPF (y qué no es): deje de culpar a la herramienta equivocada

SPF (Sender Policy Framework) responde a una pregunta estrecha: ¿está esta IP autorizada para enviar correo usando este dominio en el SMTP MAIL FROM / return-path?
Eso es todo. No autentica directamente su encabezado «From:». No certifica la identidad humana del remitente. Y definitivamente no impide que un phisher ponga el nombre de su CEO en el campo de nombre visible.

SPF es una comprobación de autorización realizada por el receptor, basada en la IP del remitente y el DNS. El receptor evalúa el registro SPF del dominio en el
remitente del sobre (el bounce address), no del encabezado From: visible. DMARC es la capa que vincula SPF (y/o DKIM) al dominio From: mediante alineamiento.

Códigos de resultado SPF centrales que realmente verá

• pass: la IP remitente está autorizada.
• fail: explícitamente no autorizada (típicamente por -all).
• softfail: no autorizada, pero “quizá” (típicamente por ~all).
• neutral: sin afirmación (a menudo por ?all o mecanismos ambiguos).
• none: no se encontró registro SPF.
• temperror: problema transitorio (timeout DNS, SERVFAIL).
• permerror: fallo permanente de evaluación (error de sintaxis, demasiadas búsquedas DNS).

La trampa operativa: los receptores tratan estos resultados de forma diferente. SPF no es un “interruptor de rechazo” universal. Es una señal.
Algunos sistemas tratan softfail casi como fail; otros tratan fail como un fuerte indicador de spam pero aún entregan. Usted no controla al receptor.
Controla cuán defendible es su señal.

Parafraseando a Gene Kranz: “Duro y competente.” Esa es la postura que desea para la autenticación de correo: estricto donde ayuda, cauteloso donde rompe.

~all vs -all: qué significan y cómo los tratan realmente los receptores

El último mecanismo en la mayoría de registros SPF es un calificador “all”. Es su política por defecto para cualquier cosa no coincidente anteriormente.
Estos son los dos entre los que está eligiendo:

• ~all (softfail): “No autorizado, pero no sea duro.” Los receptores suelen aceptar pero marcar o puntuar.
• -all (fail): “No autorizado. Esto es explícitamente incorrecto.” Los receptores pueden rechazar, poner en cuarentena o puntuar fuertemente.

Comportamiento del receptor: la verdad incómoda

El fallo SPF no garantiza el rechazo. El softfail SPF no garantiza la entrega. Los receptores combinan SPF con reputación, análisis de contenido,
DKIM, DMARC, ARC, comportamiento histórico del remitente y, a veces, lo que su proveedor de inteligencia de amenazas les vendió este trimestre.

Aquí está la diferencia práctica en la que puede confiar: -all hace su intención inequívoca. Si un receptor quiere usar SPF como señal decisiva,
usted se lo ha permitido. Con ~all dejó margen de maniobra —y a los atacantes les encanta el margen.

Los dos grandes modos de fallo

1. Falsos negativos (bloquea su propio correo legítimo).
   Causas comunes: proveedores no listados, plataformas SaaS que rotan IPs, pasarelas “scan-and-send”, herramientas CRM, sistemas de tickets, y
   el clásico: “cambiamos el enrutamiento saliente y olvidamos SPF.”
2. Falsos positivos (los atacantes obtienen un aterrizaje más suave).
   Con ~all, las fuentes no autorizadas aún obtienen “soft” failures. Muchos receptores entregarán pero lo pondrán en spam. Algunos lo entregarán al buzón si otras señales son favorables.
   Eso no es una victoria.

Broma #1: SPF es como un portero con una tabla de control. Si la lista está mal, el VIP es rechazado y el alborotador entra con un bigote falso.

Mi recomendación con criterio (y cuándo romperla)

Recomendación por defecto: pase a -all cuando tenga inventario y monitorización

Si controla su correo saliente y puede listar cada remitente legítimo, use -all.
Softfail está bien como estado de transición, no como destino. Los atacantes no necesitan su permiso para enviar; necesitan su ambigüedad para evitar filtros duros.

Dicho esto, no “cambia a -all” por intuición. Hágalo cuando:

• tenga una lista completa de fuentes salientes (MTAs, relays, remitentes SaaS, helpdesk, marketing, nómina, herramientas de monitorización),
• pueda probar la evaluación SPF desde múltiples puntos de vista,
• no esté recibiendo permerrors de SPF de forma consistente (límite de búsquedas),
• tenga informes DMARC y realmente los lea,
• tenga un plan de reversión (disciplina de TTL DNS, control de cambios).

Cuándo ~all está justificado

Use ~all temporalmente si alguno de estos es cierto:

• Está descubriendo remitentes y aún no tiene informes DMARC.
• Su negocio depende de reenvíos o listas de correo donde SPF falla y no tiene cobertura DKIM alineada.
• Heredó un dominio con remitentes “shadow IT” desconocidos y necesita una ventana segura para inventariar sin descartar silenciosamente correo crítico.

La pega: un ~all “temporal” tiende a volverse permanente. Ponga una fecha límite. Ponga un responsable. Si no puede, está eligiendo deriva.

Cuándo debe evitar ambos y arreglar el problema mayor

Si intenta usar la política SPF para resolver el suplantado del encabezado From:, está usando la herramienta equivocada.
Eso es trabajo de DMARC (con DKIM haciendo la mayor parte del trabajo pesado para reenvíos). Su registro SPF debe ser preciso y estricto,
pero la estrategia anti-spoofing es SPF + DKIM + DMARC, no solo SPF.

Hechos e historia: por qué SPF se comporta así

• SPF surgió a principios de los 2000 cuando los operadores intentaban frenar remitentes de sobre falsificados y reducir el backscatter de bounces.
• La evaluación SPF está ligada al sobre SMTP (MAIL FROM / return-path), no al encabezado From: que ven las personas.
• El límite de 10 búsquedas DNS existe porque la evaluación temprana de SPF podía golpear mucho al DNS y convertirse en vector de denegación de servicio.
• El mecanismo ptr quedó efectivamente deprecado en la práctica porque es lento, frágil y susceptible de abuso por control de DNS.
• SPF falla con el reenvío por diseño: el reenviador cambia la IP remitente pero normalmente no reescribe el return-path a un dominio que controle.
• DKIM se introdujo en parte por el reenvío: una firma criptográfica sobrevive el tránsito si los intermediarios no modifican los encabezados firmados.
• DMARC llegó después para conectar los resultados de autenticación al dominio From: visible y proveer política e informes.
• ARC (Authenticated Received Chain) existe porque DMARC estricto puede romper flujos legítimos reenviados (listas, gateways), y los receptores querían confiar en intermediarios.
• Los grandes receptores tratan la autenticación como entrada de reputación más que como puerta binaria, porque los atacantes se adaptan rápido y los falsos positivos son costosos.

Guía rápida de diagnóstico: encuentre el cuello de botella en minutos

Cuando la entrega de correo se pone extraña tras un cambio de SPF, necesita dejar de adivinar. Aquí está el orden que encuentra el problema con rapidez.

Primero: confirme qué registro SPF está viendo el mundo

• Interrogue resolutores autoritativos-ish (no solo la vista cacheada de su portátil).
• Confirme que existe exactamente un registro TXT SPF (o al menos no varios registros “v=spf1”).
• Compruebe el TTL; puede estar persiguiendo fantasmas de propagación.

Segundo: confirme qué IP está realmente enviando

• Use los encabezados Received de un mensaje de ejemplo para identificar la IP de conexión al destinatario.
• No confunda saltos internos con la IP de entrega externa.
• Verifique si el proveedor envía directamente o a través de su relay.

Tercero: evalúe SPF y cuente las búsquedas DNS

• Ejecute un evaluador SPF (o analice logs si usted es receptor).
• Busque permerror (demasiadas búsquedas) o temperror (fallos DNS).
• Revise includes y redirects; son multiplicadores de búsquedas.

Cuarto: compruebe alineamiento DMARC y cobertura DKIM

• Si el fallo es “spoofing”, DMARC es el control de política.
• Si el fallo es “reenvío”, DKIM alineado es su tabla de salvación.
• Si tiene DMARC con enforcement sin cobertura DKIM, se ha tendido una trampa.

Quinto: decida la acción inmediata

• Si correo de negocio está bloqueado: revierta el cambio de SPF (o suavice temporalmente) y abra un incidente para inventariar remitentes correctamente.
• Si el spoofing pasa: endurezca SPF a -all y mueva DMARC hacia cuarentena/rechazo una vez DKIM sea estable.
• Si permerror: reduzca búsquedas, aplane o coloque remitentes detrás de un relay controlado.

Tareas prácticas: 12+ comandos, salidas y decisiones

Esto no es “agradable de tener”. Son las perillas que mueve a las 2 a.m. cuando Ventas dice que los correos de cotización desaparecieron.
Cada tarea incluye: comando, qué significa la salida y la decisión que toma.

Task 1: Fetch the SPF TXT record (and spot duplicates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"
"google-site-verification=abc123"

Significado: Existe un registro SPF (bien). El otro TXT es irrelevante. Si ve dos cadenas separadas que empiezan con v=spf1,
muchos receptores tratarán eso como permerror.

Decisión: Si existen duplicados, fusione en un solo registro SPF inmediatamente.

Task 2: Check the record as seen by specific resolvers (propagation sanity)

cr0x@server:~$ dig @8.8.8.8 +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Significado: El resolutor público ve el valor previsto.

Decisión: Si resolutores diferentes discrepan, no “arregle” SPF de nuevo—espere al TTL o identifique problemas de DNS con split-horizon.

Task 3: Check TTL to estimate how long the blast radius lasts

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.        3600    IN      TXT     "v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Significado: El TTL es 3600 segundos. En el peor caso, las cachés mantienen datos viejos cerca de una hora.

Decisión: Antes de cambios mayores de SPF, baje el TTL con un día de antelación; durante incidentes, ajuste expectativas según el TTL.

Task 4: Verify the sending IP from a received message header (sender truth serum)

cr0x@server:~$ grep -iE '^(received: from|authentication-results:)' sample.eml | head
Received: from outbound.vendor.example (outbound.vendor.example [198.51.100.77])
Authentication-Results: mx.receiver.example; spf=softfail (example.com: domain of bounce@example.com does not designate 198.51.100.77 as permitted sender)

Significado: El receptor evaluó SPF para example.com y la IP conectante fue 198.51.100.77.

Decisión: Si esa IP no está en su SPF, añada el mecanismo/include del proveedor o enrútelos por su relay autorizado.

Task 5: Evaluate SPF with a local tool (quick and blunt)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@example.com -helo outbound.vendor.example
fail

Significado: Para el dominio remitente del sobre, esa IP no está autorizada.

Decisión: No cambie -all a ~all para “arreglar” esto. Arregle la lista de autorizaciones o la ruta de envío.

Task 6: Count DNS lookups risk with an SPF inspection (detect permerror candidates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.a.example include:_spf.b.example include:_spf.c.example include:_spf.d.example -all"

Significado: Cada include puede desencadenar múltiples búsquedas. Puede llegar a 10 rápidamente.

Decisión: Si se aproxima a la complejidad, consolide remitentes detrás de un relay o aplane con cuidado (ver Task 9/10).

Task 7: Detect an SPF permerror (too many DNS lookups) via receiver logs (Postfix example)

cr0x@server:~$ sudo grep -i spf /var/log/mail.log | tail -5
Jan  4 11:02:18 mx postfix/smtpd[22190]: NOQUEUE: reject: RCPT from unknown[203.0.113.55]: 550 5.7.1 SPF permerror; too many DNS lookups; from=<bounce@example.com> to=<user@receiver.example> proto=ESMTP helo=<sender.example>

Significado: La evaluación SPF falló permanentemente. Algunos receptores rechazan por permerror, otros tratan como neutral; en cualquier caso, es descuidado.

Decisión: Reduzca includes/redirects. Trate el permerror como una condición de interrupción para la entregabilidad.

Task 8: Confirm you didn’t publish two SPF records (classic self-own)

cr0x@server:~$ dig +short TXT example.com | grep -c '^"v=spf1'
2

Significado: Existen dos registros SPF. Muchos receptores devuelven permerror.

Decisión: Fusione inmediatamente en un registro. Luego re-verifique con varios resolutores.

Task 9: Extract and validate include targets (are you depending on a broken vendor?)

cr0x@server:~$ dig +short TXT _spf.vendor.example
"v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.128/25 -all"

Significado: El proveedor publica un SPF limpio con rangos IP explícitos y -all.

Decisión: Si el SPF del proveedor está malformado o inflado, presiónelos: o lo corrigen o los enruta por un relay controlado.

Task 10: Check SPF redirect usage (and understand its blast radius)

cr0x@server:~$ dig +short TXT mail.example.com
"v=spf1 redirect=example.com"

Significado: El SPF de subdominio está delegado completamente a la política del apex.

Decisión: Si necesita remitentes distintos para subdominios (marketing vs transaccional), evite redirect y defina explícitamente.

Task 11: Verify DKIM is present for a sender that will be forwarded (SPF-proofing)

cr0x@server:~$ grep -i '^dkim-signature:' sample.eml | head -1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Significado: El mensaje está firmado por DKIM por example.com. Esto puede sobrevivir al reenvío, preservando el alineamiento DMARC incluso cuando SPF falla.

Decisión: Si el correo reenviado es crítico, priorice la corrección de DKIM sobre intentar “hacer que SPF funcione” mediante reenvíos.

Task 12: Query DMARC policy (because SPF strictness alone isn’t the point)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Significado: DMARC aplica cuarentena y requiere alineamiento estricto para DKIM y SPF.

Decisión: Si no tiene cobertura DKIM fuerte en todos los remitentes legítimos, el alineamiento estricto más un fallo SPF puede causar problemas a los usuarios. Arregle las configuraciones de remitente primero.

Task 13: Check alignment symptoms in Authentication-Results

cr0x@server:~$ grep -i '^authentication-results:' sample.eml | head -1
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=fail header.from=example.com

Significado: SPF pasó para bounce.example.com, DKIM pasó para example.com, pero DMARC falló para header.from=example.com.
Eso es desalineamiento: los dominios no están alineados según sus ajustes DMARC.

Decisión: Alinee el dominio remitente del sobre con el dominio From (o relaje el alineamiento) y asegure que DKIM use el dominio From cuando sea posible.

Task 14: Identify who is sending for you (Postfix outbound logs example)

cr0x@server:~$ sudo grep -E 'status=sent|relay=' /var/log/mail.log | tail -5
Jan  4 10:55:01 mta postfix/smtp[21011]: 1A2B3C4D: to=<user@outside.example>, relay=aspmx.l.google.com[142.250.102.27]:25, delay=1.2, status=sent (250 2.0.0 OK)
Jan  4 10:56:44 mta postfix/smtp[21022]: 5E6F7A8B: to=<user@outside.example>, relay=mail.protection.outlook.com[52.101.73.5]:25, delay=0.9, status=sent (250 2.6.0 Queued mail for delivery)

Significado: Puede ver destinos salientes, y también inferir si está enviando directamente o pasando por un smart host.

Decisión: Si enruta a través de un único relay, SPF puede ser más simple (autorice el relay). Si envía desde muchas IPs, el inventario es obligatorio.

Task 15: Sanity-check your outbound public IP (cloud NAT surprises)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.55

Significado: La IP de egress de este host es 203.0.113.55 desde la perspectiva de Internet.

Decisión: Asegúrese de que esa IP (o el rango NAT) esté autorizada en SPF si puede enviar correo directamente. Si la IP cambia, deje de enviar directamente; use un relay estable.

Tres micro-historias corporativas desde el terreno

1) Incidente causado por una suposición errónea: “El proveedor usa nuestro relay”

Una compañía mediana tenía un relay SMTP interno y un SPF ordenado: un rango IP, un include, -all.
También tenían una nueva plataforma de RRHH que enviaba correos de onboarding. Todos creían que la plataforma estaba configurada para enviar a través del relay.
Incluso decía “SMTP configured” en la UI de administración, una frase que ha engañado a más gente que cualquier correo de phishing.

El primer síntoma no fue un rebote. Fue silencio. Los nuevos empleados no recibían sus enlaces de onboarding, los gestores no recibían aprobaciones,
y el equipo de RRHH asumió que “la app está inestable”. Mientras tanto, algunos destinatarios externos sí recibieron los mensajes—pero en spam.
Diferentes receptores, distinto comportamiento. Así es la vida con SPF.

Cuando alguien finalmente sacó un mensaje crudo, la IP conectante pertenecía a la infraestructura del proveedor, no al relay de la compañía.
El proveedor había caído silenciosamente a “envío directo” porque el relay requería ajustes TLS que no habían soportado completamente para ese tenant.
SPF hizo exactamente lo que debía: marcó el correo como no autorizado. La suposición fue errónea, no el mecanismo.

La solución fue aburrida y efectiva: o hacer que el proveedor use el relay de verdad, o autorizar el include del proveedor en SPF y exigir firma DKIM
con el dominio de la compañía. Eligieron la vía del relay para mantener SPF pequeño y estable. También añadieron revisión semanal de informes DMARC.
El incidente terminó y la lección quedó: si no puede señalar la IP y la configuración, no “conoce” la ruta de correo.

2) Optimización que salió mal: “Aplanemos SPF por rendimiento”

Otra organización había hecho crecer un registro SPF como un cajón de trastos: seis includes, dos bloques ip4 y un redirect para un subdominio.
Se asustaron por el límite de 10 búsquedas y decidieron aplanarlo todo—copiar rangos IP de proveedores directamente en el registro.
Se presentó como “rendimiento” y “resiliencia” porque eliminaba dependencias del DNS del proveedor.

El aplanado funcionó un mes. Luego la entregabilidad empezó a tambalearse. Una plataforma de marketing empezó a usar un nuevo pool de IPs,
y porque la org había congelado los rangos antiguos en su SPF, esos mensajes comenzaron a fallar SPF. Algunos receptores pusieron en cuarentena; otros rechazaron.
El include del proveedor se había actualizado correctamente, pero la org optó por salirse de esa corriente de actualizaciones.

El modo de fallo fue sutil: las pruebas internas seguían “pasando” porque los ingenieros probaron desde una región y un remitente.
En producción, el proveedor usaba egress IPs diferentes según geografía y throughput. El SPF aplanado se volvió una instantánea obsoleta,
y la org se había hecho cargo del ciclo de vida de IP del proveedor.

Revertieron a includes para proveedores que los mantienen bien, y usaron aplanado sólo para fuentes que poseían.
El cambio mayor fue de proceso: el onboarding de proveedores ahora requiere o (a) un include estable publicado con prácticas de cambio, o (b) enrutar por el relay de la compañía.
La optimización es buena—hasta que cambia quién tiene la responsabilidad de mantenerla correcta.

3) Práctica aburrida pero correcta que salvó el día: estricticidad por etapas con informes DMARC

Una firma de servicios financieros ejecutó un programa disciplinado de autenticación de correo. No emocionante. Muy efectivo.
Empezaron con SPF ~all en un dominio legacy porque realmente no sabían todos los remitentes. En vez de adivinar, instrumentaron.
DMARC se puso en p=none con informes habilitados, y el equipo de seguridad revisaba reportes agregados semanalmente.

Encontraron las sorpresas habituales: un sistema de monitorización que enviaba alertas “disco lleno” directamente desde una IP de colo, una impresora de oficina regional con SMTP auth,
y una pequeña herramienta SaaS de facturación que nadie había contado al TI central. Ninguno era malicioso. Eran simplemente no asignados.
Los informes los hicieron visibles, que es lo que hace una buena telemetría: convierte misterios en tickets.

Tras alinear o reemplazar esos remitentes, cambiaron SPF a -all y DMARC a p=quarantine.
Solo entonces subieron a p=reject para el dominio principal, manejando subdominios por separado.
Cuando un atacante intentó una campaña básica de spoofing, la mayoría de receptores la rechazaron limpiamente. Los equipos internos apenas notaron.

El “salvado” vino después: una caída de un proveedor forzó un re-enrutamiento temporal del correo saliente por un relay de backup.
Porque la firma tenía inventario explícito de remitentes y un proceso de cambios, actualizar SPF fue un cambio controlado con TTL pre-reducido y un plan de reversión.
Su correo siguió fluyendo. Nadie escribió sobre ello en internet, lo que es señal de que se hizo bien.

Errores comunes: síntoma → causa raíz → solución

1) Mensajes de repente van a spam tras cambiar ~all a -all

Síntoma: Correos transaccionales legítimos empiezan a aterrizar en spam/cuarentena en proveedores principales.

Causa raíz: Uno o más remitentes legítimos nunca fueron autorizados; softfail se toleraba, fail no.

Solución: Identifique IPs remitentes desde encabezados o logs, autorice vía ip4/ip6 o include, o enrútelos por un relay conocido. Luego vuelva a probar SPF y alineamiento DMARC.

2) Receptores aleatorios rechazan con “SPF permerror”

Síntoma: Algunos destinatarios rechazan con 5.7.1 y mencionan permerror o “too many DNS lookups.”

Causa raíz: Su registro SPF excede 10 búsquedas DNS debido a includes/redirect/a/mx.

Solución: Reduzca búsquedas: elimine includes no usados, evite a/mx salvo que sean necesarios, consolide remitentes o use un relay. Revise duplicación y errores de sintaxis.

3) SPF pasa pero DMARC falla (y no puede explicarlo)

Síntoma: Authentication-Results muestra spf=pass pero dmarc=fail.

Causa raíz: SPF pasó para un dominio de sobre no alineado (p. ej., dominio bounce del proveedor), y DKIM falta o no está alineado.

Solución: Asegure que DKIM firme con su dominio From, o alinee el dominio remitente del sobre; ajuste la alineación DMARC solo si comprende el tradeoff.

4) Correo reenviado falla SPF y es bloqueado tras enforcement de DMARC

Síntoma: Empleados que reenvían correo a cuentas personales (o socios) ven rechazos/cuarentena.

Causa raíz: Los reenviadores rompen SPF; DMARC en enforcement depende de que DKIM pase y esté alineado, lo cual puede faltar.

Solución: Mejore la cobertura DKIM en su correo saliente; considere receptores conscientes de ARC y mejores prácticas para listas/reenvíos. Evite confiar en SPF para rutas reenviadas.

5) Publicó “v=spf1” como varios fragmentos TXT y algunos sistemas lo interpretan mal

Síntoma: Fallos SPF intermitentes; distintas herramientas muestran cadenas de registro diferentes.

Causa raíz: Longitud del registro/quoting o múltiples registros; algunas UIs DNS dividen cadenas mal.

Solución: Asegure exactamente un RRset TXT SPF y que sea una cadena SPF válida. Valide con la salida de dig y un evaluador local.

6) El proveedor le dice usar “+all” o “?all” para evitar problemas

Síntoma: Soporte del proveedor sugiere debilitar SPF para “arreglar entregabilidad.”

Causa raíz: No pueden (o no quieren) proporcionar autorización de envío estable y quieren que lo acepte todo.

Solución: No lo haga. Enrute por su relay o exija firma DKIM con su dominio y una estrategia de include adecuada. Si no pueden, reconsidere al proveedor.

Listas de verificación / plan paso a paso

Paso a paso: camino seguro de ~all a -all

1. Inventario de remitentes: liste todos los sistemas que envían como su dominio (humanos + apps + dispositivos + proveedores).
2. Habilite informes DMARC con p=none si aún no los tiene; asigne un responsable para leer informes semanalmente.
3. Confirme cobertura DKIM para cada remitente que pueda: marketing, tickets, facturación, RRHH, etc.
4. Arregle alineamiento: asegure que DKIM d= y/o el return-path SPF se alineen con From según su DMARC.
5. Limpie SPF: un solo registro, sin includes muertos, evite ptr, minimice a/mx.
6. Revise presupuesto de búsquedas: deje margen amplio bajo 10. No opere en 9/10 y finja que está bien.
7. Baje TTL con antelación (24–48 horas) antes de cambiar a -all para que la reversión sea realista.
8. Etape el cambio: aplique -all primero en subdominios menos críticos o en un dominio piloto si puede.
9. Monitoree: vigile rebotes, feedback de receptores e informes DMARC por al menos un ciclo de negocio completo (una semana+).
10. Cambie a -all y documente la lista de remitentes como un artefacto vivo ligado al onboarding/offboarding de proveedores.

Lista operativa: antes de tocar SPF en DNS

• ¿Conocemos cada ruta legítima de envío, incluidas herramientas “pequeñas” (alertas, impresoras, apps legacy)?
• ¿Tenemos un plan de reversión y una copia reciente del TXT previo?
• ¿El TTL es lo bastante bajo para que la reversión importe?
• ¿Hemos verificado que hoy hay exactamente un registro SPF?
• ¿Este cambio nos empuja hacia el límite de 10 búsquedas?
• ¿Estamos aplicando DMARC? Si sí, ¿está DKIM alineado para todos los remitentes principales?
• ¿Quién está a cargo de gestionar tickets de entregabilidad las próximas 24–48 horas?

Regla de decisión: qué debería publicar hoy

• Publique -all si: el inventario de remitentes es exacto, DKIM está ampliamente desplegado, se revisan informes DMARC y controla o puede limitar remitentes.
• Publique ~all si: está descubriendo remitentes con un plan acotado en el tiempo y puede tolerar que algo de correo suplantado tenga mejor puntaje del que debería.
• No “solucione” problemas de proveedor con ?all o +all. Eso no es política; es rendición.

Broma #2: Cambiar SPF sin comprobar el alineamiento DMARC es como apretar las tuercas de un coche con tres ruedas. Técnicamente hizo trabajo.

Preguntas frecuentes

1) ¿Garantiza -all que los receptores rechazarán correo no autorizado?

No. Señala “fail”, pero el receptor decide qué hacer. Muchos rechazarán, algunos pondrán en cuarentena, otros aún entregarán pero con puntuación alta.
Su control es la precisión y la estricticidad de la señal, más la política DMARC y DKIM.

2) ¿Es ~all más seguro porque no romperá correo legítimo?

Es más seguro solo en el sentido de que algunos receptores son más indulgentes. También da a remitentes no autorizados un aterrizaje más suave.
Si usa ~all, trátelo como transición mientras inventaría y arregla remitentes.

3) Usamos varios proveedores. ¿Simplemente añadimos todos sus includes?

A veces. Pero los includes multiplican búsquedas y tiene un límite duro. Si está apilando proveedores, puede convenir más
enrutar el correo saliente a través de un relay central que usted controla, y autorizar solo ese relay en SPF.

4) ¿Por qué el reenvío rompe SPF?

SPF comprueba la IP conectante contra el registro SPF del dominio remitente del sobre. Un reenviador cambia la IP conectante pero normalmente mantiene el remitente original.
Resultado: IP no autorizada, SPF falla. DKIM puede sobrevivir al reenvío y rescatar el alineamiento DMARC si está configurado correctamente.

5) ¿Debería usar include o listar rangos IP directamente?

Use include cuando el proveedor lo mantiene bien y cambia IPs. Liste IPs directamente cuando usted las posea y controle.
Aplanar rangos de proveedores en su SPF le hace responsable de seguir su churn de IPs, una tarea que probablemente no presupuestó.

6) ¿Qué es peor: temperror o permerror?

En la práctica, permerror es peor porque es persistente y señala configuración rota (sintaxis, registros múltiples, límite de búsquedas).
Temperror puede ser intermitente (caídas DNS), pero a escala también daña la entregabilidad. Cualquiera de los dos es razón para simplificar y endurecer DNS.

7) ¿Puedo usar SPF para evitar que alguien suplante mi dirección From:?

No de forma fiable. SPF autentica el dominio remitente del sobre. Los atacantes pueden elegir un dominio de sobre que controlan mientras suplantan el From: visible.
DMARC es lo que vincula la autenticación al dominio From: (alineamiento). Use SPF como parte del conjunto, no como la solución completa.

8) Tenemos DMARC en reject. ¿Significa eso que SPF debe ser -all?

No estrictamente. DMARC puede pasar vía DKIM incluso si SPF falla. Pero si la cobertura DKIM es incompleta, la estricticidad SPF cobra mucha más importancia.
Si aplica DMARC en enforcement, debería tener confianza en DKIM primero y luego hacer SPF estricto y preciso.

9) ¿Y los subdominios—deben heredar el registro SPF del apex?

Solo si el conjunto de remitentes es realmente idéntico. Las plataformas de marketing y sistemas de producto suelen usar subdominios por una razón. Si redirige todo al apex,
puede autorizar por error remitentes donde no debería, o romper remitentes legítimos de subdominios.

10) ¿Cómo sé si cambiar a -all me va a salir mal?

Si no puede responder “¿cuáles son todas las IPs/dominios legítimos que envían?” y “¿firman con DKIM alineado?” con evidencia (logs, encabezados, informes DMARC),
no está listo. Use ~all temporalmente, instrumente, arregle y luego pase a -all con un despliegue por etapas.

Conclusión: qué hacer a continuación

Si quiere la configuración que no le fallará, no trate ~all vs -all como un debate moral. Trátelo como preparación.
Softfail es un periodo de prueba. Fail es producción.

Pasos prácticos siguientes:

1. Ejecute las comprobaciones DNS anteriores y confirme que tiene exactamente un registro SPF y un TTL razonable.
2. Extraiga encabezados de correos reales y anote las IPs conectantes reales para cada sistema remitente.
3. Arregle DKIM y alineamiento DMARC para sus remitentes principales, especialmente lo que se reenvía.
4. Reduzca la complejidad de búsquedas SPF antes de que se convierta en ruleta de permerror.
5. Pase a -all con un cambio por etapas, monitorizado al menos una semana con tráfico real.

La meta no es publicar un registro que se vea intimidante. La meta es publicar un registro que pueda defender a las 2 a.m. con logs, encabezados y un plan de reversión.
Así evita que la autenticación de correo se convierta en una denegación de servicio accidental contra su propio negocio.