SPF PermError «too many DNS lookups»: el límite de 10 consultas

«SPF PermError: too many DNS lookups» (demasiadas consultas DNS) significa que comprobar el registro SPF de tu dominio requiere más de 10 consultas DNS, el límite fijo de la RFC 7208, así que el servidor receptor deja de evaluarlo y devuelve un error permanente en lugar de «pass». Todo mensaje cuyo Return-Path use ese dominio pierde SPF. La solución es contar las consultas, también las anidadas dentro de cada include:, eliminar entradas muertas, poner tus propios servidores como ip4:/ip6: y llevar a los remitentes externos a sus propios subdominios.

¿Qué cuenta para el límite de 10 consultas DNS de SPF?

Cuentan seis términos: los mecanismos include, a, mx, ptr y exists y el modificador redirect. Si la evaluación necesita más de 10, el resultado debe ser permerror. Los mecanismos ip4, ip6 y all no cuestan nada (RFC 7208, sección 4.6.4).

El límite se aplica a toda la evaluación, no a la línea que ves en el panel DNS. Microsoft lo dice claramente: un include que apunta a un registro con otros tres include cuesta cuatro consultas, así que tener menos de 10 include: no garantiza menos de 10 consultas DNS (Microsoft Learn: configurar SPF). La ayuda de Google lo simplifica a «hasta 10 etiquetas include», lo que solo es cierto si ninguna anida otras (Google Workspace: configurar SPF).

Datos a noviembre de 2026, según la RFC 7208.

El segundo límite: dos consultas vacías

La RFC 7208 recomienda además limitar a dos las llamadas void lookups, consultas que no devuelven ningún registro o apuntan a un nombre inexistente; superarlo también da permerror. En la práctica afecta a dominios que conservan include de servicios ya cancelados: el proveedor borra el nombre DNS y tu registro apunta al vacío. Un include cuyo destino no tiene registro SPF ya es por sí solo un permerror (lo mismo indica Microsoft).

Un registro por nombre

Un nombre solo puede tener un registro TXT que empiece por v=spf1. Dos registros, normalmente porque se añadió un proveedor nuevo como segundo registro en lugar de fusionarlo, también dan permerror. Los registros largos se pueden dividir en varias cadenas entre comillas dentro de un mismo TXT; los receptores las unen sin añadir espacios (RFC 7208, 3.3). Los paneles DNS de Arsys, IONOS o Hostinger se ven distintos, pero la regla es la misma.

¿Cómo cuentas las consultas de tu SPF?

Consulta tu propio registro TXT con dig, cuenta los seis términos que generan consultas, después consulta cada destino de include: y redirect= y repite hasta llegar a registros con solo ip4/ip6. La suma de todos los niveles es el número que ven los receptores.

# 1. Your own record (exactly one line must start with v=spf1)
dig +short TXT example.com

# 2. Every include: in it, then every include: inside those
dig +short TXT mailgun.org
dig +short TXT _spf.mailgun.org

A mano se vuelve pesado a partir del segundo nivel, así que aquí tienes un script corto en Bash que recorre el árbol y lo muestra. Solo usa dig, sed y tr, y funciona en Linux y macOS:

#!/usr/bin/env bash
# spf-count.sh: count the SPF terms that cost a DNS lookup, following include: and redirect=
# Usage: ./spf-count.sh example.com
spf() { dig +short TXT "$1" | sed 's/" "//g; s/"//g' | grep -i '^v=spf1'; }

