Límite de 10 consultas SPF: cómo corregir permerror sin romper cold email

RFC 7208 establece que las implementaciones SPF deben limitar a 10 los términos que causan consultas DNS durante una evaluación. Si se excede ese límite, el resultado debe ser permerror. No es una recomendación de un verificador ni un umbral inventado por Gmail: forma parte del estándar para evitar una carga irrazonable sobre DNS.

El límite aplica a la evaluación completa, incluidos mecanismos anidados. Un registro raíz con tres include puede consumir más de tres consultas si cada proveedor apunta a otros registros. Microsoft lo explica con precisión: tener menos de 10 includes visibles no garantiza quedar por debajo de 10 lookups.

También hay que separar lookup de query. Un término puede producir más de una consulta DNS y la evaluación puede detenerse cuando encuentra una coincidencia. Por eso el mismo registro puede pasar para una fuente y fallar para otra situada más adelante en el recorrido. Una herramienta que devuelve un solo número sin mostrar la ruta ayuda a alertar, pero no termina el diagnóstico.

El estándar cuenta include, a, mx, ptr y exists, además del modificador redirect. El mecanismo ptr está desaconsejado por el propio RFC, pero si existe también consume presupuesto. Los anidados suman dentro del mismo límite global de la evaluación; no reciben diez consultas nuevas por cada include.

all, ip4 e ip6 no causan consultas DNS durante la evaluación SPF y no entran en ese límite. exp tampoco entra en el conteo principal porque su consulta ocurre después y solo en determinadas rutas. Esto no significa que una lista enorme de IPs sea automáticamente una buena arquitectura: reduce lookups, pero puede quedar obsoleta o autorizar rangos más amplios de lo necesario.

RFC 7208 añade límites específicos para resoluciones de mx y ptr, y recomienda no superar dos void lookups —respuestas sin datos o nombres inexistentes—. No mezcles todos esos controles en un contador llamado 'SPF score'. Reporta por separado términos, ruta, resultados vacíos, errores y tiempo de consulta.

Microsoft define la identidad que SPF valida como MAIL FROM, también llamada 5321.MailFrom, P1 sender o envelope sender. Puede ser distinta del dominio visible en RFC5322.From. Antes de editar DNS, descarga un mensaje original de cada flujo y confirma qué dominio evaluó realmente el receptor.

DMARC conecta ambas capas mediante alineación. RFC 7489 considera alineación SPF relajada cuando MAIL FROM y From comparten dominio organizacional; en modo estricto exige coincidencia exacta. Un SPF pass sobre un dominio ajeno al From puede ser técnicamente válido y aun no aportar un pass alineado para DMARC.

En cold email es común mirar el dominio del vendedor y asumir que allí vive toda la configuración. El proveedor de buzón o la plataforma puede usar otra ruta de retorno. Si el header muestra un MAIL FROM gestionado por el proveedor, agregar includes al dominio equivocado no corrige esa evaluación. Solo vuelve más complejo un registro que quizá nunca fue consultado.

Un dominio puede empezar con Google Workspace o Microsoft 365 y después sumar formularios, CRM, soporte, facturación, newsletter, un gateway y alguna herramienta que alguien probó un trimestre. Google pide identificar todos los servidores y terceros que envían para el dominio; también recomienda retirar dominios o IPs cuando dejan de usarse.

La trampa es añadir el include de cada herramienta conectada al workflow, aunque esa herramienta no transporte correo con ese MAIL FROM. Clay puede enriquecer, n8n puede orquestar e Instantly o Smartlead pueden operar una secuencia usando un mailbox de Google o Microsoft. Su participación en el proceso no demuestra que cada uno necesite autorización SPF. La fuente de verdad es la documentación del proveedor y el mensaje real.

Otro error es publicar varios registros SPF para el mismo hostname. No se suman. Microsoft y RFC 7208 indican que más de un registro aplicable produce permerror porque el receptor no puede elegir cuál evaluar. Si una guía dice 'agrega este TXT', primero comprueba si ya existe un valor que empieza con v=spf1 y edita el único registro autorizado mediante control de cambios.

Empieza por un inventario de flujos, no por el TXT. Para cada dominio o subdominio registra sistema de envío, tipo de correo, MAIL FROM observado, From visible, firma DKIM, proveedor, owner, última evidencia y estado. Separa corporativo, outbound, transaccional, soporte y marketing para saber qué fuente todavía necesita autorización.

Después consulta el TXT del hostname exacto y expande recursivamente cada include y redirect. Conserva el árbol, detecta ciclos, anota a, mx, exists y ptr, y calcula la ruta que seguiría cada fuente posible. Un conteo de mecanismos únicos puede engañar: el límite corresponde a términos evaluados en una ruta y el orden puede hacer que una fuente coincida antes que otra.

Finalmente compara DNS con evidencia. Envía pruebas internas autorizadas desde cada combinación representativa de dominio, mailbox y proveedor hacia cuentas controladas. Descarga los originales y revisa Authentication-Results: resultado SPF, smtp.mailfrom, DKIM y DMARC. Un auditor que nunca mira un correo real está validando intención de configuración, no comportamiento.

