Cómo resolver el límite de 10 búsquedas de SPF: Guía técnica para MSPs

Resumen ejecutivo El registro SPF de cada dominio está limitado a 10 consultas DNS — una restricción establecida en 2006 que no ha seguido el ritmo de los actuales entornos SaaS. Para los MSP que gestionan decenas de dominios de clientes, cada uno con sus propias herramientas de email, marketing, facturación y soporte, superar el límite es casi inevitable. Cuando ocurre, los emails legítimos fallan la autenticación en silencio, se rompe la alineación con DMARC y los tickets de soporte empiezan a acumularse. Esta guía explica a los MSP la mecánica del límite de búsquedas, cómo auditar dominios de clientes a gran escala, por qué las soluciones tradicionales como el flattening o la delegación de subdominios no funcionan, y cómo Dynamic SPF elimina por completo esta restricción — convirtiendo la gestión de SPF de una labor reactiva a un servicio automatizado y escalable.

Puntos clave

• Cada mecanismo include, a, mx, redirect, exists y ptr en SPF cuenta para el límite de 10 búsquedas — los includes anidados en registros de terceros consumen búsquedas ocultas que es fácil pasar por alto en una revisión manual.
• Un cliente medio que utilice siete o más herramientas SaaS ya está en el umbral o cerca de él, por lo que la simple adopción de un nuevo servicio puede provocar un PermError y arruinar la entregabilidad sin previo aviso.
• Google y Microsoft ahora aplican de forma explícita el cumplimiento de SPF para remitentes de alto volumen, haciendo del límite de búsquedas un requisito para entregar emails, más que una mera recomendación de buenas prácticas.
• El flattening de SPF es una molestia de mantenimiento porque los proveedores en la nube rotan direcciones IP de envío regularmente, lo que causa que los registros aplanados se queden obsoletos en toda la cartera.
• Dynamic SPF consolida todos los remitentes autorizados en un único include que se actualiza automáticamente y siempre se mantiene por debajo del límite, sin importar el número de servicios que use el cliente.
• Los MSP deben auditar cada dominio de cliente en la incorporación, marcar como en riesgo cualquier dominio con 8 o más búsquedas y considerar la resolución de SPF como la puerta de entrada para pasar a los clientes del seguimiento DMARC a la aplicación completa.

Un cliente añade HubSpot a su pila de marketing. Una semana después, las facturas del CFO empiezan a llegar a spam. Llegan los tickets de soporte y la raíz del problema resulta ser algo que nunca apareció en las listas de verificación iniciales: el registro SPF del cliente acaba de superar su décima consulta DNS, provocando un fallo de autenticación permanente que ninguna intervención en la bandeja de entrada solucionará. Para los MSP que gestionan decenas de dominios de clientes, cada uno con su propia mezcla de servicios de correo, plataformas CRM y herramientas de soporte, este escenario se da cada vez con más frecuencia. 

Plataformas como Red Sift OnDMARC abordan el problema mediante Dynamic SPF, que elimina por completo la restricción del límite de búsquedas. Pero comprender por qué existe el límite, cómo se incumple y qué errores cometen los enfoques tradicionales es conocimiento esencial para cualquier MSP que desee especializarse en DMARC.

Esta guía explica el límite de 10 búsquedas de SPF en términos prácticos, revisa los métodos tradicionales y sus desventajas y cubre los enfoques automatizados que permiten a los MSP escalar la autenticación del correo electrónico en las carteras de clientes sin toparse con este obstáculo.

• Qué significa en realidad el límite de 10 búsquedas de SPF
• Por qué los MSP superan el límite más que nadie
• Cómo auditar el registro SPF de un cliente
• Soluciones tradicionales y por qué fallan
• Dynamic SPF: la solución automatizada
• Cómo establecer un workflow de gestión SPF para tu MSP
• Preguntas frecuentes

