SPF "Too Many DNS Lookups": la guía completa para corregir el límite de 10 lookups
Por CaptainDNS
Publicado el 3 de marzo de 2026
- La RFC 7208 impone un máximo de 10 DNS lookups por evaluación SPF, más allá de eso, el resultado es
permerrory tus correos fallan - Los mecanismos
include,a,mx,redirectyexistscuentan cada uno como un lookup,ip4eip6no cuentan - Con 3-4 proveedores de correo (Google Workspace, SendGrid, Mailchimp), alcanzas fácilmente 9-12 lookups
- 5 métodos para corregirlo: eliminar mecanismos innecesarios, reemplazar por IPs directas, SPF flattening, SPF macros, subdominios dedicados
- También existe un límite de 2 void lookups (mecanismos que no devuelven ningún resultado) que a menudo se ignora
Tu registro SPF contiene una decena de include: para cubrir todos tus proveedores de correo. Un día, agregas un nuevo servicio y tus correos empiezan a ser rechazados. El diagnóstico revela un permerror: has superado el límite de 10 DNS lookups impuesto por la RFC 7208.
Este problema afecta a la mayoría de las organizaciones que utilizan más de 3 proveedores de correo. Google Workspace por sí solo consume 4 lookups. Agrega SendGrid, Mailchimp y un servidor MX dedicado, y ya estás rozando el límite antes siquiera de haber configurado tu última herramienta de marketing.
Esta guía explica exactamente cómo funciona el límite de 10 lookups, cómo contar los tuyos y detalla 5 métodos concretos para corregir el problema, del más simple al más robusto.
¿Qué es el límite de 10 DNS lookups SPF?
Lo que dice la RFC 7208
La RFC 7208, sección 4.6.4 impone un límite estricto: la evaluación de un registro SPF no debe generar más de 10 consultas DNS. Este límite existe para proteger a los servidores de recepción contra ataques de amplificación DNS. Sin él, un atacante podría publicar un SPF con cientos de include: anidados y forzar a los servidores a realizar miles de consultas.
El límite se aplica de forma recursiva: si tu SPF incluye _spf.google.com, y este a su vez incluye otros 3 dominios, cada inclusión cuenta en el total de 10.
¿Qué mecanismos cuentan como un lookup?
| Mecanismo | ¿Cuenta como lookup? | Explicación |
|---|---|---|
include: | Sí | Resolución del SPF del dominio destino |
a | Sí | Resolución del registro A/AAAA |
mx | Sí | Resolución MX y luego A/AAAA de cada servidor MX |
redirect= | Sí | Resolución del SPF del dominio destino |
exists: | Sí | Verificación de existencia del dominio |
ip4: | No | Dirección IP directa, sin consulta DNS |
ip6: | No | Dirección IP directa, sin consulta DNS |
all | No | Mecanismo terminal, sin consulta |
La trampa principal: el mecanismo mx puede consumir varios lookups. Si tu dominio tiene 3 servidores MX, el mecanismo mx genera 1 lookup MX + 3 lookups A, es decir, 4 consultas para un solo mecanismo.
¿Cómo contar los DNS lookups de tu registro SPF?
El método más fiable consiste en resolver manualmente el árbol SPF. Veamos un ejemplo concreto con captaindns.com:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Conteo paso a paso:
| # | Mecanismo | Lookups generados |
|---|---|---|
| 1 | include:_spf.google.com | 1 |
| 2 | → include:_netblocks.google.com | 1 |
| 3 | → include:_netblocks2.google.com | 1 |
| 4 | → include:_netblocks3.google.com | 1 |
| 5 | include:sendgrid.net | 1 |
| 6 | include:servers.mcsv.net | 1 |
| 7 | mx (resolución MX de captaindns.com) | 1 |
| Total | 7 |
Con 7 lookups, este registro deja un margen de 3. Agregar HubSpot (1 lookup) y un segundo servidor MX (1 lookup) llevaría el total a 9, aún dentro del límite.
En lugar de contar manualmente, utiliza nuestro SPF Record Check que muestra el conteo exacto y señala cualquier exceso.
¿Qué sucede cuando superas el límite?
Cuando la evaluación SPF alcanza el 11.o lookup, el servidor de recepción detiene inmediatamente la evaluación y devuelve un resultado permerror. Las consecuencias son directas:
- El SPF se considera inválido : no simplemente fallido, sino estructuralmente roto
- DMARC falla en cascada : si tu política DMARC depende de SPF para la alineación, también falla
- Los correos son rechazados o enviados a spam : Gmail, Outlook y Yahoo aplican estrictamente este límite
- El error es silencioso : tus correos salen sin error del lado del remitente, solo el destinatario ve el rechazo
El problema es insidioso: mientras no superes el límite, todo funciona. El día que agregas un include: de más, todos tus correos se ven potencialmente afectados, no solo los del nuevo proveedor.
5 métodos para corregir el error "too many DNS lookups"
Método 1: Eliminar mecanismos innecesarios
Empieza por identificar los include: que ya no corresponden a servicios activos. Un proveedor de correo transaccional que dejaste de usar hace 6 meses sigue consumiendo uno o más lookups.
# Antes: 11 lookups (demasiados)
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.brevo.com mx ~all
# Después de eliminar Brevo (sin uso): 9 lookups
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Verifica cada include:: ¿ese servicio sigue enviando correos por captaindns.com? Si la respuesta es no, elimínalo.
Método 2: Reemplazar include por ip4/ip6
Si un servicio utiliza direcciones IP fijas y documentadas, puedes reemplazar su include: por las direcciones IP directas. Los mecanismos ip4: e ip6: no cuentan como lookups.
# Antes: include del servidor de correo (1 lookup)
v=spf1 include:mail.captaindns.com include:_spf.google.com ~all
# Después: reemplazo por la IP del servidor (0 lookup adicional)
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Atención: este método solo es adecuado para servidores cuyas IPs controlas. Nunca reemplaces los include: de Google o Microsoft por sus IPs, estas cambian regularmente sin previo aviso.
Método 3: SPF flattening (aplanamiento)
El SPF flattening resuelve automáticamente todos los include:, a, mx y redirect en direcciones IP directas. El resultado es un registro SPF compuesto únicamente por ip4: e ip6:, que no generan ningún lookup.
Ventajas:
- Resolución inmediata del problema de lookups
- Compatible con todos los servidores de recepción
- Resultado verificado y listo para publicar
Inconveniente:
- Las IPs de los proveedores cambian, debes re-aplanar regularmente (se recomienda mensualmente)
Método 4: SPF macros
Las SPF macros (%{i}, %{d}, %{s}) permiten construir registros dinámicos que redirigen la evaluación hacia subdominios específicos sin consumir lookups adicionales. Este enfoque avanzado se detalla en un próximo artículo de esta serie.
v=spf1 include:%{i}._spf.captaindns.com ~all
El servidor de recepción reemplaza %{i} por la IP del remitente, lo que apunta a un registro SPF específico. Resultado: 1 solo lookup en lugar de varios include:.
Método 5: Subdominios dedicados
En lugar de enviar todo desde el dominio principal, asigna un subdominio a cada proveedor:
| Subdominio | Proveedor | SPF dedicado |
|---|---|---|
captaindns.com | Google Workspace | include:_spf.google.com (4 lookups) |
news.captaindns.com | Mailchimp | include:servers.mcsv.net (1 lookup) |
transac.captaindns.com | SendGrid | include:sendgrid.net (1 lookup) |
Cada subdominio tiene su propio registro SPF con un contador de lookups independiente. Crea los SPF de cada subdominio con nuestro SPF Generator.
Void lookups: el segundo límite que debes conocer
La RFC 7208 define un segundo límite que a menudo se ignora: el número máximo de void lookups está fijado en 2. Un void lookup ocurre cuando un mecanismo DNS no devuelve ningún resultado (respuesta NXDOMAIN o vacía).
Ejemplos de void lookups:
- Un
include:dominio-inexistente.comque devuelve NXDOMAIN - Un
asobre un dominio sin registro A - Un
exists:que no corresponde a ninguna entrada
Más allá de 2 void lookups, el resultado también es permerror. Verifica que todos tus include: apunten a dominios existentes y correctamente configurados.
Plan de acción recomendado
- Cuenta tus lookups actuales: verifica el número exacto de DNS lookups de tu SPF publicado
- Identifica los mecanismos innecesarios: elimina los
include:de proveedores que ya no utilizas - Elige tu método de corrección: flattening para un resultado inmediato, subdominios para una solución estructural, macros para un enfoque avanzado
- Prueba antes de publicar: valida el nuevo registro antes de modificar tu zona DNS
- Monitorea regularmente: los SPF de los proveedores cambian, vuelve a verificar cada mes
FAQ
¿Qué es el límite de 10 DNS lookups SPF?
La RFC 7208 impone que un registro SPF no genere más de 10 consultas DNS durante su evaluación. Cada mecanismo include:, a, mx, redirect y exists cuenta como un lookup. Los mecanismos ip4: e ip6: no cuentan porque contienen directamente la dirección IP sin necesitar resolución DNS.
¿Cómo saber cuántos DNS lookups usa mi SPF?
Resuelve manualmente cada mecanismo de tu SPF contando los include:, a, mx, redirect y exists, incluyendo los de los sub-includes. Por ejemplo, include:_spf.google.com consume por sí solo 4 lookups porque Google anida 3 sub-includes. Una herramienta de análisis SPF automatiza este conteo y muestra el total exacto.
¿Qué sucede si mi SPF supera los 10 lookups?
El servidor de recepción devuelve un resultado permerror y considera tu SPF como inválido. Tus correos corren el riesgo de ser rechazados o clasificados como spam. Si DMARC está configurado, también falla en cascada porque la alineación SPF no puede verificarse.
¿El mecanismo mx cuenta como un solo lookup?
No. El mecanismo mx genera primero un lookup MX para obtener la lista de servidores de correo, y luego un lookup A/AAAA por cada servidor devuelto. Un dominio con 3 servidores MX consume potencialmente 4 lookups por un solo mecanismo mx.
¿Qué es el SPF flattening?
El SPF flattening consiste en reemplazar todos los mecanismos que generan lookups (include:, a, mx, redirect) por las direcciones IP directas que resuelven (ip4:, ip6:). El resultado es un SPF equivalente que no consume ningún lookup DNS.
¿Qué es un void lookup?
Un void lookup ocurre cuando un mecanismo DNS devuelve una respuesta vacía (NXDOMAIN o sin registros). La RFC 7208 limita los void lookups a 2. Más allá de eso, el resultado es permerror, incluso si el total de lookups se mantiene por debajo de 10.
¿Es mejor usar flattening o subdominios?
El flattening es la solución más rápida pero requiere mantenimiento mensual porque las IPs de los proveedores cambian. Los subdominios ofrecen una solución estructural duradera que aísla a cada proveedor con su propio contador de lookups. Para organizaciones con más de 5 proveedores, se recomiendan los subdominios.
Glosario
- DNS lookup: consulta DNS realizada durante la evaluación de un registro SPF para resolver un mecanismo como
include:omx. - Permerror: error permanente devuelto cuando un SPF es estructuralmente inválido, especialmente cuando supera el límite de 10 lookups.
- SPF flattening: técnica que reemplaza los mecanismos SPF que requieren lookups por las direcciones IP directas que resuelven.
- Void lookup: consulta DNS que no devuelve ningún resultado (NXDOMAIN o respuesta vacía). Limitado a 2 por la RFC 7208.
- RFC 7208: especificación oficial del protocolo SPF (Sender Policy Framework) que define las reglas de evaluación y los límites de lookups.
Aplana tu registro SPF ahora: utiliza nuestro SPF Flattener para resolver todos tus includes en direcciones IP directas y respetar el límite de 10 lookups.
📚 Guías de SPF relacionadas
- SPF Flattening vs SPF Macros: qué enfoque elegir para respetar el límite de 10 lookups?
- SPF PermError: comprender, diagnosticar y corregir (próximamente)
