Fallas SPF de correo: los 5 errores en registros que rompen la entrega (y cómo solucionarlos)

SPF en términos operativos sencillos (qué hace realmente)

SPF (Sender Policy Framework) es una política publicada en DNS que le dice al receptor qué IPs están autorizadas a enviar correo usando un dominio en la identidad SMTP “envelope-from” (el dominio Return-Path). El receptor compara la IP que se conecta contra esa política y produce un resultado: pass, fail, softfail, neutral, none, temperror o permerror.

En producción, SPF cumple dos funciones:

• Evitar suplantaciones casuales de tu dominio en el envelope-from (no necesariamente en el encabezado visible From:).
• Alimentar políticas downstream, especialmente DMARC. DMARC usa SPF (y/o DKIM) más reglas de alineación para decidir si poner en cuarentena o rechazar.

SPF no es magia. No cifra. No prueba que un humano escribió el correo. No sobrevive al reenvío en muchos casos. Es una comprobación de política ligada a la IP del cliente SMTP en el momento de la entrega. Por eso un registro SPF “válido” puede fallar en el mundo real cuando cambia la ruta del correo.

Una matización más: SPF se evalúa sobre el dominio del envelope-from (Return-Path), no sobre el encabezado visible From: que ven las personas. Si tu proveedor usa bounces.vendor.example como return-path y tu dominio DMARC es example.com, SPF puede pasar pero no alinearse. Eso es un problema distinto con el mismo síntoma: “DMARC falló”.

Idea parafraseada de Werner Vogels: Lo construyes, lo operas. El correo no es una excepción. Si delegas el envío a proveedores, sigues siendo responsable de los resultados de autenticación.

Broma #1: SPF es como un portero de discoteca que revisa la lista de invitados. Si sigues reescribiendo la lista durante el turno, no te sorprendas cuando nadie entre.

Hechos interesantes y contexto histórico

• SPF precede a DMARC por años. SPF se empezó a desplegar ampliamente a mediados de los 2000; DMARC llegó después para unificar SPF y DKIM bajo una política del propietario del dominio.
• El “límite de 10 consultas DNS” es una fricción intencional. Existe para evitar que un receptor se vea obligado a realizar trabajo DNS recursivo costoso por mensaje (un vector clásico de DoS).
• TXT ganó la pelea de tipos de registros. SPF tuvo en su momento un tipo de RR dedicado, pero TXT se convirtió en el estándar práctico por soporte DNS y herramientas inconsistentes.
• SPF comprueba la IP que se conecta, no “al remitente”. Por eso los relays salientes, las piscinas compartidas de SaaS y el NAT de egress on‑prem son trampas habituales.
• “~all” se volvió popular porque parecía más seguro. Softfail se usa a menudo durante el despliegue, pero muchas organizaciones nunca migran a “-all”, dejando vías abiertas para suplantaciones.
• Los receptores tratan permerror con dureza. Un error de sintaxis o una explosión de consultas puede provocar “permerror”, y algunos receptores lo tratan efectivamente como fail para decisiones de aplicación.
• Las macros SPF existen y rara vez valen la pena. Son potentes y frágiles, y pueden crear comportamiento impredecible de consultas entre receptores.
• La alineación es por qué DMARC cambió las reglas del juego. Un “pass” de SPF no es suficiente; debe alinearse con el From: visible para satisfacer DMARC vía SPF.
• Flattenear SPF es un parche, no una virtud. Cambia la indirección DNS por mantenimiento de listas de IP, y puede quedarse obsoleto rápido a menos que esté automatizado.

Guía rápida de diagnóstico

Si estás de guardia y los correos rebotan, no tienes tiempo para filosofía. Necesitas una secuencia determinista que encuentre el cuello de botella rápido.

Primero: identifica qué identidad está fallando (SPF vs DMARC vs “alguna cosa del proveedor”)

1. Consigue un rebote real o un encabezado del receptor de una entrega fallida. Busca: spf=, dmarc=, dkim=, Authentication-Results:, o un “SPF fail” explícito.
2. Extrae el dominio del envelope-from (Return-Path) y la IP que se conectó (a menudo aparece en el rebote o en el log SMTP).
3. Decide si vas a arreglar SPF, alineación o enrutamiento. Si SPF pasa pero DMARC falla, puede que estés frente a un problema de alineación o DKIM.