SPF (Sender Policy Framework) permite a los propietarios de dominios declarar qué servidores de correo están autorizados a enviar emails en su nombre. Los servidores receptores revisan el registro SPF del dominio remitente y verifican si la dirección IP de origen está permitida. El protocolo funciona, pero lleva consigo una restricción definida en el RFC 7208: una evaluación SPF no debe requerir más de 10 mecanismos o modificadores que generen búsquedas adicionales en DNS [1].

El límite existe para proteger la infraestructura DNS. De no existir, un registro SPF mal formado o malicioso podría desencadenar cadenas de consultas DNS ilimitadas, consumiendo los recursos del servidor y provocando condiciones de denegación de servicio. El límite mantiene la evaluación predecible y controlada.

Un matiz crucial: el límite cuenta el número de mecanismos que requieren búsquedas, no el total de consultas DNS generadas [2]. Un mecanismo mx cuenta como uno de los 10, aunque genere múltiples consultas adicionales para resolver la dirección de cada servidor de correo. Esta distinción es clave al optimizar registros, porque reemplazar mx con entradas ip4 ahorra una búsqueda, independientemente del número de registros MX que tenga el dominio.

Cuando un servidor receptor supera el umbral de 10 búsquedas durante la evaluación, devuelve PermError, un fallo SPF permanente. La consecuencia depende de la configuración del receptor: algunos rechazan el mensaje directamente, otros lo envían a spam y algunos lo consideran neutro. En todos los casos, la alineación DMARC se rompe si SPF era el único mecanismo aprobado, lo que puede activar las políticas de cuarentena o rechazo más adelante.

El límite de búsquedas SPF se definió en 2006 y se codificó en el RFC 7208 en 2014, cuando lo común era que una organización usara uno o dos servicios de envío de correo. El entorno actual de SaaS es muy diferente. Un cliente medio puede requerir fácilmente includes de SPF para:

• Plataforma de correo (Google Workspace o Microsoft 365)
• Automatización de marketing (HubSpot, Marketo o Mailchimp)
• Sistema CRM (Salesforce)
• Soporte (Zendesk o Freshdesk)
• Facturación y cobros (QuickBooks, Xero)
• RRHH y selección (Greenhouse, BambooHR)
• Correo transaccional (SendGrid o Amazon SES)

Cada uno de estos servicios suele requerir su propio include en el registro SPF del dominio. Siete servicios suponen siete búsquedas antes de añadir los mecanismos a o mx del dominio. Añade una sola herramienta más y el registro supera el umbral.

Para los MSP, el problema se multiplica porque cada dominio de cliente presenta una variante de este desafío. Una cartera de 30 dominios son 30 combinaciones distintas de SaaS, 30 registros SPF a revisar y 30 posibles puntos de fallo. En cuanto el equipo IT o de marketing de un cliente añade un nuevo servicio sin avisar al MSP, el registro SPF puede superar el límite en silencio. Los emails empiezan a fallar de forma intermitente (porque el PermError solo se dispara cuando la evaluación llega a la 11ª búsqueda y no todos los receptores evalúan todos los mecanismos en todos los emails), lo cual dificulta la detección y reproducción del problema.

Google ahora exige cumplimiento SPF a las organizaciones que envían más de 5.000 emails diarios [3] y Microsoft ha introducido requisitos similares con directrices explícitas para mantener SPF dentro del límite de 10 búsquedas [4]. Para los MSP, el cumplimiento de remitente masivo ya no es opcional en ningún cliente que haga envíos a escala.

Antes de arreglar el problema, los MSP deben cuantificarlo. Una auditoría sistemática identifica cuántas búsquedas requiere el registro SPF de un cliente y de dónde viene el exceso.

Proceso paso a paso de auditoría:

1. Consulta el registro SPF usando una herramienta como el Comprobador de SPF de Red Sift o una consulta DNS por línea de comandos (dig TXT ejemplo.com) para obtener el registro en bruto
2. Mapea la cadena de includes expandiendo cada include recursivamente. Cada include añade una búsqueda y el registro incluido puede tener a su vez includes anidados
3. Cuenta todos los mecanismos que generan búsquedas incluyendo include, a, mx, redirect, exists y ptr
4. Identifica servicios sin uso cotejando los includes SPF frente a la infraestructura real de envío de emails del cliente. Servicios inactivos que ya no envían mensajes siguen consumiendo búsquedas
5. Documenta el contador actual y marca cualquier dominio con 8 o más búsquedas como en riesgo (a dos servicios de romperse)
6. Revisa la profundidad de anidamiento ya que algunos SPF de terceros pueden contener varios includes anidados. Un solo include:tercero.com puede consumir tres o cuatro búsquedas al expandirse del todo

