Toda organización que ha expandido su stack de software en los últimos años lleva una posible falla de entregabilidad dentro de un registro DNS que casi nadie revisa. El registro SPF, una entrada TXT corta que autoriza cuáles servidores pueden enviar correo en nombre de tu dominio, fue diseñado para una era más simple. El RFC 7208, el estándar que regula SPF, impone un límite estricto de 10 consultas DNS de mecanismo por evaluación. En 2026, con la organización mediana típica usando Microsoft 365, un CRM, una plataforma de marketing, un servicio de correo transaccional, una herramienta de soporte al cliente y varias aplicaciones SaaS más que envían correo con el dominio de la empresa, ese límite no es un caso extremo teórico. Es una trampa en la que los equipos caen cada vez que agregan una nueva herramienta.
Qué Significa Realmente el Límite de 10 Consultas
Cuando un servidor de correo receptor verifica si un mensaje entrante está autorizado bajo la política SPF del remitente, comienza en el registro SPF publicado y sigue cada mecanismo include:, a, mx y redirect= que encuentra. Cada uno de esos mecanismos puede apuntar a otro registro DNS, que puede contener más directivas include:, cada una de las cuales genera otra consulta. El RFC 7208 limita el total de estas consultas a 10 para una sola evaluación SPF.
Si la evaluación llega a la undécima consulta, el servidor no ignora simplemente los mecanismos adicionales. Devuelve un PermError, que significa “este registro SPF está permanentemente roto.” El mensaje no pasa SPF. No hay softfail. Simplemente falla por completo.
Bajo DMARC, un PermError se trata como una falla de SPF. Si DKIM tampoco está pasando y alineado, el mensaje falla DMARC. Si tu política DMARC es p=quarantine o p=reject, ese mensaje va a spam o se bloquea por completo, aunque haya sido enviado por tu propia infraestructura autorizada.
Cómo los Stacks de SaaS Modernos Alcanzan el Límite
La acumulación ocurre de forma gradual e invisible. Considera un inventario de envío realista para una empresa de 200 empleados:
include:spf.protection.outlook.compara Microsoft 365 (1 consulta, pero se resuelve en mecanismos adicionales)include:_spf.google.comagregado cuando alguien integró Google Workspace para una subsidiariainclude:salesforce.compara el CRMinclude:mcsv.netpara Mailchimpinclude:sendgrid.netpara correo transaccionalinclude:amazonses.compara una integración de desarrolladorinclude:_spf.intuit.comporque el equipo de contabilidad envía facturas a través de QuickBooksinclude:zendesk.compara la plataforma de soporte
Eso son ocho includes de nivel superior. Cada uno de esos includes se resuelve en su propio registro, que puede encadenar más consultas. El registro SPF de Microsoft por sí solo puede consumir de cuatro a seis consultas según el estado actual de su infraestructura. El conteo supera 10 antes de completar la lista.
El detalle crítico es que la falla es silenciosa. No hay ninguna notificación de rebote que diga “tu registro SPF tiene demasiadas consultas”. El servidor remitente entrega el mensaje, el servidor receptor evalúa SPF, obtiene un PermError y registra una falla de autenticación. Si tu política DMARC está en aplicación, los destinatarios dejan de ver tu correo. Si tu política es p=none, es posible que nunca lo sepas a menos que estés leyendo activamente los informes agregados.
Por Qué el Aplanamiento de SPF Funciona Hasta Que Deja de Funcionar
El remedio tradicional para el problema de 10 consultas es el aplanamiento de SPF: resolver cada cadena include: hasta las direcciones IP puras y escribir esas direcciones directamente en el registro SPF como mecanismos ip4: e ip6:. Dado que los mecanismos literales de IP no consumen consultas DNS, un registro aplanado puede autorizar docenas de servicios de envío sin superar el límite.
El problema es que los proveedores de correo en la nube rotan sus direcciones IP de envío continuamente. Cuando Google agrega nueva infraestructura de envío, cuando SendGrid expande un centro de datos regional, cuando Microsoft agrega capacidad, las IPs en el registro aplanado quedan desactualizadas. El correo legítimo de esas nuevas IPs comienza a fallar la autenticación SPF. El registro aplanado que solucionó el problema de consultas ahora ha creado un problema de desactualización de IPs, y el modo de falla es idéntico: fallas de autenticación silenciosas, entregabilidad degradada y posibles consecuencias de aplicación DMARC.
El aplanamiento manual que no se actualiza continuamente a menudo crea peores resultados que el problema que intentaba resolver.
Los Enfoques Modernos Que Realmente Funcionan
Tres enfoques manejan el límite de consultas de manera confiable en 2026.
La delegación de subdominios es la solución estructural más limpia. En lugar de enviar correo de marketing desde @tuempresa.com, lo envías desde @mail.tuempresa.com o @em.tuempresa.com. Cada subdominio tiene su propio registro SPF con su propio presupuesto de 10 consultas. El registro SPF del dominio raíz se mantiene liviano, y puedes incorporar servicios de envío adicionales en subdominios sin modificar el registro principal. DMARC puede configurarse para cubrir subdominios explícitamente, y la firma DKIM con el subdominio satisface la alineación.
Los servicios de aplanamiento de SPF automatizado rastrean los rangos de IP publicados por tus proveedores incluidos y actualizan el registro aplanado automáticamente cada vez que un proveedor cambia su infraestructura. Esto elimina el problema de desactualización que hace peligroso el aplanamiento manual. El registro se mantiene dentro del límite de consultas, y el correo legítimo continúa autenticándose correctamente.
Las macros SPF permiten políticas SPF altamente dinámicas que se evalúan por mensaje en lugar de globalmente, pero requieren soporte específico del lado receptor e introducen complejidad que las hace impráctica para la mayoría de las organizaciones sin experiencia dedicada en infraestructura de correo.
La Conexión DMARC Que la Mayoría de los Equipos Ignora
La relación entre el límite de consultas SPF y la aplicación DMARC es donde este problema se vuelve más importante en 2026.
Las organizaciones que han alcanzado políticas p=quarantine o p=reject y están protegiendo activamente su identidad de dominio contra suplantación pueden haber creado inadvertidamente una condición de PermError SPF en algún momento después de alcanzar la aplicación. Un PermError causado por un nuevo include de SaaS hará que DMARC falle para cada mensaje de ese dominio, no solo los falsificados. La protección que se construyó cuidadosamente a través del proceso de aplicación ahora está disparando mal en el correo legítimo.
El Informe de Adopción de DMARC 2026 de EasyDMARC encontró que solo alrededor del 9% de los dominios combinan una política de aplicación con informes agregados activos. Los informes agregados son exactamente el mecanismo que detectaría un aumento repentino en fallas de SPF causado por una violación del límite de consultas. Las organizaciones que se movieron a la aplicación y luego dejaron de monitorear sus informes agregados están volando a ciegas, sin visibilidad de si sus propios remitentes legítimos están pasando la autenticación.
Una Auditoría Práctica Que Puedes Ejecutar Hoy
Diagnosticar un problema con el límite de consultas SPF toma menos de cinco minutos. Usa cualquier herramienta de búsqueda SPF disponible públicamente para evaluar el registro SPF de tu dominio. La mayoría de las herramientas no solo contarán tus consultas actuales, sino que mostrarán el árbol de resolución completo, identificando qué cadenas include: consumen más consultas y si alguna ya te ha llevado más allá del límite.
Si encuentras un PermError, el paso inmediato es identificar qué include te está llevando por encima del límite. En la mayoría de los casos, es un proveedor agregado recientemente. Eliminar o trasladar ese proveedor a un subdominio generalmente es suficiente para mantener el total por debajo de 10 mientras implementas una solución a largo plazo.
Si estás exactamente en 10 consultas, estás a un include de un PermError. Trátalo como un problema urgente de infraestructura, porque la próxima herramienta SaaS que aprovisione tu equipo podría ser la que rompa tu correo.
Lo Que Proporciona el Monitoreo Continuo
El límite de consultas SPF no es un problema que se resuelve una vez. Es una condición que se gestiona continuamente, porque tu infraestructura de envío evoluciona constantemente. Se agregan nuevas herramientas. Los proveedores cambian las estructuras de sus registros. Las adquisiciones incorporan nuevos dominios. Una capacidad de monitoreo que observe tus métricas de autenticación en todas las fuentes de envío detectará una violación del límite de consultas en horas, mucho antes de que produzca fallas de entregabilidad visibles para los clientes.
Las organizaciones que evitan esta trampa no hacen nada particularmente sofisticado. Han automatizado el monitoreo de sus informes agregados y configurado alertas para cambios repentinos en las tasas de aprobación de autenticación. Cuando un nuevo include de SaaS los empuja sobre el límite, ven el pico de fallas antes de que los clientes noten las facturas o tickets de soporte faltantes.
La higiene de SPF, el monitoreo de DMARC y el análisis de informes agregados no son problemas separados. Son la misma tarea continua. Crea tu cuenta gratuita en Excello y mantén todo tu stack de autenticación de correo saludable.