Segundo: valida publicación y propagación DNS

4. Consulta la vista autorizada del DNS (no el resolver cacheado de tu portátil). Confirma que hay exactamente una política SPF coherente y que comienza con v=spf1.
5. Compara múltiples resolvers (públicos e internos). Si los resultados difieren, es propagación o DNS con separación de vistas (split-horizon).
6. Revisa los TTL para estimar cuándo convergerá el mundo. No adivines. Lee el TTL.

Tercero: evalúa el registro SPF como lo haría el receptor

7. Cuenta las consultas DNS (includes, a, mx, ptr, exists, redirect). Si estás cerca de 10, asume que en algún lugar las sobrepasas.
8. Prueba la IP del remitente específica contra el registro. SPF trata sobre la IP que se conectó, no sobre la marca del proveedor.
9. Busca mecanismos frágiles: ptr, macros, cadenas redirect, includes demasiado amplios.

Cuarto: decide la corrección menos riesgosa

• Si tienes múltiples registros TXT SPF: combínalos en uno. Esa suele ser la victoria más rápida.
• Si excedes el límite de consultas: reduce includes, elimina a/mx si no son necesarios, o flattenea (con automatización) si es imprescindible.
• Si fallas por proveedores que envían desde rangos IP inesperados: corrige la ruta de envío o la configuración del proveedor, no solo el registro SPF.
• Si DMARC aplica y SPF no se alinea: arregla la alineación (return-path personalizado) o apóyate en la alineación DKIM.

Los 5 errores en registros SPF que rompen la entrega (y las soluciones)

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

Permerror de SPF aparece de repente tras un “pequeño cambio DNS”

Síntomas: Los rebotes mencionan “SPF permerror”, “demasiadas consultas DNS” o “SPF inválido”. Empezó dentro de la hora tras una actualización DNS.

Causa raíz: Cruzaste el límite de 10 consultas añadiendo un include más, o creaste múltiples registros TXT SPF.

Solución: Fusiona en un único registro TXT SPF y reduce las consultas. Elimina includes innecesarios; reemplaza a/mx por rangos IP explícitos cuando sea factible.

SPF pasa pero DMARC falla (y el receptor aún rechaza)

Síntomas: El encabezado muestra spf=pass pero dmarc=fail; los rebotes mencionan la política DMARC. Usuarios informan “funciona en Gmail pero no en dominios corporativos” o viceversa.

Causa raíz: SPF pasó para un dominio envelope-from que no se alinea con el From: visible. O DKIM falta/está roto y SPF es la única esperanza.

Solución: Configura return-path personalizado bajo tu dominio (alineación), o asegúrate de que DKIM firme y se alinee con el From: visible y sobreviva la ruta de envío.

SPF falla solo en un flujo de un proveedor

Síntomas: Mail de Office 365 pasa; plataforma de marketing falla. O lo transaccional pasa; el sistema de tickets falla.

Causa raíz: El proveedor envía desde IPs no cubiertas por el registro SPF del dominio de return-path relevante; o el proveedor usa un dominio envelope-from distinto al que asumiste.

Solución: Identifica la IP que se conecta y el dominio envelope-from a partir de encabezados reales. Actualiza el registro SPF correcto (a menudo un subdominio). Prefiere el include del proveedor si no rompe el límite de consultas.

SPF “none” aparece aunque “configuré SPF hace meses”

Síntomas: Receptores muestran spf=none. Aseguras que SPF existe.

Causa raíz: Publicaste SPF en www.example.com u otro dominio distinto al dominio return-path. O DNS con separación de vistas sirve respuestas distintas externamente.

Solución: Consulta el dominio return-path real usado en el mensaje. Valida el DNS autoritativo visible externamente. Elimina registros internos solo o alinea las zonas internas/externas.

SPF falla tras habilitar un nuevo relay saliente o cambiar NAT

Síntomas: Todo estaba estable; luego cambiaron infraestructuras (nuevas IPs de egress, nueva piscina de relays). Ahora la entrega empeora.

