Infraestructura de email
SPF: demasiadas búsquedas DNS, y el fallo silencioso que provoca.
SPF está limitado a diez búsquedas DNS por comprobación. Si superas ese límite, tu registro devuelve PermError, que falla la autenticación de cada mensaje que envías — en silencio, sin rebote, visible solo como correo que desaparece e informes DMARC que fallan. Los mecanismos que cuestan una búsqueda son include, a, mx, ptr, exists y redirect; ip4, ip6 y all son gratis. El arreglo honesto rara vez es una herramienta de flattening: poda los includes que no usas, quita el ptr obsoleto y delega SPF a un subdominio para que tu registro raíz se quede en una sola búsqueda.
En breve
- El tope es 10 búsquedas, más 2 void. Definido en RFC 7208 §4.6.4; supera cualquiera y obtienes PermError.
- PermError falla todo tu correo, en silencio. No solo el servicio extra — cada mensaje, sin rebote que te avise.
- include, a, mx, ptr, exists, redirect cuestan búsquedas. ip4, ip6 y all son gratis.
- Un solo registro SPF. Dos registros v=spf1 provocan PermError sin importar el conteo de búsquedas.
- La delegación gana al flattening. Un subdominio _spf delegado es estático; el flattening se queda obsoleto cuando cambian las IP del proveedor.
¿Por qué SPF se rompe en cuanto añades un servicio más?
El Sender Policy Framework permite a un propietario de dominio listar los servidores autorizados a enviar correo en su nombre, y un servidor receptor comprueba esa lista antes de decidir cómo tratar un mensaje. Para evaluarla, el receptor resuelve los mecanismos de tu registro vía DNS — y RFC 7208 §4.6.4 limita ese trabajo a 10 DNS-querying mechanism lookups, plus a separate cap of 2 void lookups, per check. El tope existe por una razón sólida: sin él, un registro malicioso podría encadenar referencias para disparar cientos de consultas DNS y convertir a cada receptor en un amplificador de denegación de servicio.
El problema es que el límite te alcanza poco a poco. Un registro con tres remitentes funciona a la perfección. En un par de años un equipo añade un CRM, un help desk, una plataforma de marketing — cada uno un include de aspecto inocente — y un día el sexto inclina el conteo por encima de diez. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. Desde ese momento el registro es inválido, y el modo de fallo es la parte cruel: Exceeding either limit returns PermError, which fails SPF for every message from the domain — silently. There is no bounce on the sending side; the only evidence is missing mail and failing DMARC reports.
No es un caso raro. Un escaneo de 5,5 millones de dominios en 2026 encontró que 4.8% of SPF-enabled domains exceed the 10-lookup limit — 148,655 of 3.1M scanned (DMARCguard SPF Supply Chain Study, 2026, 5.5M Tranco domains). Cada uno de esos dominios está enviando correo con autenticación rota ahora mismo, la mayoría sin saberlo, porque nada en sus propios sistemas se lo dice. El daño a la entregabilidad aparece primero como una deriva lenta hacia las carpetas de spam, semanas antes de que alguien lo rastree hasta el registro.
¿Qué aspecto tiene un registro pasado de límite — y el arreglo?
Aquí hay un registro que ha crecido por encima del límite como la mayoría: un montón de includes
acumulados con el tiempo, un mx, y un ptr obsoleto que nadie recuerda haber
añadido. Parece razonable, y está devolviendo PermError en silencio.
# Antes — 11 búsquedas, fallando en silencio con PermError
v=spf1 include:_spf.google.com # 3-4 búsquedas
include:sendgrid.net # 1
include:servers.mcsv.net # Mailchimp · 1
include:_spf.salesforce.com # 1
include:spf.protection.outlook.com # 2-3
a mx ptr # 3 más — ptr está obsoleto
-all
El arreglo duradero mantiene el registro raíz en una sola búsqueda delegando la lista real a un
subdominio, mientras poda lo que no se usa, quita ptr y convierte un remitente estático a
un ip4 directo. El registro delegado sigue usando includes normales, así que tus
proveedores conservan la capacidad de actualizar sus propias IP.
# Después — la raíz se queda en UNA búsqueda por delegación de subdominio
example.com. TXT "v=spf1 redirect=_spf.example.com"
# el registro delegado guarda la complejidad real, mantenida en un solo sitio
_spf.example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net
ip4:198.51.100.10 -all"
# ptr eliminado · remitente estático cambiado por ip4 · includes sin uso podadosContar búsquedas
¿Qué mecanismos cuestan una búsqueda DNS?
Todo el problema se reduce a qué mecanismos consultan DNS y cuáles no. Domina esta tabla y podrás contar tu propio registro a mano.
| Mecanismo | Qué hace | ¿Búsqueda? |
|---|---|---|
| include | Cuesta ≥1 búsqueda y resuelve el propio registro SPF del destino, cuyos includes anidados también cuentan. El mecanismo más común — cerca de un tercio de todos los mecanismos SPF en producción. | Cuenta |
| a | Resuelve los registros A/AAAA del dominio. | Cuenta |
| mx | Una búsqueda, más una por cada host MX devuelto — puede salir sorprendentemente caro. | Cuenta |
| ptr | DNS inverso por cada IP que conecta, lento y poco fiable. RFC 7208 lo desaconseja — elimínalo. | Cuenta (obsoleto) |
| exists / redirect | Cada uno resuelve el registro SPF de un dominio; una búsqueda cada uno. | Cuenta |
| ip4 / ip6 / all | Coincidencias literales — sin consulta DNS alguna. Úsalos para reemplazar mecanismos costosos en remitentes estáticos. | Exento |
El hábito más útil es contar antes de añadir. Antes de atornillar un nuevo include a tu registro, comprueba el total actual con un analizador SPF — porque los includes anidados dentro del propio registro de un proveedor pueden cambiar sin avisar, un registro que estaba en ocho búsquedas el mes pasado puede estar en once hoy sin una sola edición tuya. Hay además un segundo tope, más callado: RFC 7208 §4.6.4 limita los void lookups — consultas que no devuelven nada — a dos, y un único servicio dado de baja cuyo include ahora resuelve a un registro vacío puede dispararlo por sí solo.
El arreglo
Arreglarlo, del más rápido al más sostenible
Recorre la lista en orden. Los primeros pasos son victorias rápidas; los últimos son los arreglos estructurales que impiden que el problema vuelva.
- 1
Confirma que de verdad es un PermError
Pasa tu dominio por un comprobador SPF como MXToolbox; cuenta los includes anidados y marca «demasiadas búsquedas DNS». Contrasta enviando una prueba a Gmail, abriendo Mostrar original y buscando spf=permerror, y leyendo tus informes DMARC, donde el resultado SPF muestra permerror para cada remitente y no solo para uno.
- 2
Poda los includes de servicios que ya no usas
Este es el arreglo más limpio y seguro. Revisa cada mecanismo include, a y mx; si el servicio ya no envía por ti, bórralo. Esto también limpia el PermError por void lookup que provoca un servicio dado de baja cuyo include ahora resuelve a nada.
- 3
Reemplaza remitentes estáticos por ip4 / ip6 directo
Para cualquier remitente en una IP fija — normalmente tu propio servidor de correo — cambia el mecanismo include o a por la IP en sí, que no cuesta búsqueda. La contrapartida es que asumes la responsabilidad de esa IP, ya que el proveedor ya no puede actualizarla por ti.
- 4
Elimina el mecanismo ptr obsoleto
Si ptr aparece en cualquier parte de tu registro, elimínalo. Hace una búsqueda DNS inversa por cada IP que conecta, que es lenta y poco fiable, y la especificación lo desaconseja. Reemplázalo con referencias IP directas donde aún necesites autorizar esos hosts.
- 5
Delega SPF a un subdominio
Para el largo plazo, apunta tu registro raíz a un subdominio _spf delegado con redirect, para que la raíz se quede en una sola búsqueda mientras el registro delegado lleva la complejidad real en un único sitio mantenido. Esto es estático una vez configurado y es el arreglo más fiable para un dominio con muchos remitentes.
- 6
Trata el flattening como último recurso
Solo si la delegación no es viable, resuelve los includes a IP en bruto dentro del registro. Como las IP de los proveedores cambian, un registro aplanado se queda obsoleto y se rompe en silencio salvo que automatices el re-aplanado periódico y la monitorización — que es justo la carga de mantenimiento que evita la delegación.
La delegación de subdominio es más fiable que el flattening para casi todos los casos; el flattening es un parche cuando la delegación no es viable. Muchos equipos que pagan una herramienta de flattening descubren que ya no la necesitan una vez que podan y delegan.
El include obsoleto que rompe un registro por sí solo
No todos los PermError vienen del volumen puro. El segundo tope — dos void lookups — atrapa un fallo distinto y más taimado: un include que apunta a un dominio que ya no tiene registro SPF, así que la consulta no devuelve nada. Un void lookup es una consulta DNS que vuelve vacía o con un NXDOMAIN, y la mayoría de los receptores devuelven PermError en cuanto un registro pasa de dos. El culpable habitual es un único servicio dado de baja cuyo include simplemente no se eliminó nunca.
Hay un ejemplo bien documentado de exactamente esto. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it. La lección es que un registro puede estar cómodamente por debajo de diez búsquedas contadas y aun así dar PermError, porque un include muerto no es solo presupuesto desperdiciado — es un void lookup activo. Cuando migras fuera de cualquier servicio de correo, eliminar su include es parte de la migración, no una limpieza opcional para después.
Por eso el arreglo más limpio es también el primero de la lista. Podar no es vistoso y no hay herramienta que vender para ello, pero recorrer cada mecanismo include, a y mx y borrar los que ya no envían por ti elimina ambos tipos de fallo a la vez: recupera presupuesto de búsqueda y limpia los void lookups que deja atrás un include obsoleto. La mayoría de los registros pasados de límite tienen al menos un servicio olvidado dentro, y algunos se arreglan solo con ese paso.
Por qué se agota el presupuesto de búsquedas al crecer
La razón estructural tras casi cada registro pasado de límite es la misma: SPF se diseñó cuando la mayoría de las organizaciones enviaban correo desde uno o dos sitios, y el stack moderno envía desde una docena. Cada nueva herramienta SaaS que envía correo en tu nombre — un CRM, un help desk, una plataforma de marketing, un sistema de facturación, una herramienta de encuestas — quiere su propio include, y los includes se anidan. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. El presupuesto que parecía generoso con tres remitentes ha desaparecido para cuando llegas al séptimo, y nada en el proceso te avisa al cruzar la línea.
Los datos confirman lo mecánico que es. El mecanismo más común en los registros SPF es el include, y es justo el que cuesta búsquedas y se anida de forma impredecible, porque el propio registro del proveedor puede crecer sin decírtelo. AutoSPF (Apr 2026) attributed 41% of SPF failures across a sample of fast-growing domains to exceeding the 10-lookup limit. El patrón es consistente: cuantos más servicios de terceros adopta una organización, más rápido agota su presupuesto de búsquedas, y los equipos que alcanzan el límite suelen ser los que crecen más rápido y añaden herramientas con más agresividad.
Ese encuadre apunta directo al arreglo duradero. Si el problema es que los includes se acumulan y se anidan más allá de tu visibilidad, la respuesta no es congelar tu infraestructura de envío ni fijar a mano una instantánea de IP que se desviará — es poner toda esa complejidad detrás de un único registro delegado que controlas, para que la raíz se quede en una búsqueda sin importar cuántos servicios haya detrás. Crecer deja de ser una cuenta atrás hacia el PermError y pasa a ser una edición en un solo sitio mantenido.
PermError no es lo mismo que un fallo de SPF
Conviene ser preciso con el error, porque los dos resultados piden respuestas completamente distintas. PermError is not the same as an SPF fail. Fail means the record was evaluated and the IP did not match; PermError means the record itself is broken (too many lookups, a syntax error, multiple records, or unresolvable/circular includes) and could not be evaluated at all. Un fallo es un resultado normal y sano — es SPF haciendo su trabajo, diciéndole al receptor que una IP concreta no estaba en tu lista. Un PermError es el registro en sí siendo ilegible, lo que significa que SPF no le da al receptor ninguna respuesta utilizable para nada de tu correo.
El efecto en cadena alcanza a DMARC. DMARC interprets an SPF PermError as a fail, so if SPF is your only alignment path, a PermError quietly weakens DMARC too. Un equipo que ha movido con cuidado DMARC hacia la aplicación puede descubrir que un único registro SPF pasado de límite le quita el suelo en silencio, porque la alineación con la que contaba ahora resuelve a PermError para cada mensaje. Arreglar el conteo de búsquedas no es por tanto solo una reparación de SPF; a menudo es la pieza que falta para que una política DMARC se sostenga de verdad.
Hay una mala configuración más que conviene descartar mientras estás en el registro, porque produce el
mismo PermError por otra vía. RFC 7208 requires exactly one SPF (v=spf1) TXT record per domain. Two records cause PermError for all mail, regardless of lookup count — a very common misconfiguration. Si estás depurando y no sabes si la culpa es de las
búsquedas o de un registro duplicado, cuenta primero las búsquedas; si el conteo está cómodamente por
debajo de diez y aún ves PermError, busca esa segunda entrada TXT v=spf1 perdida.
El arreglo honesto
Flattening frente a delegación, sin rodeos
Ambos recortan el conteo de búsquedas. Solo uno se queda arreglado.
Los resultados de búsqueda dominados por vendors alrededor de este tema empujan el flattening con
fuerza, a menudo como servicio de pago, porque es el arreglo que necesita una herramienta. Diremos lo
menos rentable: la mayoría de los dominios no necesita una suscripción de flattening. Poda los includes
que dejaste de usar, quita ptr, convierte tus propios servidores estáticos a
ip4 y, si aún tienes complejidad genuina, delégala a un subdominio. Recurre al flattening
solo cuando la delegación de verdad no sea opción, y si lo haces, monta la automatización que evita que
se pudra en silencio.
Dónde nos situamos
Alojamos infraestructura de envío, así que vemos registros SPF pasados de límite constantemente — son, en nuestra experiencia y en los datos publicados, el fallo de SPF más común. El consejo honesto nos cuesta un producto que podríamos vender: la mayoría de los equipos que llegan con un PermError no necesitan un servicio de flattening, necesitan una tarde de poda y una delegación de subdominio, tras la cual el registro se queda arreglado solo. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it.
Si gestionas el correo con nosotros, mantener tu SPF dentro del límite es parte de la configuración, y
diseñaremos la delegación para que se quede estática a medida que añades y quitas remitentes. Si
autohospedas o envías por un ESP, la misma secuencia se aplica sea quien sea quien opere los servidores:
confirma el PermError, poda, quita ptr, convierte remitentes estáticos a IP directas y
delega el resto. Cuenta antes de añadir, y el límite deja de ser una trampa.
Preguntas
Respondidas con claridad
Las preguntas que se hacen los equipos cuando SPF empieza a fallar sin razón evidente.
¿Qué es exactamente el límite de 10 búsquedas de SPF?
La evaluación de SPF está limitada a diez búsquedas DNS de mecanismos por comprobación, más un tope aparte de dos void lookups, definido en RFC 7208 §4.6.4. Los mecanismos que resuelven un nombre — include, a, mx, ptr, exists y redirect — cuestan cada uno al menos una búsqueda, y los includes anidados cuentan contra el mismo presupuesto. Los mecanismos literales (ip4, ip6, all) no cuestan nada. El límite existe por seguridad y rendimiento: sin él, un registro malicioso podría disparar cientos de consultas DNS y convertir a los receptores en un vector de denegación de servicio.
¿Qué pasa de verdad cuando lo supero?
Tu registro devuelve PermError, y SPF falla para cada mensaje que envías — no solo el correo del servicio extra, todo. Lo peor es que es silencioso: no hay rebote en tu lado, así que la única evidencia es correo que desaparece e informes DMARC que muestran permerror. Un registro que funcionaba bien con tres remitentes se rompe el día que añades el sexto, y la entregabilidad puede degradarse durante semanas antes de que alguien lo relacione con el cambio en SPF.
¿Es PermError lo mismo que un fallo de SPF?
No, y la distinción importa. Un fallo de SPF significa que el registro se evaluó correctamente y la IP de envío simplemente no estaba autorizada. Un PermError significa que el registro en sí no se pudo evaluar en absoluto — demasiadas búsquedas, un error de sintaxis, más de un registro SPF, o un include irresoluble o circular. Como DMARC trata un PermError como un fallo, un registro roto también socava en silencio la alineación de DMARC si SPF es la vía en la que te apoyas.
¿Debo usar una herramienta de flattening de SPF?
Normalmente no como primer movimiento, y a menudo en absoluto. El flattening reemplaza los includes por sus IP resueltas, lo que sí recorta el conteo de búsquedas, pero esas IP se quedan obsoletas en cuanto un proveedor cambia su infraestructura de envío — y los grandes proveedores cambian sus rangos con regularidad. Un registro aplanado necesita por tanto re-aplanado y monitorización automatizados o se rompe en silencio. La mayoría de los equipos que podan los includes sin uso y delegan a un subdominio descubren que ya no necesitan la herramienta de pago que estaban considerando.
¿Por qué la delegación de subdominio es mejor que el flattening?
Porque es estática una vez configurada, sin dependencia de una herramienta de terceros que vuelva a resolver IP. Apuntas tu registro raíz a un subdominio _spf delegado, la raíz se queda en una sola búsqueda, y el registro delegado lleva la complejidad real — pero sigue usando includes normales, así que los proveedores conservan la capacidad de actualizar sus propias IP. El flattening arregla el síntoma (el conteo de búsquedas) mientras asume la fragilidad de fondo de las IP fijadas a mano; la delegación arregla la estructura y deja a los proveedores al mando de sus propios rangos.
¿Puedo tener dos registros SPF para que quepa todo?
No — eso lo empeora. RFC 7208 exige exactamente un registro TXT v=spf1 por dominio, y publicar dos provoca un PermError para todo tu correo sin importar cuántas búsquedas contenga cada uno. Es una de las malas configuraciones de SPF más comunes. Fusiona cada remitente autorizado en un único registro, y si ese registro es demasiado largo para una cadena DNS, tu proveedor de DNS debería partirlo en varias cadenas dentro del mismo registro — que es distinto de tener varios registros.
¿SPF fallando sin razón evidente?
Cuéntanos tu dominio de envío y contaremos tus búsquedas, encontraremos el PermError y diseñaremos una delegación que se quede bajo el límite a medida que creces — sin suscripción de flattening.