Aplanamiento de SPF: cómo resolver el límite de 10 consultas

El límite de 10 consultas, explicado

SPF (Sender Policy Framework) falla con un permerror cuando un servidor de correo receptor debe realizar más de 10 consultas DNS para resolver su registro SPF. Esto ocurre por las sentencias include anidadas: si su registro incluye a un proveedor y ese proveedor incluye otro servicio, cada paso cuenta para el límite. Para solucionarlo, debe recurrir al aplanamiento de SPF (SPF flattening), que sustituye estas consultas recursivas por una lista estática de direcciones IP.

Como ingeniero que gestiona la entregabilidad, he visto este problema aparecer sobre todo con la "proliferación de proveedores". Una empresa empieza con un proveedor transaccional, agrega una herramienta de marketing, luego un CRM, y de repente su registro SPF es un castillo de naipes. Cuando se produce la consulta número 11, el servidor receptor deja de buscar y devuelve un error permanente. Esto significa que su correo no solo se marca como spam: puede rechazarse por completo porque la comprobación de autenticación falló de raíz.

Cómo funciona el límite de consultas

Según RFC 7208, el límite existe para evitar ataques de denegación de servicio (DoS) contra la infraestructura DNS. Sin límite, un actor malicioso podría crear una referencia circular o una cadena enorme de include que obligara al servidor receptor a hacer cientos de consultas por un solo correo.

¿Qué cuenta como consulta?

No todos los mecanismos de su registro SPF son gratuitos. Los siguientes generan una consulta DNS:

• include: el culpable más habitual. Indica al servidor que consulte el registro SPF de otro dominio.
• a: consulta el registro A del dominio.
• mx: consulta los registros MX del dominio.
• ptr: consulta el DNS inverso (aunque está obsoleto y debe evitarse).
• exists: consulta un dominio concreto para ver si existe.

Mecanismos como ip4 e ip6 son gratuitos porque la dirección IP figura explícitamente en el registro.

Anatomía de una cadena de consultas

Considere este registro SPF hipotético:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

A simple vista, son 3 consultas. Sin embargo, si _spf.google.com contiene tres sentencias include más y spf.protection.outlook.com contiene cuatro, ya está en 10 consultas. Si el registro de SendHQ también tuviera un include, habría alcanzado el límite. Esto es una "cadena de include".

Cómo identificar el permerror

Si no está seguro de haber alcanzado el límite, puede usar el Verificador de DNS de correo de SendHQ para validar sus registros. En un registro sin procesar o en una herramienta de análisis de encabezados, verá un resultado como este:

spf=permerror (too many DNS lookups)

Esto es distinto de un softfail (~all) o un fail (-all). Un permerror significa que la comprobación SPF no pudo completarse. Cuando esto ocurre, el receptor no puede verificar si el remitente está autorizado, lo que a menudo hace que el correo se descarte o que los filtros más agresivos lo marquen.

¿Qué es el aplanamiento de SPF?

El aplanamiento de SPF es el proceso de resolver todos los mecanismos include, a y mx en una lista plana de direcciones ip4 e ip6.

Ejemplo: antes y después

Antes (recursivo):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Suponga que _spf.example.com se resuelve como 1.2.3.4 y _spf.vendor.com como 5.6.7.8)

Después (aplanado):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

Al convertir el registro en una lista de IP, el número de consultas baja de 2 (o más) a 0. El servidor receptor ve las IP de inmediato y valida al remitente sin más consultas DNS.

Las desventajas del aplanamiento

El aplanamiento es una solución potente, pero introduce una carga de mantenimiento considerable.

1. El problema de las IP obsoletas

Cuando usa una sentencia include, delega la gestión de las direcciones IP en el proveedor. Si Amazon SES o SendGrid agregan un nuevo rango de IP a su infraestructura, actualizan su propio registro SPF y su correo sigue fluyendo.

Si aplana esos registros en su propio DNS, pasa a ser responsable de esas IP. Si el proveedor cambia una IP y usted no actualiza su lista aplanada, sus correos fallarán la autenticación SPF. Esta es la principal razón por la que el aplanamiento manual es peligroso para el correo transaccional de alto volumen.

2. Límites de longitud de los registros

Los registros DNS tienen una longitud máxima. Una sola cadena en un registro TXT está limitada a 255 caracteres. Aunque puede concatenar varias cadenas, algunos analizadores DNS antiguos tienen problemas con registros muy largos. Si aplana demasiados proveedores, su registro SPF podría volverse demasiado grande para procesarse correctamente.

Cómo corregir las cadenas de include

Si alcanza el límite de 10 consultas, siga esta jerarquía de soluciones, de la más segura a la más agresiva.

Paso 1: audite y depure

Revise su registro en busca de proveedores antiguos. Muchos equipos siguen teniendo sentencias include de servicios que dejaron de usar hace tres años. Elimine cualquier proveedor que ya no envíe correo en su nombre.

Paso 2: use subdominios para los distintos tipos de tráfico

Esta es la solución de arquitectura más profesional. En lugar de poner todos los servicios en su dominio raíz, sepárelos por función:

