La mayoría de las organizaciones descubren los límites de los registros SPF solo después de que la autenticación falla. Para entonces, el correo electrónico legítimo ya está rebotando, llegando al spam o fallando silenciosamente sin errores visibles. El límite de 10 consultas DNS no es una recomendación—es un límite técnico estricto que termina la evaluación SPF y devuelve un error permanente, causando típicamente el fallo de alineación DMARC incluso cuando otra autenticación pasa.

El sesenta y tres por ciento de las organizaciones que utilizan tres o más plataformas de correo electrónico de terceros exceden el límite de consultas SPF dentro de los 18 meses posteriores a la implementación inicial, según datos recientes de referencia de autenticación de correo electrónico. El fallo es estructural: cada remitente autorizado agregado a SPF a través de mecanismos include: aumenta el recuento de consultas DNS, y la mayoría de las organizaciones alcanzan el límite mucho antes de darse cuenta de que están contando las consultas incorrectamente.

Este artículo explica cómo funcionan los límites de consultas SPF, qué se rompe cuando los excedes, cómo identificar el fallo antes de que impacte la entrega, y cómo reestructurar SPF para mantenerse dentro de los límites técnicos mientras se mantiene la cobertura de proveedores.

I. ¿Qué es el Límite de Consultas SPF?

SPF (Sender Policy Framework) valida que el servidor de correo remitente está autorizado para enviar correo electrónico en nombre de un dominio. El servidor receptor realiza consultas DNS para resolver el registro SPF y evaluar la cadena de autorización. RFC 7208 establece un límite estricto de 10 consultas DNS por evaluación SPF para prevenir abusos, recursión infinita y ataques de amplificación DNS.

Cuando una evaluación SPF excede 10 consultas DNS, el servidor receptor deja de procesar y devuelve permerror. Esto es un fallo permanente, no una condición temporal. El resultado se trata como un fallo de SPF en la mayoría de las implementaciones, lo que significa:

• La alineación DMARC falla incluso si DKIM pasa, porque SPF no pasó y no se alineó.
• Las señales de reputación se degradan porque los proveedores de buzones de correo ven inconsistencia en la autenticación.
• La entrega se vuelve impredecible porque algunos servidores receptores filtran silenciosamente, otros rechazan, y muchos no muestran el fallo en los mensajes de rebote.

El límite es fijo. No escala con el tamaño del dominio, el volumen de correo electrónico o la complejidad del negocio. Agregar un remitente autorizado más cuando ya estás en 10 consultas rompe todo el registro SPF.

II. Cómo se Cuentan las Consultas DNS

El conteo de consultas SPF a menudo se malinterpreta porque no todos los mecanismos en un registro SPF activan una consulta DNS. Los siguientes mecanismos sí cuentan hacia el límite de 10 consultas:

• include: – Cada mecanismo include: activa al menos una consulta, y si el registro incluido contiene include:, a, mx o ptr adicionales, esos cuentan recursivamente.
• a – Consulta el registro A del dominio.
• mx – Consulta el registro MX del dominio, y cada destino MX requiere una consulta de registro A adicional.
• ptr – Consulta el registro PTR (obsoleto y no debe usarse).
• redirect= – Activa una consulta, más cualquier consulta dentro del registro redirigido.
• exists: – Consulta el registro A para el dominio especificado.

Los siguientes mecanismos no cuentan:

• ip4: – Dirección IP estática, no requiere consulta DNS.
• ip6: – Dirección IPv6 estática, no requiere consulta DNS.
• all – Mecanismo que define la acción predeterminada, sin consulta DNS.

Ejemplo: Explosión Oculta de Consultas

Un registro SPF aparentemente simple puede exceder el límite rápidamente:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.salesforce.com ~all

Recuento de consultas aparente: 5
Recuento de consultas real: 12+

He aquí por qué:

• include:_spf.google.com → 3 consultas (Google usa includes anidados)
• include:sendgrid.net → 2 consultas
• include:spf.protection.outlook.com → 2 consultas
• include:mail.zendesk.com → 2 consultas
• include:_spf.salesforce.com → 3 consultas

Total: 12 consultas. Este registro devolverá permerror y fallará la autenticación SPF.

Las organizaciones a menudo asumen que cinco declaraciones include: equivalen a cinco consultas. No es así. Cada dominio incluido puede expandirse en múltiples consultas anidadas, y esas cuentan hacia el total.

III. Qué se Rompe Cuando Excedes el Límite

1. SPF Devuelve permerror

Cuando el servidor receptor alcanza el límite de 10 consultas, la evaluación SPF se detiene y devuelve permerror. Esto se registra en el encabezado Authentication-Results como:

spf=permerror (too many DNS lookups)

