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: cada include: sustituido por un ip4:/ip6: aligera otro tanto el 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 las diez del dominio evaluado. Así es como se supera el límite sin darse cuenta: bastan unos cuantos proveedores glotones.

Diagnosticar: ¿cuántas búsquedas se consumen?

Antes de corregir, hay que medir: no se repara lo que no se ve. Nuestro analizador gratuito evalúa el SPF, despliega los include en cascada y sitúa el recuento exacto. El objetivo es visualizar el árbol del registro: cada include publicado, 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 del 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. Eliminar 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í. Toca limpieza: solo subsisten las fuentes que envían realmente.
2. Sustituir include por ip4:/ip6:. Cuando un proveedor publica rangos de IP estables, estos se inscriben en duro en lugar de su include. Búsquedas DNS se transforman entonces en literales que no cuentan. Cuidado, no obstante: si el proveedor cambia sus IP, hay que seguirle.
3. Aplanar el 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. Separar los envíos por subdominio. En lugar de apilarlo todo en el dominio raíz, hacer salir el marketing desde mail.ejemplo.es y el transaccional desde notif.ejemplo.es. 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. Evitar el mecanismo ptr. Lento, poco fiable, y desaconsejado por la propia RFC. Si aún ronda por el registro, hay que retirarlo.

Y una vía avanzada: las macros exists

Las cinco correcciones anteriores reducen el 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 pilotada por el remitente. 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 la protección. El buen reflejo es reducir el número de búsquedas, no bajar la guardia. Para la diferencia entre -all y ~all, ver los mecanismos -all y ~all.

Verificar que está resuelto

Una vez aligerado el registro, dos controles:

1. Un nuevo paso por el analizador SPF gratuito para confirmar que el recuento ha vuelto a bajar de diez y que ya no hay PermError. Ver también cómo verificar un registro SPF.
2. Una vigilancia de los 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: este PermError de desbordamiento no se confunde con los 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 el proveedor, con el riesgo de romper la entregabilidad a falta de seguimiento. 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 estaba 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:

• Verificar el coste antes de añadir un proveedor. Cada nuevo include puede ocultar varios; su árbol se mira antes de publicarlo, no después.
• Preferir los subdominios desde el principio para los flujos voluminosos (marketing, notificaciones). Es un presupuesto de diez búsquedas por flujo, y nunca más un desenredo de urgencia.
• Auditar el 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. Es un activo que hay que mantener, no una línea que se publica una vez por todas —los pocos minutos por trimestre que se pasan aquí cuestan mucho menos que un día buscando por qué las facturas caen de repente en el spam—.

Thomas vigila el SPF

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

Analizar un dominio gratis o crear una cuenta para mantener un SPF bajo control.