Causa raíz: SPF autorizaba solo las IPs antiguas. La IP del cliente SMTP cambió.

Solución: Actualiza SPF con los nuevos rangos de egress (o con el include publicado por el relay). También verifica que el relay se use para todos los flujos; las configuraciones híbridas suelen filtrar tráfico directo a internet.

Resultados SPF intermitentes entre destinatarios

Síntomas: Algunos destinatarios ven pass, otros fail o none. Varía por región/proveedor.

Causa raíz: Diferencias de propagación DNS, caches obsoletos o servidores autoritativos que no están sincronizados. A veces es fallo de DNSSEC o problema en la ruta del resolver.

Solución: Consulta los servidores autoritativos directamente y compara entre resolvers. Asegura que todos los NS sirvan el mismo TXT SPF. Arregla el proceso de despliegue DNS; baja TTL temporalmente durante ventanas controladas de cambios.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas probadas en campo que puedes ejecutar desde un host Linux con herramientas comunes. Cada tarea incluye: el comando, una salida representativa, qué significa y qué decisión tomar.

Task 1: Pull the published SPF TXT record (simple view)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Qué significa: Existe al menos un registro TXT; una cadena parece SPF.

Decisión: Si ves más de una cadena v=spf1 aquí, probablemente tienes el problema de “múltiples TXT SPF” y debes fusionarlos inmediatamente.

Task 2: Detect multiple SPF records explicitly

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 -all"
example.com.  300 IN TXT "v=spf1 include:spf.mailvendor.example ~all"

Qué significa: Se publicaron dos políticas SPF en el mismo nombre propietario.

Decisión: Trátalo como riesgo de permerror. Reemplaza ambos con una cadena SPF fusionada. No “dejes ambos y esperes que un receptor escoja uno”. No deberían hacerlo.

Task 3: Query authoritative nameservers (avoid caching lies)

cr0x@server:~$ dig +short NS example.com
ns1.dnsprovider.example.
ns2.dnsprovider.example.

cr0x@server:~$ dig +noall +answer TXT example.com @ns1.dnsprovider.example
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Qué significa: Estás inspeccionando lo que sirve el servidor autoritativo, no lo que algún resolver cacheó ayer.

Decisión: Si ns1 y ns2 difieren, tienes un problema de publicación DNS. Arregla eso primero; el correo es downstream.

Task 4: Inspect TTL to estimate propagation time

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Qué significa: El TTL es 3600 segundos (una hora). Los receptores pueden cachear hasta ese tiempo (a veces más con resolvers defectuosos).

Decisión: Si necesitas una vía de reversión rápida, reduce el TTL antes de cambios riesgosos durante una ventana planificada. Durante un incidente, cambiar TTL no vacía caches al instante.

Task 5: Check if your outbound IP is what you think it is

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

Qué significa: La IP de salida de este host es 203.0.113.55.

Decisión: Si tu SPF no incluye esta IP (o el rango del relay), SPF fallará para envíos directos desde este host/red. Decide si enrutar el correo por el relay previsto o actualizar SPF.

Task 6: Confirm which SMTP client actually connects to the internet (Postfix logs)

cr0x@server:~$ sudo grep -E "to=<|relay=" /var/log/mail.log | tail -n 3
Jan 03 10:11:12 mx1 postfix/smtp[23144]: 3F2A0123: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.2, delays=0.1/0.1/0.4/0.6, dsn=2.0.0, status=sent
Jan 03 10:12:01 mx1 postfix/smtp[23188]: 9ABCD456: to=, relay=203.0.113.200[203.0.113.200]:587, delay=0.9, delays=0.1/0.1/0.2/0.5, dsn=2.0.0, status=sent
Jan 03 10:12:45 mx1 postfix/smtp[23210]: 7CDE9012: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.0, delays=0.1/0.1/0.3/0.5, dsn=2.0.0, status=sent

Qué significa: Parte del correo va directo a los destinatarios; otra parte pasa por un smarthost en 203.0.113.200.

Decisión: El enrutamiento mixto aumenta la complejidad SPF porque la IP que se conecta cambia. Decide si hacer cumplir una única ruta de salida (preferible) o asegurar que SPF cubra todas las IPs de egress posibles.

