Error SPF «too many DNS lookups»: entender y corregir el límite de las 10 búsquedas DNS

Lo que cuenta (y lo que no) en las diez

Es el meollo del asunto, y la fuente de la mayoría de los malentendidos. Cuentan en el límite los mecanismos que exigen una búsqueda DNS:

• include: — cada include cuesta al menos una búsqueda, y a menudo más si contiene otros en cascada.
• a y mx — resuelven registros A/MX.
• ptr — resolución inversa (a evitar, ver más abajo).
• exists: y el modificador redirect= — cuentan también.

No cuentan los mecanismos que no exigen ninguna consulta:

• ip4: e ip6: — direcciones literales, cero búsquedas.
• all — el mecanismo terminal (-all, ~all).

La consecuencia es nítida: cuanto más sustituyas include: por ip4:/ip6:, más aligeras tu recuento. Y cuidado con los include en cascada: un include:_spf.proveedor.com puede contener él mismo tres o cuatro include, que cuentan todos en tus diez. Así es como se supera el límite sin darse cuenta: bastan unos cuantos proveedores glotones.

Diagnosticar: ¿cuántas búsquedas consumes?

Antes de corregir, mide. No puedes reparar lo que no ves. Nuestro analizador gratuito evalúa tu SPF, despliega los include en cascada y te dice en qué punto del recuento estás. El objetivo es visualizar el árbol de tu registro: cada include que publicas, y todo lo que arrastra tras de sí. Una vez ese árbol a la vista, los culpables saltan a los ojos —típicamente uno o dos grandes proveedores que, por sí solos, consumen la mitad de tu presupuesto—.

Cinco formas de volver a bajar de la barra

Aquí están las correcciones, de la más simple a la más estructurante:

1. Elimina los include inútiles. Lo más evidente, y lo más a menudo olvidado. ¿Esa herramienta que marketing probó hace dos años y ya no usa? Su include sigue ahí. Haz limpieza: conserva solo las fuentes que envían realmente.
2. Sustituye include por ip4:/ip6:. Si un proveedor publica rangos de IP estables, puedes inscribirlos en duro en lugar de su include. Transformas búsquedas DNS en literales que no cuentan. Cuidado, no obstante: si el proveedor cambia sus IP, debes seguirle.
3. Aplana tu registro (SPF flattening). El aplanamiento consiste en resolver de una vez por todas los include y sustituirlos por los ip4:/ip6: correspondientes. Potente, pero a manejar con método (las IP de los proveedores evolucionan). Le dedicamos una guía entera: qué es el aplanamiento de SPF.
4. Separa tus envíos por subdominio. En lugar de apilarlo todo en tu dominio raíz, haz salir el marketing desde mail.tu-dominio.com y el transaccional desde notif.tu-dominio.com. Cada subdominio tiene su propio presupuesto de diez búsquedas, independiente. Es a menudo la solución más duradera para los grandes remitentes.
5. Evita el mecanismo ptr. Lento, poco fiable, y desaconsejado por la propia RFC. Si ronda por tu registro, retíralo.

Y una vía avanzada: las macros exists

Las cinco correcciones anteriores reducen tu recuento. Existe una sexta vía, más técnica, que lo sortea: el mecanismo exists combinado con macros SPF autoriza un número ilimitado de IP en una sola búsqueda, delegando la decisión a una zona DNS que tú controlas. Reservada a los grandes emisores con parque dinámico, y con sus propias contrapartidas, la explicamos en detalle en las macros SPF y el mecanismo exists.

El error que no hay que cometer al corregir

Buscando reducir el recuento, algunos equipos pasan su SPF a ~all (softfail) «para quedarse tranquilos», o incluso lo suprimen. Mala idea. Debilitar la cualificación terminal (-all → ~all, o peor +all) no tiene ningún efecto sobre el recuento de búsquedas —no corrige nada—, pero debilita tu protección. El buen reflejo es reducir el número de búsquedas, no bajar la guardia. Para la diferencia entre -all y ~all, ve los mecanismos -all y ~all.

Verificar que está resuelto

Una vez aligerado tu registro, dos controles:

1. Vuelve a pasarlo por el analizador para confirmar que el recuento ha vuelto a bajar de diez y que ya no hay PermError. Ve también cómo verificar tu registro.
2. Vigila tus informes agregados: una fuente que fallaba en SPF por desbordamiento debería ahora pasar (y alinearse). Es la prueba definitiva de que la corrección ha surtido efecto.