count() {
  local domain=$1 depth=$2 n=0 term lterm rec
  rec=$(spf "$domain")
  printf '%*s%s: %s\n' $((depth * 2)) '' "$domain" "${rec:-NO SPF RECORD}" >&2
  for term in $rec; do
    term=${term#[+~?-]}
    lterm=$(printf '%s' "$term" | tr 'A-Z' 'a-z')
    case $lterm in
      include:*)  n=$((n + 1 + $(count "${term#*:}" $((depth + 1))))) ;;
      redirect=*) n=$((n + 1 + $(count "${term#*=}" $((depth + 1))))) ;;
      a|a:*|a/*|mx|mx:*|mx/*|ptr|ptr:*|exists:*) n=$((n + 1)) ;;
    esac
  done
  echo "$n"
}

total=$(count "$1" 0)
echo "Lookups: $total of 10"

chmod +x spf-count.sh
./spf-count.sh mailgun.org

Salida, abreviada:

mailgun.org: v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all
  _spf.mailgun.org: v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all
    _spf1.mailgun.org: v=spf1 ip4:159.135.224.0/20 ip4:69.72.32.0/20 ...
    _spf2.mailgun.org: v=spf1 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ...
  _spf.eu.mailgun.org: v=spf1 ip4:141.193.32.0/23 ip4:159.135.140.80/29 ...
Lookups: 4 of 10

El total es lo que cuesta un include de ese nombre por debajo; el propio include suma una más. Así que include:mailgun.org cuesta 5 consultas en tu registro. El script es deliberadamente sencillo: no expande macros (exists:%{i}… cuenta como una, que es lo correcto) y no cuenta las consultas A por host detrás de mx.

¿Cuánto cuesta el include de cada proveedor?

Ejecutamos el script sobre los include que los proveedores indican a sus clientes. Las diferencias son grandes, y un solo helpdesk puede ocupar más de la mitad de tu presupuesto.

Datos a noviembre de 2026: medidos con el script anterior el 14 de noviembre de 2026. Los proveedores cambian sus registros sin avisar, así que vuelve a ejecutarlo antes de fiarte de una cifra.

¿Cómo se soluciona «too many DNS lookups»?

Ve del cambio más barato al más profundo: borra lo que sobra, sustituye las consultas que apuntan a tu propia infraestructura por direcciones y lleva a los remitentes masivos a subdominios. La mayoría de dominios bajan de 10 antes de necesitar aplanar nada.

Toma este registro, muy parecido al que acumulan muchas pymes tras unos años añadiendo herramientas:

; Before: 17 lookups, every message gets spf=permerror
example.com.  3600  IN  TXT  "v=spf1 a mx include:_spf.google.com include:mailgun.org include:email.freshdesk.com include:_spf.salesforce.com ~all"

Son 1 (a) + 1 (mx) + 1 (Google) + 5 (Mailgun) + 7 (Freshdesk) + 2 (Salesforce) = 17 consultas. Los receptores que evalúan el registro completo devuelven permerror para cada mensaje de example.com, incluido el correo normal del equipo.

1. Comprueba qué remitentes usan de verdad tu dominio en el Return-Path

   SPF comprueba el dominio del remitente del sobre (MAIL FROM, visible como Return-Path en un mensaje entregado), no la dirección From. Envía una prueba desde cada herramienta a una cuenta de Gmail y abre «Mostrar original». Si el Return-Path es bounces+123@vendor-mail.com, tu registro nunca se comprueba para esa herramienta y su include es peso muerto. Muchas herramientas de helpdesk, CRM y newsletter funcionan así y pasan DMARC con DKIM firmado con tu dominio.

2. Elimina los include de herramientas que ya no usas

   Los servicios cancelados son la causa más habitual tanto de pasarse del límite como de las consultas vacías. Si nadie sabe para qué sirve un include, consúltalo con dig; si pertenece a un servicio que dejaste, bórralo.

3. Quita ptr y cuestiona a y mx

   ptr es lento y la RFC 7208 pide no publicarlo. a solo sirve si el servidor web envía correo por sí mismo; mx, solo si tus servidores de entrada también envían. Con Google Workspace o Microsoft 365, los hosts MX ya están cubiertos por el include del proveedor, así que mx es una consulta desperdiciada.

4. Pon tus propios servidores como ip4:/ip6:

   Para un servidor que controlas, como un servidor de aplicaciones, un MTA de NetSendo o un relay de oficina, escribe la dirección directamente: ip4:203.0.113.10. No cuesta nada y solo cambia si cambias de servidor.

5. Lleva a los remitentes masivos y de marketing a subdominios

   Configura Mailgun en mg.example.com, Amazon SES con un dominio MAIL FROM personalizado como bounce.example.com, etc. Cada subdominio tiene su propio registro SPF y su propio límite de 10. La siguiente sección explica por qué DMARC sigue pasando.

6. Aplana lo que quede, solo si no hay otra opción

   Si un proveedor que debe quedarse en el dominio principal aún te hace superar el límite, sustituye su include por sus rangos de direcciones publicados y apunta en el calendario una fecha de revisión.

Tras los pasos 1–5, el mismo dominio queda así:

; After: each name has its own budget of 10
example.com.     3600  IN  TXT  "v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all"
mg.example.com.  3600  IN  TXT  "v=spf1 include:mailgun.org ~all"
bounce.example.com.  3600  IN  TXT  "v=spf1 include:amazonses.com ~all"
bounce.example.com.  3600  IN  MX   10 feedback-smtp.eu-west-1.amazonses.com.

El registro del dominio principal cuesta ahora 3 consultas, mg.example.com 5 y bounce.example.com 1, cada uno con margen dentro de su propio límite. Freshdesk desaparece del dominio principal porque, en este ejemplo, su Return-Path era el dominio del proveedor. El registro MX del subdominio de SES lo exige Amazon SES para un dominio MAIL FROM personalizado, y el registro SPF de ahí es el que documenta SES (Amazon SES: dominio MAIL FROM personalizado). Usa en el host MX la región de tu cuenta de SES, por ejemplo eu-west-1 (Irlanda).

⚠️ Atención: No quites un include hasta haber confirmado, en un mensaje real, adónde apunta el Return-Path de esa herramienta. Si quitas un remitente cuyo sobre sí usa tu dominio principal, su resultado SPF pasa a fail; solo pasará DMARC si además firma con DKIM alineado con tu dominio.

¿Es buena idea aplanar el SPF?

Aplanar (SPF flattening) sustituye un include por los rangos IP a los que se resuelve en este momento, así que ese remitente no cuesta ninguna consulta. Funciona, pero asumes una tarea que antes hacía el proveedor por ti: darse cuenta de cuándo cambian sus direcciones.

; Flattened by hand: 0 lookups for this sender, but the list goes stale when the vendor adds a range
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:198.51.100.0/24 ip4:203.0.113.0/25 ~all"

La guía de Microsoft es una buena regla: aplana solo proveedores con rangos estables y documentados, nunca el propio Microsoft 365, cuyas direcciones de envío cambian a menudo. Si aplanas, documenta lo que sustituiste, sigue la documentación del proveedor, revisa las entradas al menos cada trimestre y prueba tras cada cambio (Microsoft Learn).

Aplanado estático frente a automático

El aplanado estático es el ejemplo anterior: copias las direcciones una vez. Es gratis y transparente, pero se rompe en silencio el día en que el proveedor añade un rango, porque el correo desde el rango nuevo falla SPF mientras en el panel DNS todo parece correcto. Los servicios de aplanado automático vuelven a resolver los include periódicamente y publican el resultado, normalmente mediante un include o un CNAME a su propia zona. La lista se mantiene al día, pero añades una dependencia de pago en la autenticación de tu correo; si el servicio falla, falla tu SPF.

¿Por qué un subdominio de envío evita el problema?

Porque SPF se evalúa para el dominio exacto del remitente del sobre, y cada nombre tiene su propio registro y su propio presupuesto de 10 consultas. Microsoft lo dice expresamente: cada subdominio tiene su propio presupuesto de 10 consultas, y recomienda subdominios para los servicios de correo que no controlas (Microsoft Learn).

DMARC es lo que hace que funcione también para la dirección From visible. DMARC solo usa el resultado SPF de la identidad MAIL FROM, y esta debe estar alineada con el dominio From (RFC 9989, 4.4.2). Por defecto la alineación es relajada (aspf=r), así que bounce.example.com y news@example.com comparten el dominio organizativo example.com y cuentan como alineados. Puedes seguir enviando desde news@example.com mientras SPF se comprueba en el subdominio.

Además encaja con lo que Gmail pide a todo remitente: SPF y DKIM configurados para tu dominio y alineados a nivel de dominio organizativo (Google: directrices para remitentes). Un subdominio propio para marketing tiene otra ventaja: los rebotes y las quejas de las campañas llegan a un nombre que puedes vigilar por separado. Para una guía completa de SPF, DKIM, DMARC y calentamiento de tus propios servidores, consulta nuestra guía de entregabilidad para envío autoalojado (en inglés).

💡 Consejo: Si tu registro DMARC usa aspf=s (estricto), un sobre en un subdominio no está alineado y SPF deja de contar para DMARC. Revisa tu registro con dig +short TXT _dmarc.example.com antes de mover remitentes.

¿El registro debe terminar en ~all o en -all?

Con DMARC ya activo funcionan los dos, porque DMARC trata tanto ~all (softfail) como -all (fail) como fallo de SPF. Google recomienda ~all (Google Workspace); Microsoft recomienda -all para dominios de Microsoft 365 que también usan DKIM y DMARC (Microsoft Learn).

La diferencia está en lo que ocurre antes de que se ejecute DMARC. La RFC 9989 advierte que algunos receptores comprueban SPF al principio de la sesión SMTP, así que -all puede hacer que se rechace un mensaje que habría pasado DMARC gracias a una firma DKIM alineada, y esos rechazos nunca aparecen en tus informes agregados de DMARC (RFC 9989, 7.1). Esto importa con reenvíos y listas de correo. Una regla práctica:

• Mientras limpias include y mueves remitentes, usa ~all.
• Para un subdominio que usa un solo remitente, como mg.example.com, -all tiene poco riesgo: nada más debería enviar desde ahí.
• Para el dominio principal con correo del equipo, ~all más DMARC en p=quarantine o p=reject te da aplicación de la política sin rechazos tempranos por SPF.

Ninguna opción arregla un permerror: con demasiadas consultas, nunca se llega al all final.

¿Cómo compruebas que la solución funciona?

Comprueba el registro publicado desde fuera de tu red, vuelve a contar las consultas y luego envía un mensaje real y lee la cabecera Authentication-Results. Cuando expire el TTL del registro antiguo, deberías ver spf=pass para el dominio del sobre.

# The record the world sees (ask a public resolver, not your cache)
dig +short TXT example.com @1.1.1.1

# Exactly one SPF record per name
dig +short TXT example.com @1.1.1.1 | grep -c 'v=spf1'

# The count after the change
./spf-count.sh example.com 2>/dev/null

Después envía un mensaje desde cada herramienta a un buzón de Gmail u Outlook.com y mira las cabeceras. Un registro roto se ve así, con DKIM salvando todavía el resultado DMARC:

Authentication-Results: mx.receiver.example;
       spf=permerror smtp.mailfrom=news@example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Tras la corrección quieres ver spf=pass y un smtp.mailfrom en el dominio previsto. Si obtienes dmarc=fail porque fallan SPF y DKIM, consulta nuestra guía sobre el error 550-5.7.26 de Gmail (unauthenticated).

Vigila tus informes agregados de DMARC (rua) durante dos semanas tras el cambio: una fuente que de repente muestra SPF fail suele ser un remitente que no conocías y que envía desde el dominio principal.

Consultas SPF al enviar con NetSendo

NetSendo no publica ningún include SPF propio, así que nunca añade una cadena anidada a tu registro. Lo que necesita tu SPF depende de cómo envía cada buzón:

• NetSendo MTA (integrado en todas las instalaciones desde la 2.11.0): el registro del dominio remitente debe incluir la dirección pública del servidor, o la IP dedicada del buzón, como ip4:/ip6:. No cuesta ninguna consulta. El panel muestra la entrada exacta que hay que añadir.
• Relays SMTP: NetSendo reconoce Amazon SES, SendGrid, Google Workspace, Microsoft 365 y Mailgun por su host SMTP. Para Amazon SES y SendGrid no añade ningún include, porque esos relays envían con su propio dominio de sobre (o con el dominio MAIL FROM personalizado que configures en ellos).
• Return-Path: cuando un buzón tiene activada la gestión de rebotes, NetSendo pone como Return-Path su dirección de rebotes, así que una dirección de rebotes en un subdominio traslada allí la comprobación SPF. La configuración está en la documentación de configuración.

Con GOLD, el módulo Deliverability comprueba SPF, DKIM y DMARC de cada dominio, y su generador SPF conserva tu registro actual y solo añade los include que necesitan tus buzones de NetSendo. Muestra el número de consultas y marca los registros por encima de 8. Ese número cubre los términos del propio registro y no expande los include anidados, así que con un registro lleno de include de terceros ejecuta también el script de este artículo. Para empezar, sigue el inicio rápido.

Preguntas frecuentes

Fuentes

• RFC 7208: Sender Policy Framework (SPF)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain
• Google Workspace Admin Help: Set up SPF
• Google: Email sender guidelines
• Amazon SES: Using a custom MAIL FROM domain