Task 7: Extract Return-Path and Authentication-Results from a raw message

cr0x@server:~$ sed -n '1,80p' message.eml | egrep -i '^(return-path|authentication-results|received|from:|dkim-signature):'
Return-Path: 
Authentication-Results: mx.recipient.example; spf=fail (sender IP is 198.51.100.77) smtp.mailfrom=bounce.mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Received: from mta77.vendor.example (mta77.vendor.example [198.51.100.77])
From: Billing 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Qué significa: SPF falló para bounce.mail.example.com desde la IP 198.51.100.77, pero DKIM pasó y DMARC pasó (porque DKIM se alineó con example.com).

Decisión: Si DMARC pasa vía DKIM, la falla SPF puede ser tolerable pero aún perjudicial para la reputación. Decide si arreglar SPF de todas formas (recomendado) o aceptarlo temporalmente asegurando que DKIM siga estable.

Task 8: Resolve the include chain (and spot hidden lookup bombs)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Qué significa: Un include se expande en más includes. Eso es normal, pero consume presupuesto de consultas.

Decisión: Cuando apilas varios includes “grandes”, estás apostando a no alcanzar 10 consultas. Cuéntalas. Si estás cerca, refactoriza antes de que falle.

Task 9: Count DNS-lookups roughly (pragmatic method)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounces@bounce.mail.example.com -helo mta77.vendor.example
result: pass
smtp.mailfrom: bounce.mail.example.com
Received-SPF: pass (bounce.mail.example.com: domain of bounces@bounce.mail.example.com designates 198.51.100.77 as permitted sender)

Qué significa: La evaluación SPF local devuelve pass para esa IP y remitente. Esto no es idéntico al comportamiento de todos los receptores, pero es una señal sólida.

Decisión: Si tu prueba dice pass pero un receptor dice fail, sospecha que evaluaron un dominio distinto (mismatch de alineación/return-path), vieron DNS distinto (propagación/split-horizon), o alcanzaron límites de consultas por comportamiento de resolución distinto.

Task 10: Verify you didn’t accidentally publish SPF on the wrong name

cr0x@server:~$ dig +short TXT www.example.com
"v=spf1 include:spf.mailvendor.example -all"

cr0x@server:~$ dig +short TXT example.com
"google-site-verification=abc123"

Qué significa: SPF existe en www.example.com pero no en el apex example.com.

Decisión: Si tu correo usa example.com en return-path, SPF está efectivamente ausente. Mueve el registro SPF al nombre de dominio correcto (o colócalo en el dominio return-path que realmente usas).

Task 11: Check for split-horizon DNS (internal vs external answers)

cr0x@server:~$ dig +short TXT example.com @10.0.0.53
"v=spf1 ip4:10.10.10.10 -all"

cr0x@server:~$ dig +short TXT example.com @1.1.1.1
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Qué significa: El resolver interno sirve un SPF interno (sin sentido para internet público), mientras que los resolvers públicos ven la política real.

Decisión: Si sistemas internos envían correo a internet y evalúan SPF (o decisiones de enrutamiento/firma dependen de ello), el split-horizon puede causar fallos autoinfligidos. Alinea zonas o asegura que los resolvers internos vean la misma vista pública de SPF.

Task 12: Confirm DKIM alignment when SPF is fragile

cr0x@server:~$ sed -n '1,120p' message.eml | egrep -i '^(from:|dkim-signature|authentication-results):'
From: Notifications 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Authentication-Results: mx.recipient.example; spf=softfail smtp.mailfrom=bounce.vendor.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Qué significa: DKIM pasa para example.com, y DMARC pasa aunque SPF esté en softfail porque SPF no se alinea (o es débil).

Decisión: Si no puedes arreglar SPF rápidamente (restricciones del proveedor, reenvíos, límites de includes), asegúrate de que DKIM sea robusto y esté alineado. Pero no dejes SPF roto para siempre; todavía impacta la confianza y algunas heurísticas de receptores.

Task 13: Validate that your SPF ends with a sane default

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | tail -n 1
-all"

Qué significa: La política termina en -all, una postura clara.

