El límite de consultas SPF es sencillo: si evaluar tu política SPF requiere más de 10 términos que generan consultas DNS, los receptores pueden detener el procesamiento y devolver un error permanente. Así, un correo que parecía estar bien configurado en tu panel DNS puede fallar la autenticación al enviarse. Si ya estás revisando el correo de tu dominio, empieza por correo empresarial para pequeñas empresas y vuelve después para corregir la parte que suele fallar más adelante.
Muchos equipos se encuentran con este problema. Añaden Google Workspace, después Microsoft 365, Mailchimp, un CRM y una plataforma de soporte. Cada proveedor dice: «Solo tienes que añadir nuestro include». Meses después, el registro SPF tiene una sintaxis válida, pero deja de funcionar en la práctica. El correo empieza a llegar a spam. Algunos mensajes rebotan. Nadie sabe por qué, porque a primera vista el registro parece normal.
La buena noticia es que la solución suele ser sencilla. Elimina las entradas obsoletas. Deja de usar `mx` salvo que realmente lo necesites. Separa el tráfico de marketing en un subdominio. Mantén limpio el dominio principal.
¿Qué es el límite de consultas SPF?
El límite de consultas SPF es el máximo que establece el RFC para los términos SPF que generan consultas DNS durante la evaluación. Los receptores no deben procesar más de 10 de estos términos en la ruta evaluada del árbol SPF, incluidas las cadenas de `include` anidados. Si tu política supera ese máximo, SPF puede devolver `permerror` y el mensaje pierde una señal de autenticación importante.
El RFC 7208 define esta regla. El límite evita que SPF se convierta en un problema de amplificación DNS. No es opcional ni una recomendación de buenas prácticas: es un límite del protocolo.
Un detalle que suele pasar desapercibido es que el límite de consultas SPF es acumulativo. No dispones de 10 consultas en el registro raíz y otras 10 dentro de cada include. Hay un único presupuesto para toda la ruta de evaluación.
| Mecanismo SPF | Coste en consultas | Aplicación práctica |
|---|---|---|
include: | 1 | Habitual, pero los includes anidados se acumulan rápidamente |
a | 1 | Adecuado en configuraciones pequeñas; a menudo innecesario |
mx | 1+ | Suele ser una mala opción para autorizar envíos |
ptr | 1+ | Evítalo; el RFC 7208 desaconseja expresamente su uso |
exists | 1 | Poco habitual y fácil de usar incorrectamente |
redirect= | 1 | Útil en diseños concretos, pero también cuenta |
ip4 / ip6 | 0 | No genera consultas DNS durante la evaluación SPF |
all | 0 | Solo expresa la política; no consume consultas |
Por qué el límite de consultas SPF hace fallar registros que «funcionan»
El límite de consultas SPF hace fallar registros aparentemente correctos porque SPF no evalúa lo ordenado que se ve el TXT raíz. Cuenta los términos que generan consultas DNS y que el receptor debe evaluar al seguir include, redirect, `a` y `mx` en la ruta completa.
Ejemplo:
Publicas `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` y crees que has consumido tres consultas. No es así. Los registros de Google y Microsoft se expanden a más consultas internas. El registro que ves es corto; el que se evalúa no lo es.
Por eso el límite de consultas SPF suele dar problemas después, no el primer día. Cuando los proveedores modifican sus propios árboles SPF, tu recuento puede aumentar aunque no vuelvas a editar el DNS.
Hay otra trampa: las consultas vacías. El RFC 7208 recomienda que las implementaciones las limiten a dos. Una consulta vacía es una consulta DNS que no devuelve respuestas o devuelve `NXDOMAIN`. Un error tipográfico en un include puede no ser fatal. Dos referencias incorrectas pueden causar un fallo. Así, el problema del límite de consultas SPF se convierte en un `permerror` incluso si sigues por debajo de 10.
Las directrices de Google para remitentes también muestran lo que está en juego: una autenticación ausente o incorrecta puede provocar que el correo de remitentes masivos se rechace o llegue a spam. Google indica que estos remitentes deben configurar SPF, DKIM y DMARC, y que los mensajes que no cumplan los requisitos pueden rechazarse o dirigirse a spam. Consulta las preguntas frecuentes sobre los requisitos de Google para remitentes.
Cómo calcular el uso del límite de consultas SPF
Para calcular el consumo del límite de consultas SPF, empieza por el registro SPF raíz y cuenta los mecanismos que generan consultas DNS en cada ruta de evaluación del árbol recursivo. Incluye tus propios términos y los que referencian tus proveedores. Si una ruta supera 10, la política puede fallar en la práctica.
Empieza por el registro raíz:
dig +short txt example.comEjemplo de resultado:
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"Después, revisa cada dominio referenciado:
dig +short txt _spf.google.com
dig +short txt spf.protection.outlook.comSigue las referencias hasta encontrar únicamente `ip4`, `ip6` o términos finales de la política.
Usa este modelo de recuento:
- Cuenta cada
include,a,mx,ptr,existsyredirectque encuentres. - Cuenta también los términos anidados dentro de los registros incluidos.
- No cuentes
ip4,ip6niall. - Marca cualquier destino de include que no devuelva datos. Puede ocasionar un problema de consultas vacías.
Si necesitas una comprobación rápida del DNS al configurar un dominio en TrekMail, empieza por la documentación sobre comprobación del estado DNS y registros DNS necesarios.
Errores habituales relacionados con el límite de consultas SPF
La mayoría de los fallos del límite de consultas SPF se deben a errores recurrentes: acumular proveedores en un dominio raíz, mantener proveedores antiguos, usar `mx` como atajo y aplanar registros manualmente sin un proceso de mantenimiento. No son casos excepcionales, sino problemas de mantenimiento del DNS que se agravan al crecer.
Los errores más comunes:
| Error | Por qué perjudica | Mejor alternativa |
|---|---|---|
| Mantener proveedores antiguos | Consume consultas y amplía el riesgo | Elimina todo servicio que ya no uses para enviar |
Usar mx para autenticar envíos | Los servidores MX de recepción a menudo no son tus remitentes | Autoriza expresamente al remitente real |
Usar ptr | Es lento, desaconsejado y frágil | Elimínalo |
| Enviar todo desde un dominio | El marketing y el correo transaccional compiten por el mismo presupuesto SPF | Separa los flujos en subdominios |
| Aplanar manualmente | Puede fallar cuando los proveedores cambian sus IP | Automatiza las actualizaciones o evita el aplanamiento |
Aquí también se suele confundir la complejidad visible con la real. Un solo include de un proveedor puede consumir varias consultas al expandirse. Por eso el límite de consultas SPF acaba pasando factura a la idea de «añadir solo un remitente más».
Si todavía estás decidiendo entre reenviar correo, crear un alias o disponer de un buzón real para una tarea, estas opciones están más relacionadas con la configuración de los remitentes de lo que parece. Lecturas relacionadas: alias de correo de dominio frente a buzón y reenvío mediante alias de correo.
Cómo corregir el límite de consultas SPF sin interrumpir el correo
La forma más prudente de resolver el límite de consultas SPF es reducir la complejidad, no acumular soluciones improvisadas. Primero elimina los remitentes obsoletos. Después, mueve los sistemas de mayor volumen a subdominios. Recurre al aplanamiento solo si puedes mantenerlo actualizado automáticamente.
1. Elimina lo que sobra.
Borra los proveedores que ya no usas. Elimina `ptr`. Sustituye `mx` por la autorización del remitente que realmente necesitas. Muchas políticas SPF problemáticas vuelven a quedar por debajo del límite de consultas SPF con una revisión de limpieza.
2. Separa el tráfico por subdominio.
Suele ser una buena solución para equipos en crecimiento.
; Primary company mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"
; Marketing mail
marketing.example.com. TXT "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"
; Transactional app mail
notify.example.com. TXT "v=spf1 include:amazonses.com -all"Cada subdominio tiene su propio presupuesto SPF. Esto ayuda a mantener estable el dominio raíz y facilita mucho la gestión del límite de consultas SPF.
3. Aplana solo como último recurso.
El aplanamiento sustituye los includes por rangos IP explícitos:
; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all
; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -allReduce el consumo de consultas hasta casi cero, pero genera trabajo de mantenimiento. Los proveedores cambian sus IP y el registro puede quedar obsoleto, causando fallos de correo. Si aplanas, automatiza las actualizaciones.
Enfoque anterior y enfoque nuevo: gestionar el límite de consultas SPF con TrekMail
El enfoque anterior para gestionar el límite de consultas SPF consiste en acumular proveedores de buzones, plataformas de marketing y relés en un dominio raíz hasta que revisar el DNS exige reconstruir toda su historia. El enfoque nuevo reduce las dependencias y separa las funciones de envío desde el principio.
Enfoque anterior: un registro SPF raíz sobrecargado, proveedores antiguos aún presentes, marketing mezclado con correo de buzones y ninguna responsabilidad clara sobre quién puede enviar.
Enfoque nuevo: simplificar el alojamiento de buzones, aislar los remitentes de gran volumen en subdominios y mantener una política SPF corta con margen en el dominio principal.
TrekMail puede ayudar en esta organización. Si usas el envío gestionado de TrekMail en un plan de pago, la configuración descrita consiste en añadir `include:spf.trekmail.net` a tu registro SPF. Ese término consume una consulta directa; conviene comprobar también cualquier dependencia anidada. La oferta descrita parte de $3.50/mes e incluye dominios propios, buzones IMAP, catch-all, reenvío de buzones, una herramienta de migración integrada y acceso API. Los planes de pago contemplan una prueba gratuita de 14 días con tarjeta de crédito. Nano se presenta como un plan gratuito, sin prueba y con BYO SMTP; comprueba las condiciones vigentes.
Con Nano, TrekMail puede servir como capa de buzones mientras envías mediante SES, Mailgun u otro relé. Organiza bien los subdominios para que la política raíz no alcance el límite de consultas SPF. La documentación de TrekMail sobre SMTP personalizado (BYO), SMTP gestionado de TrekMail y inicio de una migración desde el panel explica los aspectos operativos.
Si estás consolidando dominios, también pueden interesarte alojamiento de correo multidominio y configurar correo en mi dominio.
Conclusión: cómo mantenerse por debajo del límite de consultas SPF
La mejor forma de respetar el límite de consultas SPF es mantener una configuración sencilla. Usa el menor número posible de remitentes en el dominio raíz. Lleva el correo masivo y el de aplicaciones a subdominios. Revisa los includes de los proveedores cada vez que añadas una herramienta. Si tu política se acerca a 10, considéralo una señal de riesgo.
Esa es la cuestión. El límite de consultas SPF no es un caso teórico poco habitual del RFC, sino una restricción operativa que complica el crecimiento basado en acumular servicios. Mantén el registro corto y las responsabilidades sobre el DNS claras. No hagas que cinco proveedores compartan una única ruta de autenticación con presupuesto limitado, salvo que te guste analizar cabeceras de correo a las 2 de la mañana.
Si buscas una configuración más sencilla, TrekMail ofrece alojamiento de correo multidominio con tarifa fija, sin cargos por usuario, almacenamiento compartido, migración IMAP integrada y la opción de BYO SMTP o SMTP gestionado por TrekMail, según la oferta y el plan vigentes. Consulta los precios de TrekMail o visita TrekMail.
