Defaults.Exposed › Soluciones › Guides
SPF PermError: cómo arreglar "Too Many DNS Lookups" sin romper su correo (2026)
Publicado 2026-07-08
Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.
Al menos 797.263 dominios superan el límite de SPF de 10 consultas DNS, según el censo de Defaults.Exposed de 261.086.232 dominios — de un total de 139 millones de publicadores de SPF. Pasadas diez consultas, el receptor se detiene y devuelve PermError: su SPF queda anulado, y DMARC cuenta un PermError como un fallo.
La reparación tiene un orden estricto, y la mayoría de las guías lo hacen al revés. Cuente sus consultas reales, resueltas; elimine los includes muertos y sin uso — solo con eso se arreglan la mayoría de los registros; mueva los remitentes masivos a subdominios con su propio presupuesto de SPF; aplane solo como último recurso, y solo con re-aplanado automatizado, porque el aplanado estático se pudre y rompe la entrega en silencio.
¿Qué significa “SPF PermError: too many DNS lookups”?
El RFC 7208 §4.6.4 limita cada comprobación de SPF a 10 consultas DNS. Pasadas diez, el receptor se detiene y devuelve PermError — el registro entero se trata como roto, no solo la parte que excede el presupuesto. La misma sección añade un segundo techo menos conocido: como máximo 2 “consultas vacías” (void lookups) (peticiones que devuelven sin respuesta o NXDOMAIN), así que un par de entradas include: muertas de servicios cancelados pueden anular su SPF por sí solas.
La consecuencia es peor que “no tener SPF”: DMARC trata un PermError como un fallo de SPF, así que un dominio que rompe su propio SPF queda sin autenticar en la pata SPF de cada evaluación DMARC. Si DKIM no está configurado o se rompe en tránsito, ese correo ahora falla DMARC directamente.
Una cifra del censo muestra lo cruel que es este modo de fallo: 112.215 dominios publican un registro estricto -all que está anulado por desbordamiento de consultas — de los 54.655.923 dominios que publican -all siquiera. Sus propietarios hicieron la parte difícil — eligieron el final estricto — y un include de más apagó el registro entero. Parecen estrictos; están rotos. Para el panorama completo de los datos, vea el informe de PermError de SPF.
¿Por qué se rompió mi SPF si yo no cambié nada?
Porque el presupuesto se lo gastan sobre todo los registros de otros. Cada include: se evalúa de forma recursiva, y cada mecanismo con consulta dentro de él cuenta contra sus diez. Una línea en su panel DNS puede costar cuatro o cinco consultas una vez resuelta. Un proveedor anida un include más, y su SPF muere sin un solo cambio en su zona.
Las grandes plataformas no son el problema: Google y Microsoft han aplanado su propio SPF — _spf.google.com y spf.protection.outlook.com se expanden a listas de IP simples que cuestan cero consultas internas (verificado contra DNS en vivo, julio de 2026). Los desbordamientos reales vienen de cadenas de includes de paneles de alojamiento anidadas a varios niveles, y del apilamiento honesto de SaaS — buzón más boletín más CRM más helpdesk, cada uno “solo un include”. Nadie añade la undécima consulta a propósito; llega como la suma de decisiones razonables. Por eso el borde del precipicio está tan concurrido: 2.119.539 dominios están exactamente en 9–10 consultas resueltas — más o menos 1 de cada 66 de todos los publicadores de SPF, bien hoy, anulados el día que alguien pegue un include más. El registro SPF del percentil 99 ya se resuelve a 9 consultas. Si su pila es intensiva en SaaS, la guía de SPF fallando con herramientas SaaS cubre la versión proveedor por proveedor.
¿Qué partes de un registro SPF cuentan como consultas DNS?
| Mecanismo | Coste en consultas | Nota |
|---|---|---|
include: | 1 + todo lo que hay dentro, de forma recursiva | de aquí vienen casi todos los desbordamientos |
a | 1 cada uno | incluso una a sola para su propio dominio |
mx | 1 cada uno (más las consultas A de los hosts MX) | se olvida a menudo |
ptr | 1 — y obsoleto desde 2014 | elimínelo en cualquier caso |
exists: | 1 cada uno | poco frecuente |
redirect= | 1 + el contenido del registro destino | cuenta como un include |
ip4: / ip6: | 0 | por esto funciona el aplanado |
-all / ~all / ?all | 0 | el calificador es gratis |
Cuente el total resuelto, no las líneas visibles. Cuatro includes pueden ser cuatro consultas o catorce.
¿Cómo arreglo “too many DNS lookups” sin romper el correo?
- Ejecute el análisis gratuito antes de tocar el DNS. Resuelve su cadena completa de includes y muestra su número real de consultas, para que arregle el problema de verdad — no el registro tal como aparece en su panel. (Si dice que no tiene SPF en absoluto, ese es otro fallo distinto — vea “SPF record not found”.)
- Elimine primero los includes muertos y sin uso. La herramienta que dejó en 2023, el include del alojamiento antiguo que sobrevivió a una migración, los duplicados, cualquier mecanismo
ptr. Los includes muertos son doblemente tóxicos: queman presupuesto de consultas y son la fuente habitual de consultas vacías. La mayoría de los registros pasados de presupuesto vuelven a estar por debajo de 10 solo con este paso. Si su registro todavía arrastra mecanismos de un proveedor anterior, siga la guía de limpieza tras migración. - Compruebe que cada include restante sirve para algo. Los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom), no la cabecera From — y muchas herramientas SaaS ponen su propio dominio de rebote en el Return-Path, así que su include en el registro de usted no hace nada salvo gastar presupuesto. Conserve includes solo para los servicios que usan su dominio como Return-Path; para el resto, active en su lugar el DKIM de dominio propio del proveedor.
- Mueva los remitentes masivos a subdominios. Los boletines desde
news.yourdomain.com, el correo transaccional desdemail.yourdomain.com. Cada subdominio recibe su propio registro SPF con un presupuesto nuevo de 10 consultas, y un problema en un flujo deja de contaminar a los demás. - Solo entonces considere aplanar — y solo aplanado automatizado. Vea más abajo.
- Vuelva a analizar para confirmar que está con holgura por debajo de 10 — busque margen, no 10 exactos, o acaba de reincorporarse a los 2,1 millones de dominios al borde del precipicio. Luego repase todo lo demás que marque el análisis en la página de arreglar SPF.
¿Debería aplanar mi registro SPF?
El aplanado sustituye los includes por sus bloques ip4:/ip6: subyacentes, que cuestan cero consultas. Funciona — y hecho a mano, es una avería de entrega con efecto retardado.
| Enfoque | Número de consultas | Con el tiempo |
|---|---|---|
| Poda + subdominios (pasos 2–4) | Normalmente de vuelta por debajo de 10 | Estable; los proveedores gestionan sus propias IP |
| Aplanado automatizado (un servicio o tarea programada vuelve a resolver y republica) | Cerca de 0 | Sigue los cambios de IP de los proveedores; seguro |
| Aplanado manual de una sola vez | Cerca de 0 — hoy | Se pudre en silencio: los proveedores rotan IP, el correo legítimo empieza a fallar SPF sin ningún error en su lado |
Los proveedores rotan sus IP de envío de forma rutinaria y no se lo anuncian a nadie. Una lista de IP estática es correcta el día que la pega y silenciosamente errónea a los pocos meses — y como el fallo se manifiesta en que otras personas no reciben su correo, se entera tarde. Si la poda y los subdominios le dejan por debajo del límite, deténgase ahí; nunca copie a mano los bloques de IP de un tercero en su registro como solución permanente.
Preguntas frecuentes
¿Un PermError de SPF significa que mi correo deja de entregarse? No al instante — eso es lo que lo hace peligroso. DMARC cuenta un PermError como un fallo de SPF, así que la entrega descansa por completo en DKIM; si DKIM falta o se rompe en tránsito, está fallando DMARC. De los 139 millones de publicadores de SPF de nuestro censo (a fecha de 2026-06-29), al menos 797.263 están en este estado — la mayoría sin saberlo.
Mi registro solo tiene cuatro includes — ¿cómo puede superar las 10 consultas? Los includes se cuentan de forma recursiva: todo lo que hay dentro de cada include (y dentro de sus includes) se carga a su presupuesto, así que cuatro líneas visibles pueden resolverse en catorce consultas. Cuente con una herramienta que resuelva, no a ojo — resolver las cadenas es como nuestro informe de PermError encontró ~100× más dominios rotos de los que muestran los recuentos superficiales.
Termino mi registro con -all — ¿seguro que estoy protegido?
Solo si el registro se evalúa. Nuestro censo (a fecha de 2026-06-29) encontró 112.215 dominios cuyos registros estrictos -all están anulados por desbordamiento de consultas. Un calificador estricto en un registro con PermError no protege nada.
¿El límite de 10 consultas es por include o para el registro entero? Para la evaluación entera: el RFC 7208 §4.6.4 limita la comprobación completa a 10, más como máximo 2 consultas vacías. Cada subdominio tiene su propio registro y presupuesto — por eso funciona el paso 4.
¿Las entradas ip4 e ip6 cuentan para el límite? No — los mecanismos de IP no cuestan nada, que es exactamente por lo que el aplanado reduce el recuento.
Envíe el informe al propietario
Si está arreglando esto para un cliente o para su empresa, remate el trabajo con pruebas. Vuelva a ejecutar el análisis gratuito tras sus cambios y reenvíe el informe calificado al propietario del negocio: lenguaje claro, con fecha, PermError desaparecido. Ese es el documento que necesitarán para la renovación del ciberseguro y el próximo cuestionario de seguridad de clientes — la diferencia entre “cambié unos registros DNS” y un antes-y-después documentado.
Compruebe su dominio gratis
Vea su número real de consultas resueltas — y todo lo demás de SPF, DKIM y DMARC — de forma privada y solo para el propietario.
Compruebe su dominio → · Arreglar SPF → · SPF falla con herramientas SaaS → · Configurar SPF en GoDaddy → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.