Decisión: Si termina en ~all y crees conocer todos los emisores, programa la migración a -all tras verificar logs en busca de emisores desconocidos.

Task 14: Inspect whether you’re using risky mechanisms (ptr, exists, macros)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ptr exists:%{i}._spf.example.com include:spf.mailvendor.example -all"

Qué significa: ptr y exists están en juego; se usan macros. Esto es SPF avanzado y a menudo frágil.

Decisión: A menos que tengas una necesidad muy específica y pruebes en múltiples receptores, elimina ptr y exists basados en macros. Sustitúyelos por ip4/ip6 explícitos o includes de proveedores estables.

Tres micro-historias corporativas desde las trincheras SPF

Micro-historia #1: El incidente causado por una suposición errónea

La compañía tenía una configuración limpia sobre el papel: DMARC en p=reject, DKIM firmado a través de un relay saliente central, y un registro SPF ordenado. Alguien aprobó una nueva plataforma de RRHH para enviar correos de incorporación. Era “solo correo”, así que compras avanzó más rápido que ingeniería.

La lista de verificación del proveedor decía: “Añade este registro SPF”. El administrador de RRHH hizo exactamente eso—añadiendo un segundo registro TXT en el apex con un nuevo v=spf1. Nadie lo notó porque los cambios DNS no alertan a nadie hasta que lo hacen.

En pocas horas, varios receptores empezaron a devolver permerror en SPF. La aplicación de DMARC entró en acción donde DKIM no estaba presente (algunos flujos transaccionales no firmaban—servidores de apps legacy seguían enviando directamente). Esos mensajes empezaron a rebotar. El síntoma visible no fue “SPF se rompió”. Fue “no llegan los restablecimientos de contraseña”. Así aprendes que el correo es parte de tu sistema de autenticación.

Ingeniería finalmente sacó un encabezado fallido, vio spf=permerror, y encontró dos respuestas TXT SPF. Fusionaron las políticas en un solo registro y eliminaron el duplicado. Luego descubrieron algo peor: la mitad del correo de la empresa ni siquiera pasaba consistentemente por el relay.

La solución real no fue solo fusionar TXT. Hicieron cumplir el enrutamiento saliente para que los servidores de apps no pudieran enviar directo a internet, y luego endurecieron SPF con -all. La suposición errónea no fue técnica; fue organizacional: “alguien más se encarga del correo”. En realidad, el correo te posee a ti.

Micro-historia #2: La optimización que salió mal

Un equipo de plataforma quiso “simplificar DNS” y reducir dependencias de proveedores. Reemplazaron varios includes con una lista achatada de rangos IP. Parecía profesional: menos consultas, evaluación determinista y checks SPF más rápidos. Incluso escribieron un script para generar el registro flatteneado.

Entonces vino el cambio. El script no se integró en CI/CD; vivía en un portátil. Funcionó hasta que la persona con el portátil se fue de vacaciones, y el proveedor rotó la infraestructura de envío. No es hipotético—las grandes plataformas de correo mueven espacio IP por capacidad y gestión de reputación.

En una semana aparecieron fallos SPF esporádicos. Solo algunos destinatarios se veían afectados porque el proveedor usaba piscinas distintas por región y tipo de mensaje. El equipo persiguió “filtrado específico del receptor” durante dos días antes de que alguien comparara la IP que fallaba con la lista flatteneada.

Lo que salió mal no fue el flattening en sí; fue hacerlo sin automatización, monitorización y cadencia de actualización. Revirtieron a includes del proveedor, luego reintrodujeron el flattening correctamente vía un job programado que obtenía rangos del proveedor y publicaba DNS a través del pipeline estándar, con rollback y visibilidad de diffs.

La lección: ingeniería de fiabilidad odia las “mejoras de una sola vez”. Si la mejora crea una nueva obligación de mantenimiento, automatízala o no la hagas.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Otra organización tenía una política: cada cambio DNS relacionado con correo (SPF, selectores DKIM, DMARC, MX) requería un pull request en infraestructura como código, con un linter y una simple comprobación canaria. Nadie lo llamaba glamuroso. Era mayormente YAML y discusiones sobre TTLs.

