El informe de PermError de SPF: 100× más dominios superan el límite de 10 consultas de lo que muestran los recuentos de superficie (2026)

Q: ¿Cómo reduzco mi cuenta de consultas de SPF?

Elimina los includes sin usar y ptr, aplana tu propia infraestructura a ip4:/ip6:, mueve los remitentes masivos a subdominios, y vuelve a contar después de cada herramienta nueva. La guía de corrección lo explica paso a paso.

Publicado 2026-07-03

Cifras a fecha de 2026-06-29 · metodología v7, más una pasada de tarificación de cadenas ejecutada el 2026-07-03. A partir del censo de 261 millones de dominios calificados, resolvimos cada objetivo include: de SPF referenciado 100 o más veces — 10.842 objetivos que cubren el 95,2% de todas las referencias de include — y tarificamos la cadena retenida de cada dominio frente a ese mapa. Los objetivos de cola sin resolver contaron como cero y el contenido de las cadenas refleja el día de la resolución, así que el titular es una aproximación conservadora, sesgada hacia el mínimo: decimos “al menos”. Solo agregado; nunca el registro de un negocio individual. Consulta cómo calificamos.

¿Cuántos dominios superan el límite de 10 consultas de SPF?

Al menos 797.263, porque SPF lleva una autodestrucción incorporada en el estándar, y el disparador se esconde donde los propietarios no pueden verlo. El RFC 7208 §4.6.4 limita una comprobación de SPF a 10 consultas DNS; pasadas las diez, el receptor se detiene y devuelve PermError, y un registro con PermError no protege nada. Cuenta solo las consultas visibles en el propio registro — como hace la mayoría de las herramientas, y como hacía nuestro propio censo hasta este informe — y encontrarás alrededor de 8.000 infractores (7958, para ser exactos). Tarifica las cadenas include: que esos registros arrastran de verdad, y la cuenta alcanza los 797.263: aproximadamente 100 veces más.

¿Por qué los propietarios no lo ven venir?

Porque el presupuesto lo gastan los registros de otras personas. include:onetool.example.com se lee como una sola línea en tu panel de DNS, pero el receptor debe recuperar ese registro también, y contar cada mecanismo de consulta que él contiene, de forma recursiva. Un registro con tres includes puede costar once. Nada cambió en tu propia zona el día en que te pasaste; un proveedor anidó un include más, y tu SPF murió sin previo aviso.

Peor aún, DMARC trata un PermError como un fallo en la pata de SPF — así que un dominio que rompió su SPF de esta manera ahora está fallando la mitad de su propia autenticación.

Qué encontró la tarificación de cadenas

Hallazgo	Dominios
Por encima del límite de 10 consultas, cadenas tarificadas	797.263
Por encima del límite contando solo los mecanismos visibles	7958
Por encima del límite terminando en `-all` estricto	112.215
En exactamente 9–10 consultas — el borde del precipicio	2.119.539

Dos historias en esa tabla — la tercera, el borde del precipicio, tiene su propia sección más abajo:

Los recuentos de superficie pasan por alto ~99% de la rotura. El recuento de mecanismos visibles encuentra 7958; tarificar las cadenas encuentra 797.263. Casi todo el daño se hereda de lo que los includes incluyen.
112.215 de los registros rotos terminan en -all. Sus propietarios hicieron todo bien — escalaron el muro, eligieron el final estricto — y un include de más anuló todo. Parecer estricto y estar roto es el modo de fallo más cruel en la seguridad del correo electrónico.

2,1 millones de dominios están a una herramienta del precipicio

La cifra que debería preocupar a los lectores que ahora mismo están bien: 2.119.539 dominios se resuelven en exactamente 9 o 10 consultas — por debajo del límite hoy, muertos el día en que alguien conecte una plataforma más. Eso es aproximadamente 1 de cada 66 de todos los publicadores de SPF, y encaja con la forma de la distribución: el registro SPF del percentil 99 ya se sitúa en 9 consultas. Date de alta en una herramienta de marketing más, pega su línea de “solo añade este include”, y un registro que estaba por debajo del límite en el desayuno queda anulado a la hora de comer.

¿De quién es la culpa? Cada vez más, del stack

Los proveedores más grandes han aplanado discretamente su SPF — el _spf.google.com de Google y el spf.protection.outlook.com de Microsoft ahora se expanden a simples listas de IP que cuestan cero consultas internas (verificamos ambos frente a DNS en vivo durante este análisis). Las explosiones vienen de otra parte: cadenas de paneles de hosting que se anidan tres niveles de profundidad, proveedores regionales cuyo include cuesta 7–10 consultas por sí solo, y la acumulación honesta de SaaS — buzón más boletín más CRM más soporte, cada uno “solo un include”. Casi nadie añade la undécima consulta a propósito. Llega como la suma de decisiones razonables.

Cómo comprobar y arreglar el tuyo — gratis

Cuenta tu total real — nuestra comprobación gratuita resuelve tu cadena, o usa cualquier contador de consultas SPF.
Poda el peso muerto: herramientas que dejaste de usar, includes duplicados, y el mecanismo ptr obsoleto.
Aplana solo lo que controlas. Reemplazar un include profundo por sus bloques de IP funciona para tu propia infraestructura; las IP de terceros cambian sin aviso.
Dale a los remitentes masivos un subdominio. Los boletines desde news.tudominio.com obtienen su propio registro y su propio presupuesto de 10 consultas.

Preguntas frecuentes

¿Qué es el límite de 10 consultas DNS de SPF? El RFC 7208 §4.6.4 permite como máximo 10 consultas DNS para evaluar un registro SPF — contando las consultas dentro de cada include: de forma recursiva. Superarlo devuelve PermError: el registro se trata como no válido y no proporciona ninguna protección.

¿Qué significa el PermError de SPF? Un error de evaluación permanente — el receptor no pudo procesar tu registro (demasiadas consultas, varios registros, o sintaxis rota) y trata tu dominio como si no tuviera un SPF utilizable. DMARC lo cuenta como un fallo en la pata de SPF.

¿Cuántos dominios superan el límite de consultas de SPF? Al menos 797.263 de 139 millones de publicadores de SPF, según nuestra pasada de tarificación de cadenas — unas 100× los 7958 visibles sin resolver las cadenas. Otros 2.119.539 se sitúan en 9–10 consultas, a un include del límite.

¿Un PermError impide que se entregue mi correo? Normalmente no — los receptores continúan sin SPF, y tu correo se sostiene sobre DKIM y la reputación. Lo que deja de funcionar es la protección: los falsificadores ya no son rechazados, y cada comprobación DMARC de tu correo pierde su pata de SPF. Es invisible hasta que sale caro.

¿Cómo reduzco mi cuenta de consultas de SPF? Elimina los includes sin usar y ptr, aplana tu propia infraestructura a ip4:/ip6:, mueve los remitentes masivos a subdominios, y vuelve a contar después de cada herramienta nueva. La guía de corrección lo explica paso a paso.

Averigua tu número real

Los mecanismos que puedes ver no son tu cuenta de consultas — el número resuelto es el que calculan los receptores, y es una comprobación de 30 segundos.

Comprueba tu dominio → · Corregir SPF → · El modelo de madurez de SPF → · Dos registros SPF = ninguno → · La trampa del ptr → · Solo datos agregados. Datos almacenados y procesados en la UE.