SPF too many DNS lookups (permerror): cómo bajar de 10 consultas

Respuesta corta: el aviso SPF too many DNS lookups significa que tu registro se pasa del límite: SPF solo permite 10 consultas DNS al evaluar tu registro, contando también las que hacen por dentro los include: de tus proveedores. Si pasas de 10, el resultado es permerror y, a efectos prácticos, tu SPF deja de servir. Se arregla quitando los include: que no hacen falta (muchos sobran), cambiando a y mx por IPs fijas y moviendo envíos masivos a un subdominio.

Qué significa el error SPF too many DNS lookups

Cuando un servidor recibe tu correo, lee tu registro SPF (un TXT que empieza por v=spf1) y lo evalúa de izquierda a derecha. La norma de SPF (RFC 7208, apartado 4.6.4) limita a 10 los mecanismos que obligan a hacer una consulta DNS adicional. Si se supera, la evaluación se corta con permerror: un error permanente que significa «este SPF está mal construido».

Lo que cuenta y lo que no:

La trampa está en los include:. Tú ves cuatro, pero cada proveedor puede tener otros include: anidados dentro, y los cambia cuando quiere. Un SPF que el año pasado sumaba 8 consultas puede pasar a 11 sin que nadie toque tu DNS.

Hay un segundo límite menos conocido: como mucho 2 consultas «vacías» (las que no devuelven nada, por ejemplo un include: a un dominio que ya no existe). Pasarlo también da permerror.

Por qué es grave

Un SPF en permerror no autoriza a nadie. Si tu DMARC se apoya en SPF para algún servicio (porque ese servicio no firma con DKIM alineado), esos correos fallan DMARC. Con p=quarantine o p=reject acaban en spam o rechazados. Repasamos cómo encajan las tres piezas en la guía de por qué los correos llegan a spam.

Cómo saber si te pasa

Síntomas

• En las cabeceras de un correo recibido aparece spf=permerror.
• Los informes DMARC muestran SPF en permerror o fail para remitentes que sí están en tu registro.
• Un validador de SPF te dice «SPF too many DNS lookups» o «más de 10 consultas».

Cuéntalas tú mismo con dig

Empieza por tu registro:

dig +short TXT tudominio.com | grep -i spf1
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net a mx ~all"

Y baja por cada include::

dig +short TXT _spf.google.com
dig +short TXT spf.protection.outlook.com

Si dentro hay más include: o redirect=, sigue bajando. Para no hacerlo a mano, esta función de bash recorre el árbol y da el total:

spf_count() {
  local n=0 t
  for t in $(dig +short TXT "$1" | tr -d '"' | grep -i '^v=spf1'); do
    t=$(echo "$t" | sed 's/^[-+?~]//' | tr 'A-Z' 'a-z')
    case "$t" in
      include:*)  n=$((n + 1 + $(spf_count "$(echo "$t" | cut -d: -f2)"))) ;;
      redirect=*) n=$((n + 1 + $(spf_count "$(echo "$t" | cut -d= -f2)"))) ;;
      a|a:*|a/*|mx|mx:*|mx/*|ptr|ptr:*|exists:*) n=$((n + 1)) ;;
    esac
  done
  echo "$n"
}
spf_count tudominio.com

Es una ayuda rápida, no un validador completo: no entiende macros (%{i} y similares) ni detecta bucles. Si te da 9 o 10, ya estás al límite: cualquier cambio de un proveedor te saca.

Comprueba que solo tienes un SPF

Dos TXT que empiezan por v=spf1 en el mismo dominio también dan permerror. Pasa a menudo cuando cada proveedor te dice «añade este registro» y alguien crea uno nuevo en lugar de fusionarlo. Lo explicamos en SPF mal configurado: errores y solución.

Cómo bajar de 10 consultas paso a paso

1. Haz inventario de quién envía correo con tu dominio. No de quién envió alguna vez: de quién envía hoy. Correo corporativo, newsletter, CRM, facturación, tienda, formularios web, la centralita que manda mensajes de voz por email… Los informes DMARC agregados son la mejor fuente: te dicen qué IPs envían en nombre de tu dominio.
2. Quita los include: de servicios que ya no usas. Es lo más habitual: el proveedor de newsletter de hace tres años sigue en el SPF. Cada uno que eliminas puede liberar varias consultas.
3. Comprueba qué include: no sirven para nada. SPF no mira el From visible, sino el dominio del Return-Path (el remitente del sobre). Muchas plataformas de envío usan su propio dominio en el Return-Path, así que el include: en tu SPF no se usa nunca. Abre un correo enviado por esa plataforma, mira la cabecera Return-Path: si el dominio es del proveedor, ese include: te sobra. Lo que te alinea con DMARC en esos casos es DKIM, no SPF (lo explicamos en DKIM: qué es y cómo comprobarlo).
4. Cambia a y mx por IPs si tu servidor tiene IP fija. mx encima puede generar varias consultas internas (una por cada servidor MX). Si tu correo es Google o Microsoft, los MX no envían tu correo saliente: mx en ese caso suele sobrar.
5. Mueve los envíos masivos a un subdominio. Por ejemplo, news.tudominio.com o mail.tudominio.com para la newsletter, con su propio SPF y su propio DKIM. Cada subdominio tiene su propio límite de 10. Además separas la reputación del correo comercial de la del correo de personas.
6. Deja ip4: e ip6: para lo que controlas tú. No cuentan como consulta.
7. Publica el registro nuevo y vuelve a contar. Ejemplo de antes y después:

# Antes
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:mailgun.org a mx ~all

# Después: Outlook y Mailgun ya no se usan; SendGrid usa su propio Return-Path
# (su include no servía) y la newsletter pasa a news.tudominio.com
v=spf1 include:_spf.google.com ip4:203.0.113.25 ~all

1. Envía correos de prueba desde cada servicio y comprueba spf=pass o, si el servicio usa su propio Return-Path, dkim=pass con tu dominio.

¿Y el «aplanado» de SPF?

Aplanar (SPF flattening) es sustituir los include: por las IPs que contienen. Baja las consultas a casi cero, pero tiene un problema serio: los proveedores cambian sus IPs sin avisar, y tu SPF aplanado se queda viejo. Un día Google añade un rango nuevo y tus correos empiezan a fallar SPF. Solo tiene sentido si lo automatiza un servicio que vuelve a calcular el registro cada poco tiempo. Hacerlo a mano una vez es crear un problema para dentro de unos meses.

Cómo evitar que vuelva

• Cada vez que des de alta una herramienta que envía correo, pregunta antes si necesita SPF o le basta con DKIM alineado.
• Cuando des de baja un proveedor, quita su include: el mismo día.
• Revisa el recuento cada pocos meses aunque no cambies nada: los proveedores sí cambian lo suyo.
• Mantén el registro corto y comentado en tu documentación interna: qué es cada línea y quién la pidió.
• No uses ptr: está desaconsejado en la propia norma y gasta consultas.

Para agencias: el SPF de todos tus clientes, contado

El SPF de un cliente lo toca cualquiera: el que lleva la newsletter, el de la centralita, el del CRM. Nadie lo cuenta, y el permerror no da señales hasta que los correos dejan de llegar.

Jeffrey revisa el correo de cada dominio cada 6 horas. Sigue los include: y redirect= de forma recursiva, cuenta las consultas igual que la norma y, si el dominio recibe correo y el total pasa de 10, abre un aviso «SPF necesita más de 10 búsquedas DNS». Si el propio registro ya pasa de 10 sin bajar a los include:, o si tiene otros problemas (+all, ?all, sin all, uso de ptr), lo verás como «SPF mal construido», y +all se marca como crítico. Cuando el recuento no es concluyente (por ejemplo, porque un proveedor no responde), no te alarma en falso.

Preguntas frecuentes