Un viernes, el gerente de cuenta de un proveedor envió una solicitud “urgente”: añadir un include al SPF antes del fin del día, o las campañas se retrasarían. El equipo de marketing escaló, porque por supuesto lo hicieron. El ingeniero de guardia añadió el cambio a través del PR habitual.

El linter de CI falló. Señaló que el nuevo include empujaría la evaluación SPF sobre el límite de consultas debido a una cadena existente. El ingeniero no necesitó ser un mago de deliverability; el proceso lo detectó.

Respondieron con una alternativa sensata: publicar un subdominio dedicado para el return-path de ese proveedor y mantener el SPF del apex ligero. El proveedor aceptó, las campañas salieron y nada se rompió. La práctica aburrida no solo “evitó una caída”. Evitó un incidente de viernes por la noche con público interesado.

Listas de verificación / plan paso a paso

Paso a paso: arreglar SPF de forma segura en producción

1. Inventario de emisores. Lista cada sistema que envía correo como tu dominio: suite corporativa, ticketing, marketing, facturación, monitorización, CRM, apps personalizadas y “aparatos misteriosos”.
2. Recopila evidencia real. Para cada emisor, captura al menos un mensaje entregado y registra:
   • Return-Path (dominio envelope-from)
   • IP que se conectó
   • Línea Authentication-Results
3. Decide tu estrategia de identidad. Prefiere:
   • Uno o dos subdominios return-path controlados para terceros
   • DKIM alineado con el From: visible
   • Política DMARC que coincida con tu nivel de confianza
4. Construye un único registro SPF por nombre de dominio. Fusiona entradas. Elimina proveedores muertos. Evita ptr. Evita cadenas largas de includes.
5. Cuenta las consultas antes de publicar. Los includes se expanden. Redirects cuentan. A/MX cuentan. Mantén margen.
6. Planifica TTL. Para cambios planificados, baja el TTL (por ejemplo, de 3600 a 300) al menos un ciclo de TTL antes del cambio. Luego súbelo tras la estabilidad.
7. Publica y verifica en los NS autoritativos. Comprueba que cada NS responda con el mismo registro.
8. Verifica con múltiples resolvers. No estás depurando “tu DNS”, estás depurando “la vista de internet sobre tu DNS”.
9. Monitorea resultados. Rastrear razones de rebote, señales agregadas DMARC si las tienes, y dashboards de entrega de proveedores. Busca permerrors SPF y aumento de softfails.
10. Pasa de ~all a -all con fecha límite. Pon una fecha. Haz que alguien lo coordine. Si no, ~all será tu política para siempre.

Checklist: pre-lanzamiento antes de añadir un nuevo include de proveedor

• ¿Conocemos el dominio envelope-from del proveedor y puede ser un subdominio personalizado bajo el nuestro?
• ¿Esta cadena de includes mantendrá las consultas DNS bajo 10 en el peor caso?
• ¿Estamos añadiendo por error un segundo registro SPF?
• ¿Está DKIM alineado y estable para ese flujo?
• ¿La aplicación de DMARC castigará errores inmediatamente?
• ¿Podemos revertir rápido (TTL bajo, registro previo guardado, pipeline de cambios listo)?

Checklist: mitigación de emergencia cuando SPF está rompiendo activamente

• Deja de hacer ediciones DNS paralelas desde múltiples consolas. Un único responsable de cambio.
• Si existen múltiples TXT SPF: fusiona y elimina duplicados primero.
• Si permerror por consultas: elimina el include más reciente y prueba de nuevo. Restaura la entrega, luego rediseña.
• Si apareció una IP saliente nueva: enruta el tráfico temporalmente por el relay conocido en lugar de ampliar SPF sin más.
• Si DMARC está rechazando y no puedes arreglar SPF rápido: asegúrate de que la firma DKIM alineada funcione para el flujo afectado (a menudo el bypass funcional más rápido).

Preguntas frecuentes

1) ¿Puedo tener múltiples registros SPF si los divido en cadenas TXT?

Puedes dividir un único registro SPF en múltiples cadenas entrecomilladas dentro del mismo RRset TXT (algunos proveedores DNS lo hacen automáticamente). No puedes publicar múltiples registros TXT separados que empiecen cada uno con v=spf1 para el mismo nombre.