Primero elimina fuentes obsoletas después de confirmar que ya no envían. Busca campañas, alertas, facturas, webhooks y mensajes recientes; no borres un include porque el nombre no te resulta familiar. Asigna owner y ventana de rollback. Un registro más corto que rompe facturas transaccionales no es una mejora de deliverability.

Segundo consolida servicios cuando dos proveedores cumplen la misma función o separa corrientes en subdominios cuando existe una razón operativa. Microsoft recomienda subdominios para servicios de bulk que no controlas directamente y recuerda que cada subdominio remitente necesita su propio SPF. Eso crea un presupuesto de evaluación distinto, pero también otra identidad, DNS y monitoreo que mantener.

Tercero considera sustituir includes por ip4 o ip6 solo cuando el proveedor publica rangos estables y existe un proceso para actualizarlos. Microsoft desaconseja aplanar su include de Microsoft 365 porque usa infraestructura dinámica. Flattening sin sincronización convierte un permerror visible en una lista silenciosamente vieja. La deuda cambia de forma; no desaparece.

La guía de Google Workspace muestra ~all y lo recomienda en sus ejemplos de configuración. Microsoft recomienda -all para sus dominios de Microsoft 365 cuando SPF forma parte de una estrategia con DKIM y DMARC. Copiar el final de un registro entre proveedores sin revisar el contexto puede cambiar la política más de lo previsto.

No uses esta diferencia para elegir por intuición. Define todas las fuentes, configura DKIM, observa DMARC y sigue la documentación vigente del proveedor y del dominio concreto. Un cambio de ~all a -all no arregla el límite de consultas; solo modifica el resultado para fuentes que no coinciden.

Tampoco combines una reducción de lookups, una migración de plataforma y un cambio de enforcement en la misma ventana. Haz cambios pequeños, registra versión anterior, TTL, hora y owner, y prueba cada flujo antes de continuar. Cuando tres variables cambian juntas, un fallo posterior solo confirma que DNS también sabe producir misterio.

Supongamos un SPF con seis includes. El primero autoriza Workspace; el segundo, una plataforma transaccional que a su vez contiene tres includes; el tercero, un servicio de soporte con dos includes; y el resto añade otras fuentes. El registro parece estar 'debajo de diez' porque alguien contó seis palabras. La ruta recursiva puede superar el límite antes de llegar a una fuente posterior.

La corrección no es borrar el último include ni moverlo al principio para esconder el problema en las pruebas. El equipo debe identificar qué sistemas siguen activos, qué MAIL FROM usan y qué rutas necesitan autorización. Si soporte ya migró, retira su include con evidencia. Si marketing requiere infraestructura separada, usa un subdominio gestionado. Si un proveedor ofrece IPs estables y documentadas, evalúa ese reemplazo con monitoreo.

Después repite pruebas desde todas las fuentes, incluidas las que coinciden al final. Revisa varios receptores y conserva headers. El objetivo es que cada flujo autorizado pase SPF donde corresponde y que los no autorizados no entren por un rango sobrante. Un verificador verde para la primera ruta no prueba las demás.

Guarda por dominio el registro esperado, hash o versión, checked_at, owner, cambio aprobado y árbol de dependencias. Registra resultados SPF por MAIL FROM, DKIM, DMARC, proveedor receptor y flujo. Los reportes agregados DMARC pueden revelar fuentes y fallos, pero no sustituyen la prueba controlada ni muestran automáticamente el detalle comercial de cada campaña.

Alerta ante permerror, include sin TXT válido, aumento de fallos por una fuente, divergencia entre DNS esperado y observado, y proveedores activos sin owner. Revisa también que un retiro no deje mensajes transaccionales o replies fuera. El monitoreo debe conectar DNS con sistemas y campañas; de lo contrario, cada alerta vuelve a empezar la investigación desde cero.

No conviertas el número de lookups en KPI de negocio. Estar debajo de diez evita un error de evaluación; no garantiza inbox, respuestas positivas ni pipeline. Cruza la salud técnica con hard bounces, quejas, replies, reuniones y oportunidades por cohorte. SPF sano es una condición de operación, no una promesa comercial.

Un registro SPF es corto a simple vista y recursivo en producción. En una operación con varios dominios y proveedores, necesita inventario, owner, pruebas y control de cambios. Pegar includes hasta que una herramienta deje de mostrar rojo no es una arquitectura; es una colección de dependencias sin nombre.

picos.Ai audita el recorrido completo: identidad MAIL FROM, From visible, árbol SPF, DKIM, alineación DMARC, headers reales y relación con cada campaña. Priorizamos retirar fuentes y separar funciones antes de aplanar. Cuando flattening es necesario, documentamos origen, actualización y rollback en lugar de congelar IPs de una nube como si fueran mobiliario.

Si tu dominio mezcla Workspace, Microsoft 365, formularios, CRM y senders sin saber qué include sigue vivo, usa el enlace Hablemos al final de esta página. Podemos mapear una muestra, reproducir la ruta que genera permerror y corregirla sin tocar archivos ni dominios no relacionados. El mejor SPF no es el más corto: es el que autoriza exactamente lo que la empresa todavía puede explicar.