Al auditar toda la cartera de clientes, se revela la magnitud del problema. La mayoría de los MSP descubren que una parte importante de los dominios de sus clientes están por encima del límite o a solo una alta de alcanzar el máximo.

Los MSP que se topan por primera vez con el límite de 10 búsquedas suelen recurrir a varias soluciones habituales. Todas tienen limitaciones que impiden su uso a gran escala o en producción.

El flattening sustituye los includes por sus direcciones IP resultantes (ip4 e ip6), reduciendo el conteo de búsquedas a cero para esos servicios. Funciona en teoría, pero en la práctica falla porque los proveedores cloud rotan sus IPs de envío regularmente. Cuando un proveedor como Google añade infraestructura, el registro aplanado se queda obsoleto y los emails legítimos fallan la autenticación.

El flattening manual obliga al MSP a monitorizar los rangos IP de cada proveedor y actualizar los DNS siempre que haya cambios. En una cartera de 30 dominios con proveedores diferentes, esto se vuelve insostenible. Con que se deje pasar una rotación, pueden fallar masivamente los envíos.

Publicar más de un registro SPF TXT para un dominio viola la especificación de SPF [1]. Los receptores que detectan varias entradas deben devolver PermError, por lo que este enfoque rompe activamente la autenticación en vez de resolver el problema.

Desplegar servicios de correo en subdominios independientes (marketing.example.com, soporte.example.com) distribuye las búsquedas SPF en varios registros. Reduce el conteo por subdominio, pero complica la alineación DMARC, exige ajustes en el Return-Path y genera una complejidad operacional que escala mal para muchos dominios MSP.

Algunos MSP ven que no todos los receptores aplican estrictamente las 10 búsquedas. Esto lleva a una actitud de "parece que funciona", donde el registro por encima del límite sigue en producción. El riesgo es que el comportamiento puede variar entre receptores y cambiar sin aviso. Tanto Google como Microsoft mencionan el cumplimiento de SPF en sus requisitos de envío masivo, por lo que este enfoque es cada vez más arriesgado para la entregabilidad.

Dynamic SPF adopta un enfoque totalmente diferente al límite de búsquedas. En lugar de intentar cumplir el límite de 10 mediante gestión manual, Dynamic SPF consolida todas las fuentes autorizadas de envío en un único include mantenido automáticamente por debajo del umbral.

Cómo funciona:

1. Monitorización continua: la plataforma rastrea los rangos IP de todos los servicios de envío autorizados (Google Workspace, Microsoft 365, Salesforce, HubSpot y otros) en tiempo real
2. Consolidación inteligente: los includes basados en dominio se resuelven a sus IP actuales y se combinan en un único registro optimizado
3. Actualizaciones automáticas: cuando un proveedor cambia su infraestructura de envío, el registro Dynamic SPF se actualiza en minutos, sin intervención manual en DNS
4. Un único include: el registro SPF del cliente apunta a un solo Dynamic SPF, consumiendo solo una búsqueda sin importar cuántos servicios estén autorizados

Así, los MSP pueden añadir nuevos servicios de correo a los dominios de clientes sin preocuparse por el conteo de búsquedas. Un cliente con quince servicios usa la misma búsqueda única que uno con tres. La barrera técnica que antes impedía la aplicación de DMARC desaparece.

Para MSP que evalúan plataformas DMARC, la función Dynamic SPF debe ser un criterio esencial. Las diferencias entre protocolos SPF, DKIM y DMARC son importantes, pero en la práctica lo fundamental es si la plataforma puede gestionar el límite de búsquedas a escala en una cartera variada de clientes.

