Por qué existe el límite
SPF no es una lista de direcciones IP que publicas una vez. Es un pequeño programa que el servidor receptor tiene que ejecutar: obtiene tu registro TXT y luego sigue cada mecanismo include, a, mx, ptr y exists, más cualquier modificador redirect, y cada uno de esos dispara su propia consulta DNS. El RFC 7208, sección 4.6.4, pone el tope en 10: "las implementaciones de SPF DEBEN limitar el número total de esos términos a 10 durante la evaluación de SPF, para evitar una carga irrazonable sobre el DNS". Si lo cruzas, "la implementación DEBE devolver permerror".
PermError no es un fallo suave. No significa "trátalo como neutral", como pasa cuando falta el registro. La mayoría de los receptores grandes, Gmail incluido, tratan un SPF PermError como si no hubiera SPF válido en absoluto, y las reglas de remitentes masivos de Gmail exigen que SPF o DKIM pasen, así que un dominio que se pasa del presupuesto de consultas puede empezar a rebotar con errores de correo sin autenticar, aunque el registro se vea bien a simple vista.
Dentro de esa misma regla hay dos límites relacionados. Cada mecanismo MX que uses no puede requerir consultar más de 10 registros A o AAAA para resolverse, y el mismo tope de 10 aplica a las consultas PTR. El RFC 7208 también recomienda que las implementaciones limiten las "consultas vacías" (void lookups), es decir, las que no devuelven nada, a dos, y que devuelvan permerror después de eso. En la práctica, esto significa que un registro inflado puede fallar antes de llegar a contar las 10 consultas reales, si suficientes de ellas regresan vacías.
Cuenta tus consultas con honestidad
El error más común en los registros SPF es contar solo los include del primer nivel y detenerse ahí. El límite no es "10 includes", son 10 consultas DNS en total durante toda la evaluación, y un include puede a su vez contener más includes, cada uno con su propio costo.
Toma un registro que parece inofensivo:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:spf.zoho.com redirect=_hspf.hubspot.com a mx include:sendgrid.net ~allLéelo de izquierda a derecha contra la lista del RFC de lo que cuenta (include, a, mx, ptr, exists, redirect): include:_spf.google.com es 1, include:spf.protection.outlook.com es 1, include:servers.mcsv.net es 1, include:spf.zoho.com es 1, el mecanismo a es 1, el mecanismo mx es 1, e include:sendgrid.net es 1. Van 7 antes de siquiera tocar el redirect de HubSpot. La cadena SPF de HubSpot no es plana. Seguirla tal como está publicada hoy significa que redirect=_hspf.hubspot.com (1 consulta) resuelve a un registro que a su vez incluye _hspf1.hubspot.com (1 más), que incluye _hspf2.hubspot.com (1 más), que incluye otro sub-registro. Esa sola cadena de redirect agrega 4 consultas o más encima de las 7, llevando el total a 11 o más, por encima del límite, en un registro que parecía tener seis o siete entradas modestas.
Los proveedores más comunes
No todos los proveedores cuestan lo mismo. Tal como está publicado hoy, include:_spf.google.com de Google Workspace resuelve directamente a una lista plana de rangos de IP, sin includes anidados, así que cuesta exactamente 1 consulta. include:spf.protection.outlook.com de Microsoft 365 tiene la misma forma: plano, 1 consulta. include:servers.mcsv.net de Mailchimp también es plano, 1 consulta. include:spf.zoho.com de Zoho igualmente resuelve a una sola lista plana, 1 consulta, aunque la propia documentación de Zoho a veces muestra un registro combinado con includes adicionales como zcsend.net para su producto de marketing, cada uno con su propio costo. HubSpot es la excepción: su SPF es una cadena de redirect e includes de varios niveles, y seguirla completa cuesta 4 consultas o más por sí sola, más que cualquier otro proveedor común en una pila típica.
Esto cambia con el tiempo. Los proveedores reestructuran su infraestructura SPF sin avisar, y uno que hoy es plano puede agregar includes anidados el próximo trimestre. Trata cualquier conteo, incluidos los de arriba, como algo que hay que reverificar con una herramienta en vivo, no como algo para grabar en una hoja de cálculo.
Arreglo 1: elimina includes muertos
La ganancia más rápida casi siempre es borrar mecanismos que ya nadie usa. Los registros SPF se acumulan igual que las listas viejas de copia: una herramienta de marketing que cancelaste hace dos años, una pasarela de fax a correo que nadie recuerda, un relay local que se dio de baja cuando migraste a Workspace o M365. Saca el registro actual, compara cada include contra un remitente que realmente esté enviando hoy, y borra lo que no esté activo. Solo esto resuelve una buena parte de los casos de "demasiadas consultas" sin tocar nada más.
Arreglo 2: mueve el costo a un subdominio
Cada subdominio tiene su propia evaluación de SPF y su propio presupuesto de 10 consultas. Si tu dominio raíz envía correo transaccional por Workspace y correo de marketing por HubSpot y Mailchimp, mover los envíos de marketing a un subdominio dedicado, por ejemplo mail.example.com o news.example.com, divide un presupuesto de 10 consultas saturado en dos presupuestos separados. Este es también el arreglo que recomienda dmarcian, la empresa que construyó y luego retiró su propia herramienta de aplanado de SPF, en lugar de aplanar: segmentar remitentes por subdominio da "mejor control, menor superficie de ataque, eficiencia operativa y resiliencia de reputación" en vez de un registro compartido e inflado.
Arreglo 3: aplanado, y por qué trae su propio riesgo
Aplanar reemplaza un include por los rangos ip4/ip6 literales a los que resuelve hoy, bajando el conteo de consultas a casi cero. Funciona, hasta que el proveedor cambia sus IPs de envío, algo que todos los grandes ESP hacen de vez en cuando sin publicar un changelog. Un registro aplanado se vuelve obsoleto en cuanto eso pasa, y el correo desde las nuevas IPs del proveedor empieza a fallar SPF en silencio, muchas veces antes de que alguien note el patrón de rebotes. dmarcian corrió el aplanado como experimento público durante años y lo cerró en marzo de 2023, concluyendo que la práctica cambia un problema operativo por uno de seguridad: un registro sobre-autorizado y rara vez auditado son "entradas innecesarias en registros SPF" que amplían la superficie de ataque en vez de reducirla. Si aplanas, trátalo como una solución temporal con una revisión programada en el calendario, no como un arreglo permanente.
Arreglo 4: apóyate en la alineación de DKIM en vez de forzar a SPF a cubrir todo
DMARC solo necesita que SPF o DKIM pasen y alineen, no ambos. Si un remitente que no puedes quitar de SPF sin romper el correo está bien firmado con DKIM y con dominio alineado, DMARC sigue pasando para ese remitente aunque SPF por sí solo exceda el límite de consultas o falle directamente. Esto no elimina el riesgo del PermError, un SPF PermError sigue siendo tratado como un fallo total de SPF por la mayoría de los receptores sin importar lo que DMARC decida al final, así que es una mitigación para la alineación, no un sustituto de bajar el conteo por debajo de 10. Prioriza configurar DKIM para cada remitente que conserves, y úsalo como red de seguridad mientras bajas el conteo de SPF, no como excusa para ignorarlo.
Verifica antes de darlo por hecho
Publica el cambio y luego revisa el registro en vivo en vez de confiar en tu propio conteo. Un registro que se veía bien en papel puede seguir excediendo el límite una vez que sigues una cadena de redirect como la de HubSpot hasta el final, y un error de tipeo en un include puede romper en silencio todo el registro en vez de solo esa entrada. Haz un envío de prueba real con el diagnóstico de correo de Guanacos Tech y confirma que SPF devuelve pass, no permerror ni none, en un mensaje real.
Cómo ayuda Guanacos Tech
Vemos esto sobre todo en empresas que cambiaron de plataforma de correo o de marketing dos o tres veces a lo largo de los años y nunca limpiaron el rastro. Auditamos la cadena completa de consultas, incluyendo redirects e includes anidados que la mayoría de los verificadores de SPF dejan de contar después del primer nivel, la bajamos de 10 en el orden correcto, y configuramos la alineación de DKIM como cobertura de respaldo para lo que tenga que quedarse. Si tu registro SPF sigue devolviendo PermError, agenda una llamada y lo revisamos juntos.