Defaults.Exposed › Informes

¿Por qué falla mi SPF? El problema de los 10 lookups para emisores del Reino Unido y la UE con herramientas SaaS (2026)

Publicado 2026-07-09

Cifras a 2026-06-29 · metodología v7. Datos del censo agregado de 261 millones de dominios evaluados. Ver cómo evaluamos.

Cuando SPF falla en una empresa que usa herramientas SaaS en el Reino Unido o la UE, la causa más probable es una única regla RFC que nunca ha sido necesario tener en cuenta: a partir de 10 consultas DNS, SPF no devuelve “fail” — devuelve PermError, lo que significa que el registro se trata como si no existiera. Al menos 797.263 dominios ya han cruzado esa línea. Otros 2.119.539 están exactamente en 9–10 lookups — una herramienta nueva basta para caer por el mismo precipicio.

¿Por qué se rompe SPF al añadir una herramienta SaaS?

SPF funciona listando los servidores de correo autorizados a enviar en nombre de tu dominio. Las empresas modernas no gestionan sus propios servidores de correo: usan Google Workspace para el correo interno, Mailchimp para campañas, HubSpot para secuencias de ventas, Pipedrive para el seguimiento CRM. Cada plataforma entrega una línea include: que hay que pegar en el DNS.

El problema: cada include: es en sí mismo una consulta DNS. Y cada registro dentro de ese include puede desencadenar más lookups de forma recursiva. RFC 7208 §4.6.4 establece un límite estricto de diez. A partir de diez, el servidor de correo receptor deja de evaluar y devuelve PermError — y un PermError no es un fallo suave que acaba en spam. Significa que el registro SPF se trata como ausente. La autenticación del correo falla en la capa SPF.

Esto no es visible en el panel DNS. El contador solo se activa durante la evaluación en vivo. Se pueden tener tres líneas include: en el registro visible y estar a doce lookups de profundidad, porque el registro SPF de cada proveedor contiene sus propios sub-includes.

¿Cuántos dominios ya han superado el límite?

Al menos 797.263. Ese es el recuento tras resolver cada destino SPF include: referenciado 100 veces o más — 10.842 destinos distintos que cubren el 95,2% de todas las referencias include — y calcular la cadena completa de cada dominio. El recuento superficial (contando solo las líneas visibles en un registro) arroja aproximadamente 7958. La cifra evaluada por cadena es 100 veces mayor, porque casi todo el daño es invisible dentro de los destinos include.

La situación que más afecta a las empresas europeas:

Proveedores de hosting europeos y configuraciones SPF deficientes

El proveedor de hosting de origen importa, porque algunos configuran valores SPF predeterminados que ya consumen varios de los diez lookups antes de conectar una sola herramienta SaaS.

Entre los mayores proveedores de hosting usados por dominios europeos en nuestro censo:

IONOS destaca negativamente: solo 1,0% de los dominios alojados en IONOS tienen DMARC activo, lo que significa que la gran mayoría carece por completo de autenticación de remitente. Los dominios de OVH se defienden mejor en la configuración SPF estricta (43,7%), pero caen al 2,2% en aplicación DMARC — SPF solo, sin DMARC que lo vincule a la cabecera From:, solo protege el sobre, no lo que ve el destinatario.

Microsoft 365 es la excepción positiva: 85,0% de los dominios alojados en Microsoft usan SPF estricto, en gran parte porque el asistente de flujo de correo de Microsoft establece -all por defecto. Google Workspace establece ~all (softfail) por defecto, dejando al 92% de sus dominios sin protección estricta.

Cómo diagnosticar el fallo de SPF en menos de 60 segundos

La comprobación más rápida es una herramienta gratuita que evalúa la cadena completa de lookups, no solo el registro visible. Ejecuta nslookup -type=TXT tudominio.com en la línea de comandos y cuenta cada include: que aparezca. Luego busca cada uno de esos registros y cuenta los suyos. Si se acaban los dedos antes que los includes, estás en la zona de peligro.

Un enfoque más fiable: comprueba tu dominio aquí — el escáner evalúa la cadena resuelta completa, señala los PermError y muestra qué mecanismos están consumiendo tu presupuesto de lookups.

Tres posibles resultados diagnósticos:

• PermError — ya superas diez. Cada correo que envías falla la comprobación SPF en el receptor.
• En 9–10 lookups — estás al borde del precipicio. La próxima integración SaaS te hará caer.
• Softfail (~all) en vez de hardfail (-all) — estás por debajo del límite, pero el registro está configurado de forma demasiado permisiva para ofrecer protección real. Ver el informe de configuraciones incorrectas de SPF para el panorama completo sobre -all vs ~all.

Cómo corregir SPF cuando se usan múltiples herramientas SaaS

Hay tres enfoques, ordenados por permanencia:

1. Auditar y podar. Empieza listando todos los include: de tu registro actual. Elimina cualquier plataforma que ya no uses: antiguos ESP, herramientas CRM de contratos anteriores, plataformas que probaste pero abandonaste. Es gratuito y a menudo recupera varios lookups. Cada include: eliminado puede suprimir 1–3 sub-lookups.

2. Aplanar el registro SPF. El aplanamiento SPF resuelve todos los destinos include: en sus rangos de IP subyacentes y los escribe directamente en el registro como mecanismos ip4: e ip6:. Los mecanismos IP no desencadenan lookups, de modo que un registro aplanado puede listar docenas de fuentes de envío y mantenerse en cero lookups. El inconveniente: hay que re-aplanar cada vez que un proveedor actualiza sus IPs de envío, lo cual sucede sin previo aviso. La mayoría de las organizaciones usan un servicio de aplanamiento gestionado (PowerDMARC, EasyDMARC, Dmarcian, entre otros) o construyen un flujo de trabajo de monitoreo.

3. Usar macros SPF. Las macros de RFC 7208 permiten construir registros que realizan una sola consulta DNS por verificación y responden dinámicamente, en lugar de encadenar includes. Las macros requieren soporte del proveedor DNS y cierto esfuerzo de implementación, pero son la solución arquitectónicamente limpia para organizaciones con muchos emisores SaaS.

Tras corregir SPF, combínalo con la aplicación de DMARC — SPF sin DMARC solo autentica el remitente del sobre, no la dirección From: de la cabecera que ven los destinatarios.

Preguntas frecuentes

¿Por qué mi registro SPF pasa el test de mi herramienta DNS pero falla en las cabeceras del correo? La mayoría de las herramientas de lookup DNS cuentan solo los mecanismos visibles en tu propio registro, no los sub-lookups que esos mecanismos desencadenan. Puedes tener dos líneas include: y estar por encima del límite si el registro de cada proveedor contiene varios más. Solo una herramienta de evaluación por cadena (o un servidor de correo receptor) cuenta la profundidad total. Comprueba tu dominio para ver el recuento real de la cadena.

¿Que el SPF falle significa que mis correos van al spam? PermError (demasiados lookups) significa que la capa SPF de la autenticación devuelve un no-resultado — efectivamente ausente. DMARC evalúa tanto SPF como DKIM; si DKIM pasa, DMARC puede igualmente pasar a pesar del PermError de SPF. Si ninguno pasa, DMARC falla, y el resultado depende de tu política DMARC. Con p=none, el correo se entrega igualmente, pero el fallo queda registrado. Con p=quarantine o p=reject, el correo se filtra o se rebota. Corrige SPF para no depender solo de DKIM.

¿Cuántos lookups consume una pila SaaS típica? El registro SPF en el p99 de nuestro censo ya se sitúa en 9 lookups — justo en el límite — antes de añadir nada. Un registro de Google Workspace añade 3–4 lookups; Mailchimp añade 1–2; HubSpot añade 1–3 según su configuración actual. Tres herramientas habituales más la configuración predeterminada de tu proveedor de hosting suelen ser suficientes para superar diez.

¿Es seguro el aplanamiento SPF? Sí, siempre que se mantenga actualizado. El aplanamiento convierte las cadenas include: en rangos de IP estáticos — si un proveedor rota sus IPs de envío y no se re-aplana, se empezará a rechazar su correo. La mayoría de las organizaciones usan un servicio de aplanamiento gestionado que monitorea los cambios de IP en lugar de hacerlo manualmente.

Mi SPF lleva años así — ¿por qué empieza a fallar ahora? Porque tus proveedores actualizaron sus registros SPF, no el tuyo. Cada vez que una plataforma SaaS añade un nuevo rango de IPs de envío o anida otro include, el coste de tu cadena sube sin ningún cambio de tu parte. El límite de 10 lookups se evalúa en vivo en el momento de recibir el mensaje, por lo que un cambio de proveedor un martes por la mañana puede romper tu SPF para el martes por la tarde.

¿Corregir SPF mejora la entregabilidad del correo? Elimina una fuente de fallos de autenticación, que es un requisito previo para una entrega consistente — especialmente desde que Google y Yahoo exigen ahora la alineación DMARC para los emisores masivos. SPF solo no es el panorama completo: combínalo con DKIM y DMARC para una autenticación completa del correo.

Comprueba tu SPF gratis

Si no estás seguro de si tu registro SPF supera el límite de lookups — o está configurado demasiado débilmente para proteger tu dominio — realiza una comprobación gratuita. Evalúa la cadena resuelta completa y te muestra exactamente dónde se gasta el presupuesto.

Comprobar tu dominio → · Corregir SPF → · El informe SPF PermError → · Informe de configuraciones incorrectas de SPF → · El modelo de madurez de adopción de SPF → · Corregir DMARC → · Solo datos agregados. Datos almacenados y procesados en la UE.