Solucionar el límite de búsquedas SPF en un dominio es fácil. Hacerlo en toda una cartera exige un proceso repetible.

Workflow recomendado para MSP:

1. Auditoría de cartera: mide el número de búsquedas SPF en todos los dominios en el onboarding. Marca como en riesgo cualquier dominio con 8 o más
2. Prioriza por impacto: soluciona primero los dominios que ya superen el límite, después los de mayor riesgo. Los clientes con DMARC en p=quarantine o p=reject tienen máxima prioridad por el impacto directo en la entregabilidad
3. Despliega Dynamic SPF: migra los dominios a una plataforma con gestión Dynamic SPF. El programa de partners de Red Sift para MSP proporciona infraestructura multi-inquilino pensada para proveedores de servicios que gestionan muchos dominios a la vez
4. Establece control de cambios: pide que cualquier alta de nuevo servicio de email pase por el MSP. Así se evita que los equipos del cliente añadan SaaS que antes rompían SPF
5. Supervisa de forma continua: usa alertas automáticas para detectar nuevas fuentes, cambios de configuración o fallos de evaluación SPF en la cartera
6. Reporta a los clientes: incluye métricas de salud SPF en los informes periódicos. Tasas de autenticación, cambios en el inventario de remitentes y el uso de búsquedas demuestran el valor aportado

Los MSP que estandarizan este workflow reducen mucho el coste por dominio. La auditoría inicial y migración requieren esfuerzo, pero después el mantenimiento pasa a ser automatizado en vez de reactivo.

La gestión SPF encaja de forma natural en los paquetes escalonados de servicios DMARC. El límite de búsquedas suele ser justo la barrera técnica que impide a los clientes pasar de la monitorización (p=none) a la aplicación (p=reject). Resolver las rupturas de SPF en toda la cartera desbloquea el camino a la aplicación total, que es el nivel de mayor valor en la gestión de autenticación de correo.

[1] Kitterman, S. "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1." IETF RFC 7208, 2014. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

[2] Mailhardener. "The SPF lookup limit explained." Blog de Mailhardener, 2024. https://www.mailhardener.com/blog/spf-lookup-limit-explained

[3] Google. "Email sender guidelines." Google Workspace Admin Help, 2024. https://support.google.com/a/answer/81126

[4] Microsoft Defender for Office 365 Team. "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders." Microsoft Tech Community, 2025. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

El servidor de correo receptor devuelve PermError, un fallo SPF permanente. Según la política del receptor y la configuración de DMARC del dominio, esto puede causar que los mensajes sean rechazados, enviados a spam o tratados como no autenticados. El fallo es intermitente porque solo se da cuando la evaluación llega realmente a la búsqueda número 11, lo que varía entre mensajes y receptores.

El flattening sustituye includes por IPs estáticas, que reducen búsquedas pero generan una carga de mantenimiento. Los proveedores en la nube rotan las IPs a menudo, por lo que los registros aplanados se quedan obsoletos y fallan en la autenticación. Para un solo dominio puede ser manejable, pero en una cartera de clientes con múltiples proveedores, el aplanado manual no es escalable.

Dynamic SPF automatiza el proceso de consolidación y mantenimiento. La plataforma monitoriza los rangos de IP del proveedor y actualiza el registro SPF automáticamente ante cualquier cambio. El flattening tradicional es una foto puntual que requiere actualizaciones manuales; Dynamic SPF es exacto y en tiempo real, sin intervención.

Google exige cumplimiento SPF para envíos masivos (más de 5.000 mensajes al día) [3]. Microsoft indica explícitamente que hay que mantener SPF dentro del límite como parte del envío de alto volumen [4]. Ambas plataformas filtran cada vez con mayor rigor los mensajes no conformes.

Empieza por los dominios que ya superen el límite (devolviendo PermError), luego aborda los que estén en 8-9 búsquedas (a una alta de fallar). Dentro de estos grupos, prioriza los clientes con políticas DMARC (p=quarantine o p=reject), porque los fallos SPF afectan de inmediato a la entregabilidad en esos dominios.