El correo electrónico no se beneficia de la autenticación SPF. Si DKIM no está presente o no se alinea, DMARC falla.

2. La Alineación DMARC Falla

DMARC requiere que SPF o DKIM pasen y se alineen con el dominio From:. Si SPF devuelve permerror, no puede alinearse. Si DKIM falta, no está firmado o está desalineado, DMARC falla completamente.

Con p=quarantine o p=reject, esto significa que el correo electrónico es filtrado o bloqueado. Con p=none, el fallo es invisible pero aún se registra en informes agregados, degradando la reputación con el tiempo.

3. Filtrado Silencioso

No todos los proveedores de buzones de correo rechazan correos electrónicos con SPF permerror. Algunos degradan silenciosamente la entrega:

• El correo electrónico llega al spam en lugar de la bandeja de entrada.
• El correo electrónico se retrasa o se limita.
• El correo electrónico se entrega pero se marca como potencialmente sospechoso en el cliente de correo del destinatario.

Debido a que el fallo es silencioso, las organizaciones a menudo no se dan cuenta de que SPF está roto hasta que las tasas de queja aumentan, el compromiso disminuye o una campaña importante falla.

4. Impacto Específico del Proveedor

El impacto varía según el proveedor:

• Gmail: Trata permerror como una señal de fallo pero puede seguir entregando si DKIM pasa y la reputación del dominio es fuerte. Sin embargo, la ubicación en la bandeja de entrada se degrada con el tiempo.
• Microsoft 365: Trata permerror como fallo de SPF. Si DKIM no se alinea, el correo electrónico se filtra o rechaza dependiendo de la política y reputación.
• Yahoo, AOL: Aplicación estricta. permerror a menudo resulta en rechazo o filtrado de spam.
• Listas de correo, reenviadores: SPF se rompe durante el reenvío porque el remitente del sobre no se alinea. Si el registro SPF original ya está en permerror, el correo electrónico reenviado no tiene cobertura de autenticación.

5. Los Informes DMARC Muestran el Fallo

Si tu política DMARC está configurada en p=none con informes agregados habilitados, verás permerror en el campo de resultado spf de los informes agregados DMARC. El informe muestra:

<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>permerror</result>
  </spf>
</auth_results>

El fallo se registra, pero si no estás revisando activamente los informes DMARC, no lo verás. Por eso muchas organizaciones exceden el límite SPF sin darse cuenta hasta que surgen problemas de entrega.

IV. Cómo Identificar el Recuento de Consultas SPF Antes de que se Rompa

Conteo Manual de Consultas SPF

Puedes contar manualmente las consultas SPF expandiendo recursivamente cada mecanismo include: y contando todos los mecanismos include:, a, mx, redirect= y exists: encontrados.

Proceso paso a paso:

1. Consulta tu registro SPF:

   dig TXT example.com

2. Para cada mecanismo include:, consulta el dominio incluido:

   dig TXT _spf.google.com
   dig TXT sendgrid.net

3. Cuenta todos los mecanismos que activan consultas DNS en el registro principal y todos los registros anidados.

Este proceso consume tiempo y es propenso a errores, especialmente cuando los proveedores cambian sus registros SPF sin aviso.

Validación Automatizada de Consultas SPF

Usa un verificador de registros SPF que cuente automáticamente las consultas DNS e identifique qué mecanismos contribuyen al total. Herramientas como:

• Skysnag Domain Checker – Escanea tu dominio, cuenta las consultas SPF y marca registros que exceden o se acercan al límite de 10 consultas.
• dig + recursión manual (técnico pero completo).
• Validadores SPF de terceros (varían en precisión; algunos no cuentan correctamente las consultas anidadas).

Skysnag Domain Checker muestra:

• Recuento de consultas actual
• Qué mecanismos include: se expanden en múltiples consultas
• Si el registro ya está en permerror
• Recomendaciones para aplanar o reestructurar

V. Cómo Solucionar Problemas de Límite de Consultas SPF

1. Reemplazar include: con ip4: o ip6: Cuando Sea Posible

Si un remitente de terceros proporciona un rango de IP estático, reemplaza el mecanismo include: con direcciones IP explícitas:

Antes:

v=spf1 include:mail.vendor.com ~all

Después:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.5 ~all

Esto elimina las consultas DNS para ese remitente. Sin embargo, este enfoque solo funciona si el proveedor usa IPs estáticas y no rota infraestructura frecuentemente. Muchas plataformas SaaS rotan IPs, haciendo impracticables las listas estáticas.

2. Aplanar el Registro SPF

El aplanamiento SPF resuelve todos los mecanismos include: en sus direcciones IP finales y los consolida en un solo registro. Esto reduce las consultas DNS pero crea riesgo operacional:

• Los cambios de IP del proveedor rompen la autenticación. Si un proveedor agrega o rota direcciones IP, tu registro SPF aplanado queda desactualizado, y el correo electrónico legítimo falla la autenticación.
• Actualizaciones manuales requeridas. Debes monitorear los registros SPF de los proveedores y actualizar tu registro aplanado cuando ocurran cambios.
• Sin notificación cuando los proveedores cambian. La mayoría de los proveedores no anuncian cambios en registros SPF, así que solo descubres el fallo cuando el correo electrónico comienza a rebotar.

El aplanamiento funciona como solución a corto plazo pero requiere mantenimiento y monitoreo continuos.

3. Usar Subdominios para Segmentar Remitentes

Mueve flujos de correo electrónico específicos a subdominios dedicados y crea registros SPF separados para cada uno:

Ejemplo:

• example.com → Autenticado para correo electrónico comercial principal (Microsoft 365)
• marketing.example.com → Autenticado para plataformas de marketing (SendGrid, Mailchimp)
• support.example.com → Autenticado para herramientas de soporte (Zendesk, Intercom)

Cada subdominio tiene su propio registro SPF, y cada registro permanece bajo el límite de 10 consultas. Este enfoque funciona bien para organizaciones con segmentación clara de remitentes, pero requiere:

• Soporte de la plataforma de correo electrónico para envío desde subdominio (no todas las plataformas lo soportan).
• Configuración DNS para cada subdominio.
• Alineación de política DMARC a través de subdominios (si no está configurada, DMARC puede fallar).

4. Eliminar Mecanismos include: No Utilizados o Redundantes

Muchos registros SPF incluyen remitentes que ya no están en uso:

• Plataformas de marketing heredadas
• Herramientas de soporte desmanteladas
• Declaraciones include: duplicadas (p. ej., dos entradas para el mismo proveedor)
• Proveedores que fueron probados pero nunca desplegados

Audita tu registro SPF y elimina cualquier mecanismo include: que no corresponda a remitentes activos. Usa Skysnag Protect para identificar qué remitentes están enviando correo electrónico activamente y qué entradas include: no se usan.

5. Consolidar Proveedores Cuando Sea Posible

Si usas múltiples plataformas de marketing, herramientas de soporte o proveedores de correo electrónico transaccional, consolida en menos proveedores. Esto reduce el número de mecanismos include: y simplifica la gestión de SPF.

Por ejemplo:

• Usa una plataforma de correo electrónico transaccional en lugar de tres.
• Consolida el correo electrónico de marketing a través de un solo ESP.
• Enruta el correo electrónico de soporte a través de un sistema de tickets.

Esta es una decisión comercial, no solo una solución técnica, pero es la forma más sostenible de reducir la complejidad de SPF.

VI. Límite de Consultas SPF y Aplicación DMARC

Cuando SPF excede el límite de consultas y devuelve permerror, la evaluación DMARC depende de si DKIM pasa y se alinea.

Escenario 1: SPF permerror + DKIM Pasa + DKIM se Alinea

DMARC pasa porque DKIM proporciona la autenticación y alineación requeridas. El fallo de SPF no bloquea la entrega, pero debilita la postura de autenticación general.

Escenario 2: SPF permerror + DKIM Falla o Falta

DMARC falla. Si tu política está configurada en p=quarantine o p=reject, el correo electrónico se filtra o rechaza durante la entrega SMTP cuando el servidor receptor respeta la política. Si tu política es p=none, el fallo se registra pero no activa la aplicación.

Escenario 3: SPF permerror + DKIM Pasa pero Desalineado

DMARC falla. DKIM debe alinearse con el dominio From: (ya sea alineación estricta o relajada). Si DKIM pasa pero no se alinea, y SPF está en permerror, DMARC no tiene ruta de autenticación válida.

El modo de fallo más común es el Escenario 2—SPF se rompe, DKIM no está configurado para el remitente de terceros, y DMARC falla completamente.

VII. Cómo Monitorear el Recuento de Consultas SPF con el Tiempo

Los registros SPF cambian a medida que agregas o eliminas remitentes autorizados. Monitorear el recuento de consultas previene fallos de autenticación antes de que impacten la entrega.

Usa Skysnag Protect para Monitoreo Continuo de SPF

Skysnag Protect monitorea continuamente tu registro SPF y rastrea el recuento de consultas DNS. Cuando un proveedor actualiza su registro SPF y tu recuento total de consultas aumenta, Skysnag te alerta antes de que se exceda el límite de 10 consultas.

Cómo funciona:

1. Skysnag escanea tu registro SPF diariamente.
2. Rastrea el recuento de consultas para todos los mecanismos include:.
3. Te alerta cuando el recuento de consultas se acerca o excede el límite.
4. Proporciona recomendaciones para aplanar, segmentación de subdominio o consolidación de IP.

Esto previene el modo de fallo silencioso donde SPF se rompe y solo lo descubres cuando la entrega se degrada.

Comienza a monitorear tu registro SPF con Skysnag Protect.

VIII. Alternativas a SPF: MTA-STS y Autenticación Solo DKIM

Algunas organizaciones eliminan SPF por completo y confían en DKIM para la autenticación. Esto evita el límite de consultas pero elimina el papel de SPF en prevenir la suplantación a nivel de sobre.

Autenticación Solo DKIM

DKIM autentica el cuerpo del mensaje y los encabezados usando una firma criptográfica. No valida el remitente del sobre (la dirección usada durante SMTP), por lo que no previene ciertos tipos de suplantación. Sin embargo, DKIM no tiene límite de consultas, no se rompe durante el reenvío y proporciona garantías criptográficas más fuertes que SPF.

Si despliegas autenticación solo DKIM:

• Asegúrate de que DKIM esté configurado para todos los remitentes autorizados.
• Usa DMARC con aspf=r (alineación relajada) para permitir flexibilidad de subdominio.
• Monitorea informes agregados DMARC para verificar la cobertura DKIM.

MTA-STS para Seguridad de Transporte

MTA-STS (Mail Transfer Agent Strict Transport Security) impone entrega cifrada pero no reemplaza SPF o DKIM. Asegura que el correo electrónico se entregue por TLS, previniendo ataques de intermediario, pero no autentica al remitente.

MTA-STS funciona junto con DMARC, no como sustituto.

IX. Errores Comunes con el Límite de Consultas SPF

1. Asumir que los Registros SPF de Proveedores Nunca Cambian

Los proveedores actualizan sus registros SPF para agregar infraestructura, rotar IPs o cambiar proveedores de alojamiento. Si aplanas tu registro SPF y no monitoreas los cambios de proveedores, la autenticación se rompe silenciosamente.

2. Contar Declaraciones include: en Lugar de Consultas DNS

Un registro SPF con 5 mecanismos include: puede activar más de 12 consultas DNS porque cada registro incluido puede contener include:, a o mx anidados adicionales.

Siempre cuenta las consultas DNS recursivas totales, no solo los mecanismos de nivel superior.

3. Usar Mecanismos ptr

El mecanismo ptr está obsoleto e ineficiente. Activa consultas DNS inversas y aumenta el recuento de consultas. No uses ptr en registros SPF modernos.

4. No Probar Cambios SPF Antes de Publicar

Publicar un cambio SPF sin probar puede romper la autenticación para todo el correo electrónico. Usa un dominio de prueba o subdominio para validar el registro antes de aplicarlo a producción.

5. Ignorar Informes Agregados DMARC

Los informes DMARC muestran fallos de SPF permerror, pero muchas organizaciones no revisan informes regularmente. Configura monitoreo a través de Skysnag para mostrar problemas SPF antes de que impacten la entrega.

X. Conclusiones clave

Los límites de búsqueda SPF no son flexibles. El límite de 10 búsquedas DNS es una restricción técnica fija, y excederlo devuelve permerror, lo que rompe la autenticación SPF y a menudo causa fallas en DMARC.

Las organizaciones que utilizan múltiples plataformas de correo electrónico de terceros comúnmente exceden el límite sin darse cuenta porque las búsquedas DNS se cuentan recursivamente, y los registros SPF de los proveedores cambian sin previo aviso.

La falla suele ser silenciosa. El correo electrónico puede seguir siendo entregado, pero termina en spam, es limitado o degrada la reputación con el tiempo. Los informes agregados de DMARC muestran el resultado permerror, pero si los informes no se monitorean activamente, la falla pasa desapercibida hasta que surgen problemas de entregabilidad.

Para mantenerse dentro del límite de búsquedas SPF:

• Reemplace los mecanismos include: con ip4: o ip6: donde los proveedores usen IPs estáticas.
• Segmente los flujos de correo electrónico a través de subdominios para distribuir el conteo de búsquedas.
• Elimine entradas include: no utilizadas o heredadas.
• Consolide proveedores para reducir la complejidad de SPF.
• Monitoree los registros SPF continuamente para detectar cambios de proveedores.

Use Skysnag Protect para monitorear el conteo de búsquedas DNS, identificar qué remitentes contribuyen a la inflación de búsquedas y recibir alertas antes de que SPF falle. Skysnag proporciona visibilidad sobre la estructura SPF, rastrea cambios en los registros de proveedores y le ayuda a reestructurar registros antes de que falle la autenticación.