• Dominio raíz (example.com): correo corporativo (Google Workspace/Outlook).
• Subdominio transaccional (mail.example.com): SendHQ o Amazon SES.
• Subdominio de marketing (news.example.com): Mailchimp o Klaviyo.

Cada subdominio tiene su propio registro SPF y su propio límite de 10 consultas. Esto aísla el riesgo y evita que la compleja cadena SPF de una herramienta de marketing rompa sus correos transaccionales críticos.

Paso 3: aplanamiento de SPF dinámico

El aplanamiento dinámico es un servicio que supervisa en tiempo real las cadenas include de sus proveedores y actualiza automáticamente su registro DNS con las direcciones IP vigentes. Resuelve el problema de las "IP obsoletas" al automatizar la actualización mediante API.

SPF en el contexto de la entrega moderna

Es importante entender que SPF es solo una pieza del rompecabezas de la autenticación. Para que el servidor receptor acepte su correo, debe coordinar SPF con DKIM y DMARC. Encontrará un análisis detallado de estas relaciones en la guía de SendHQ sobre DKIM, SPF y DMARC.

Aceptación, entrega y llegada a la bandeja de entrada

Como ingeniero, distingo entre estas tres etapas:

1. Aceptación: el servidor receptor acepta la conexión y el mensaje. Un permerror de SPF puede hacer que un servidor rechace el mensaje a nivel SMTP, es decir, que nunca llegue a aceptarse.
2. Entrega: el mensaje se acepta y se traslada al buzón del usuario (o a una carpeta).
3. Llegada a la bandeja de entrada: el mensaje aterriza en la bandeja de entrada principal y no en la carpeta de spam.

El aplanamiento de SPF resuelve un problema de aceptación. No garantiza la llegada a la bandeja de entrada, que depende de la reputación del remitente, del contenido y de las métricas de interacción.

Consideraciones especiales para agentes de IA

Con el auge de los agentes de IA que envían correos mediante API, aumenta el riesgo de problemas de SPF, porque los agentes pueden generar grandes volúmenes de correo en distintos dominios. Al crear flujos basados en agentes, trate el envío de correo como un efecto secundario externo.

Idempotencia y aprobación

Los agentes nunca deberían enviar correos en bucle sin un mecanismo de seguridad. Use una clave de idempotencia para garantizar que la lógica de reintentos de su agente no envíe diez veces el mismo correo transaccional a un cliente. Además, para los correos delicados, implemente un paso de aprobación humana antes de realizar la llamada a la API.

Análisis de costos de los proveedores de envío

Al elegir un proveedor para incluir en su registro SPF, tenga en cuenta el costo del volumen que envía. Según los precios de septiembre de 2026:

• Amazon SES: cuesta 0.10 USD por cada 1.000 correos a la carta (precios de Amazon SES). Para 50.000 correos, esto supone unos 5 USD. Los nuevos planes escalonados introducidos el 21 de julio de 2026 incluyen Essentials (0.16 USD por cada 1.000), Pro (0.22 USD por cada 1.000 más 105 USD/mes/región) y Enterprise (0.23 USD por cada 1.000 más 500 USD/mes).
• Postmark: 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.20 USD por cada 1.000 (precios de Postmark). 50.000 correos con los planes de Postmark cuestan aproximadamente 66 USD.
• Resend: el plan gratuito incluye 3.000 correos al mes (con un máximo de 100 al día). Pro cuesta 20 USD al mes por 50.000 correos, con excedentes a 0.90 USD por cada 1.000 (precios de Resend).
• Mailgun: 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.10 USD por cada 1.000 (precios de Mailgun).
• SendGrid: el plan gratuito es ahora una prueba de 60 días, y Essentials empieza en 19.95 USD al mes (precios de SendGrid).

Lista de comprobación para solucionar problemas de SPF

Si sospecha que tiene un problema con el límite de consultas, repase esta lista:

• Ejecute una comprobación de DNS en el dominio raíz y todos los subdominios de envío.
• Cuente el número total de mecanismos include, a, mx y exists.
• Rastree las cadenas de include de cada proveedor para ver si tienen consultas anidadas.
• Identifique y elimine los proveedores que no se usan.
• Evalúe si el tráfico puede trasladarse a un subdominio dedicado (por ejemplo, notifications.example.com).
• Si el límite se sigue superando, implemente el aplanamiento dinámico de SPF.
• Verifique que el registro final no supere el límite de 255 caracteres por cadena.

Tabla resumen: mecanismos SPF

Mecanismo | ¿Consulta DNS? | Riesgo | Recomendación

ip4 / ip6 | No | Bajo | Usar para IP estáticas

include | Sí | Alto | Usar con moderación, supervisar las cadenas

a | Sí | Medio | Evitar si es posible, usar ip4

mx | Sí | Medio | Evitar si es posible

ptr | Sí | Alto | No usar (obsoleto)

Si gestiona sus registros SPF de forma proactiva, evitará el permerror que hunde la entregabilidad antes incluso de que su correo llegue al filtro de spam. Tanto si usa una API sencilla como un sistema complejo basado en agentes, mantener un DNS ligero es la mejor forma de garantizar que se acepte su correo transaccional.

Para disponer de un conjunto completo de herramientas con las que gestionar la autenticación de su dominio, visite https://sendhq.cc.