Una palabra conexa: no confundas este PermError de desbordamiento con otros errores permanentes (sintaxis inválida, doble registro). El detalle de los casos está en el PermError, qué significa.

Un ejemplo concreto: anatomía de un desbordamiento

Tomemos un registro realista, el de una pyme que ha apilado sus herramientas con los años:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
  include:_spf.salesforce.com include:servers.mcsv.net include:spf.protection.outlook.com -all

A primera vista, seis include: podría creerse que son seis búsquedas. La realidad es más pesada, porque cada include se despliega:

• include:_spf.google.com → 1, pero contiene él mismo varios include (_netblocks, _netblocks2, _netblocks3) → ~4 en total.
• include:spf.protection.outlook.com → 1, más sus propios sub-include → ~2-3.
• include:_spf.salesforce.com, sendgrid.net, mailchimp.com, servers.mcsv.net → 1 a 2 cada uno.

Suma: se superan fácilmente doce o trece búsquedas. Resultado: PermError, y todo el correo de esta pyme —incluidas sus verdaderas facturas vía Salesforce— arriesga la cuarentena.

La corrección se resume en dos gestos. Primero, servers.mcsv.net y mailchimp.com están duplicados (mismo proveedor): se retira uno. Después, se traslada el marketing (Mailchimp) a un subdominio news.pyme.com con su propio SPF. El dominio raíz vuelve a caer a seis o siete búsquedas, bajo la barra, y cada flujo conserva su presupuesto. Ningún correo legítimo perdido, y no más PermError.

Preguntas frecuentes

¿El límite de las diez concierne también a DKIM? No. DKIM no tiene esta restricción; es una especificidad de SPF, ligada a la forma en que resuelve las autorizaciones en DNS. Además, en los despliegues reales, la alineación DKIM suele ser más robusta que SPF, precisamente porque escapa a este tipo de tope (ver cómo funcionan los tres protocolos juntos).

¿Cuántas búsquedas «cuesta» un include? Como mínimo una, para resolverlo. Pero si contiene él mismo include, a o mx, esos se suman. Un solo include de proveedor puede consumir tres o cuatro por sí solo.

¿Es el aplanamiento la mejor solución? No siempre. Arregla el recuento, pero congela IP que pueden cambiar en tu proveedor, con el riesgo de romper tu entregabilidad si no le sigues. Para muchas organizaciones, hacer limpieza de los include inútiles y separar por subdominio basta, sin la deuda de mantenimiento del aplanamiento.

¿Por qué mi registro «funcionaba» antes? Porque estabas bajo la barra. Cada nuevo proveedor añadido empuja el recuento hacia arriba; un día, un include de más hace bascular en PermError. Es un umbral, no una degradación progresiva.

Prevenir mejor que curar

El PermError nunca llega por sorpresa cuando se mantiene el ojo sobre el recuento. Tres hábitos lo evitan de forma duradera:

• Verifica el coste antes de añadir un proveedor. Cada nuevo include puede ocultar varios; mira su árbol antes de publicarlo, no después.
• Prefiere los subdominios desde el principio para los flujos voluminosos (marketing, notificaciones). Te regalas un presupuesto de diez búsquedas por flujo, y nunca tendrás que desenredarlo todo con urgencia.
• Audita tu SPF periódicamente. Los parques de envío derivan: una herramienta llega, otra se va sin que se retire su include. Un control trimestral basta para mantener el registro limpio.

La regla de oro: un registro SPF está vivo. Trátalo como un activo que hay que mantener, no como una línea que se publica una vez por todas —los pocos minutos por trimestre que pasas aquí cuestan mucho menos que un día buscando por qué tus facturas caen de repente en el spam—.

Deja que Thomas vigile tu SPF

El recuento SPF deriva con cada nueva herramienta conectada a tu dominio. Thomas, tu CISO virtual, despliega tu registro, localiza los include glotones e inútiles, propone la corrección más segura para tu caso (limpieza, subdominios, o aplanamiento controlado), y te avisa antes de que cruces el límite, no después de que tu correo haya empezado a caer.

Analiza tu dominio gratis → o crea una cuenta para mantener tu SPF bajo control.