2) ¿Cuál es la diferencia entre SPF fail y SPF softfail?

-all produce fail para emisores no autorizados; ~all produce softfail. Softfail es “no autorizado, pero acepta”. Algunos receptores tratan el softfail casi tan severamente como el fail cuando se combina con mala reputación o señales de aplicación DMARC.

3) ¿Por qué veo SPF pass pero aún así me rechazan?

Porque un pass de SPF no garantiza un pass de DMARC. DMARC requiere alineación entre el dominio From: y el dominio autenticado por SPF (o la alineación DKIM). También puedes ser rechazado por contenido, reputación, listas de bloqueo o políticas no relacionadas con SPF.

4) ¿SPF protege el encabezado From: visible?

No directamente. SPF autentica el dominio del envelope-from (Return-Path). DMARC es lo que vincula la autenticación (SPF/DKIM) con el From: visible mediante reglas de alineación.

5) ¿Cómo rompen SPF los reenviadores?

El reenvío clásico cambia la IP que se conecta a la IP del reenviador, pero el envelope-from sigue siendo el dominio del remitente original. A menos que el SPF original autorice la IP del reenviador (normalmente no), SPF falla. Esta es una de las razones por las que DKIM es crucial, y por las que algunos reenviadores implementan SRS (Sender Rewriting Scheme) para preservar compatibilidad con SPF.

6) ¿Debo usar los mecanismos “a” y “mx” en SPF?

Sólo si realmente entiendes y controlas a qué resuelven. Cuestan consultas DNS y pueden autorizar infraestructura que no debería enviar correo. Para egress controlado, ip4/ip6 explícitos o un include conocido del proveedor suelen ser más seguros.

7) ¿Qué es el “redirect” de SPF y por qué puede ser peligroso?

redirect= delega la evaluación a SPF de otro dominio. Es útil para centralizar política, pero añade dependencias y riesgo de consultas. Si el registro objetivo cambia o se rompe, tu dominio se rompe también.

8) ¿Cuánto tarda un arreglo SPF en “funcionar”?

Depende del TTL y del comportamiento de cacheo. En el mejor de los casos minutos si el TTL es bajo y los resolvers cooperan. En el peor puede ser horas. Algunos receptores cachean agresivamente. Planifica cambios con estrategia de TTL y espera una cola de propagación.

9) ¿SPF es suficiente por sí solo en 2026?

No. SPF por sí solo es insuficiente porque no sobrevive fiable al reenvío y no autentica el encabezado From: visible. Usa SPF más DKIM más DMARC. Trata SPF como necesario pero no suficiente.

10) ¿Cuándo debo pasar de ~all a -all?

Cuando hayas validado que todos los emisores legítimos están autorizados y tengas un plan de reversión. En la práctica: usa ~all brevemente durante descubrimiento, luego cambia a -all cuando tu inventario sea preciso. Pon una fecha límite para que realmente ocurra.

Conclusión: próximos pasos que puedes ejecutar hoy

Si SPF está rompiendo la entrega, normalmente no es porque SPF sea “difícil”. Es porque los cambios DNS no se revisan, los inventarios de emisores son ficticios y el onboarding de proveedores se trata como un ejercicio de copiar‑pegar. Arregla el proceso, no solo la cadena de texto.

Haz esto ahora:

1. Obtén un mensaje fallido real y extrae el dominio return-path y la IP del remitente.
2. Consulta el DNS autoritativo y confirma que existe exactamente un registro TXT v=spf1 para ese nombre de dominio.
3. Revisa el presupuesto de consultas; elimina mecanismos riesgosos e includes innecesarios.
4. Alinea identidades: usa subdominios return-path personalizados para proveedores y asegúrate de que DKIM se alinee con tu From: visible.
5. Controla los cambios para SPF/DKIM/DMARC en un pipeline con linting y rollback.

SPF no es glamuroso, pero es una de esas esquinas de la infraestructura donde “casi correcto” todavía falla en producción. Hazlo aburrido. Manténlo aburrido. Tus métricas de inbox te lo agradecerán.