Límite de consultas SPF: diagnóstico y soluciones

El límite de consultas SPF puede parecer un problema DNS menor hasta que falla la autenticación. Añades otro remitente, otro CRM o una herramienta de soporte, y la política supera un límite del protocolo. El mensaje puede entonces recibir un tratamiento distinto, como filtrado o rechazo, según las reglas del receptor.

Para entender cómo encaja SPF en tu configuración, empieza por correo empresarial. El contexto importa: SPF no es una casilla de imagen de marca. Es una señal de autenticación que los receptores pueden utilizar al evaluar el correo.

Esta guía explica qué limita SPF, qué términos cuentan, por qué aplanar el registro introduce obligaciones de mantenimiento y qué alternativas conviene evaluar para una configuración sostenible.

Qué es el límite de consultas SPF

El límite de consultas SPF restringe los términos que requieren búsquedas DNS durante la evaluación, no simplemente todos los paquetes DNS enviados. Según RFC 7208, el límite es 10; superarlo produce permerror en lugar de una evaluación aprobada.

En resumen, SPF tiene un presupuesto. Si la evaluación utiliza más de 10 términos que requieren consultas DNS, el receptor debe detenerla y devolver un error permanente. No es una particularidad de Gmail, sino una regla de SPF.

RFC 7208 identifica los términos que consumen ese presupuesto: include, a, mx, ptr, exists y redirect. En cambio, ip4, ip6 y all no cuentan para este límite durante la evaluación.

La diferencia importa porque la longitud del registro no equivale a su coste de evaluación. Un registro corto puede fallar y otro más largo puede evaluarse correctamente. Hay que estudiar los términos que realmente se recorren y sus dependencias.

Qué cuenta para el límite de consultas SPF

El límite de consultas SPF cuenta los mecanismos y modificadores relevantes que requieren DNS, no las palabras del TXT. También cuentan los términos correspondientes dentro de includes anidados. Por eso el registro visible en tu panel puede ocultar parte del coste real.

Estos términos consumen presupuesto cuando se evalúan:

1. include: evalúa la política SPF de otro dominio y coincide si esa evaluación devuelve pass.
2. a: consulta las direcciones del nombre indicado y las compara con la IP de conexión.
3. mx: obtiene los servidores MX y consulta sus direcciones, con límites adicionales propios.
4. ptr: realiza comprobaciones inversas y directas; su uso está desaconsejado.
5. exists: consulta registros A del nombre indicado y coincide si devuelve alguno.
6. redirect: delega en otra política SPF si ningún mecanismo anterior coincide.

Estos términos no consumen ese presupuesto de consultas durante la evaluación SPF:

• ip4
• ip6
• all

La dificultad es que el cómputo incluye la evaluación recursiva. Si incluyes a Microsoft y su política incluye otra política, los términos relevantes evaluados dentro de ella también cuentan. Tu configuración depende de la estructura SPF de los proveedores.

Crees haber añadido 6 remitentes. Tras recorrer las dependencias, el receptor puede evaluar 11 o 12 términos sujetos al límite. Así puedes superar el presupuesto SPF aunque pensabas estar por debajo de 10.

Por qué afecta a los equipos que incorporan herramientas

El límite de consultas SPF suele convertirse en un problema al añadir servicios. Marketing, soporte, selección de personal, CRM y correo transaccional pueden solicitar un include en la política del mismo dominio, aunque no todos necesitan compartir el dominio del remitente del sobre.

Al principio, el registro puede ser sencillo. Los siguientes ejemplos son ilustrativos; verifica los valores actuales del proveedor antes de publicar:

v=spf1 include:_spf.google.com ~all

Después se amplía la configuración:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

Ya no mantienes solo una lista local. Mantienes una cadena de dependencias que los proveedores pueden modificar.

Por eso el problema puede parecer aleatorio en producción. Tu DNS no cambió esta mañana, pero un proveedor pudo ampliar sus dependencias. Una ruta que antes se evaluaba correctamente puede ahora devolver permerror. Conviene volver a medir después de cambios y revisar periódicamente.

Si el problema de entrega parece más amplio que SPF, consulta por qué los correos van a spam en TrekMail. Autenticación, reputación y contenido son señales diferentes que pueden intervenir a la vez.

Qué ocurre al superar el límite

Cuando se supera el límite de consultas SPF, la evaluación devuelve permerror. Eso no obliga a todos los receptores a tratar el mensaje igual, pero elimina una aprobación SPF válida de esa evaluación.

No existe una aprobación parcial por quedarse cerca del presupuesto. Aun así, el resultado SPF no determina por sí solo DMARC ni la entrega final.

Las recomendaciones de Google relacionan la entrega con autenticación y alineación correctas, con requisitos según el tipo de remitente. Si envías a Gmail a gran escala, revisa SPF y DKIM y el alcance vigente de las directrices para remitentes.

También conviene conocer otros dos límites relacionados:

1. Consultas sin respuesta útil. RFC 7208 recomienda limitar a dos las consultas que devuelven nombre inexistente o ausencia de datos. Un error en un include o un dominio retirado merece revisión, aunque sus efectos dependen del resultado DNS y de la evaluación.
2. Tamaño de las respuestas DNS. Una respuesta grande puede truncarse y exigir otro transporte. Si ese recurso falla, pueden aparecer errores temporales o tiempos de espera; un registro grande no provoca necesariamente el fallo.

Por qué aplanar SPF no siempre es la mejor solución

El límite de consultas SPF invita a sustituir includes por direcciones IP. Es el aplanamiento, o flattening. Reduce términos sujetos a consultas, pero transfiere a quien publica el registro la responsabilidad de mantener las autorizaciones.

Un ejemplo de aplanamiento manual:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Estos términos no consumen el presupuesto indicado. Sin embargo, los proveedores SaaS pueden cambiar rangos e infraestructura. Si no actualizas el registro, puedes dejar fuera remitentes legítimos o seguir autorizando IP que ya no corresponden. Los rangos del ejemplo son ilustrativos.

Una práctica anterior era acumular proveedores en el SPF raíz y aplanarlo cuando se complicaba.

Una alternativa consiste en separar funciones de envío por subdominios, mantener políticas acotadas y configurar DKIM alineado. Puede facilitar mantenimiento y atribución de problemas, siempre que los servicios usen realmente esos subdominios en sus identidades SMTP.

Con TrekMail, compara las condiciones actuales del alojamiento multidominio y la facturación sin cargos por buzón o dominio, en lugar de asumir que todos los proveedores antiguos cobran igual. Sus funciones pueden incluir dominios personalizados, buzones IMAP, catch-all, migración, reenvío y SMTP externo o administrado según el plan. La fuente describe SMTP propio en Free y SMTP administrado en planes de pago; confirma disponibilidad y límites actuales. Consulta registros DNS necesarios y SMTP personalizado (BYO).

Una solución sostenible: segmentar los remitentes

Una opción a largo plazo para el límite de consultas SPF es la segmentación. Separa correo corporativo, marketing, soporte y transacciones cuando los proveedores permitan configurar los dominios del remitente del sobre. Cada política puede entonces tener sus propias dependencias; no es un aislamiento absoluto de reputación.

Este modelo puede servir de referencia:

1. Dominio raíz para correspondencia personal. Ejemplo: alice@company.com.
2. Subdominio de marketing. Ejemplo: newsletter.company.com.
3. Subdominio de soporte. Ejemplo: support.company.com.
4. Subdominio transaccional. Ejemplo: updates.company.com.

Registros ilustrativos, que deben adaptarse al dominio realmente usado en el sobre:

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

Si las identidades de envío usan políticas independientes, cada evaluación tiene su presupuesto de 10 términos. Publicar TXT en otros subdominios o cambiar solo el From visible no divide el coste de la política original. Comprueba además DMARC: la alineación relajada admite el mismo dominio organizativo y la estricta exige coincidencia exacta. Una firma DKIM válida y alineada también puede proporcionar la aprobación.

La separación también puede facilitar el seguimiento de reputación por flujo, pero los receptores pueden relacionar subdominios, dominio organizativo e IP compartidas. No protege automáticamente el correo raíz frente a malas prácticas de marketing.

Si empiezas desde cero, consulta añadir un dominio y verifica DNS con pruebas reales. Para dejar proveedores antiguos, la migración IMAP puede ayudar a copiar datos de buzones según los recursos disponibles. DNS, remitentes de aplicaciones y autenticación requieren trabajo aparte.

Cómo comprobar el coste de evaluación SPF

Mide el límite de consultas SPF, no lo calcules por intuición. Obtén el TXT y recorre cada include y sus dependencias, teniendo en cuenta la ruta de evaluación para las IP y las identidades reales.

Empieza con dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Después cuenta los términos relevantes que se evalúan, incluidos los anidados. Estas consultas muestran registros, pero no sustituyen una evaluación SPF completa.

Un procedimiento práctico:

1. Obtén el TXT SPF del dominio usado en el remitente del sobre.
2. Enumera include, a, mx, exists y redirect; revisa también cualquier mecanismo de consulta inversa heredado.
3. Recorre las políticas anidadas y respeta la semántica y el orden de evaluación.
4. Retira servicios que ya no envían, después de verificar el inventario.
5. Evalúa subdominios y prueba las identidades antes de recurrir al aplanamiento.

Comprueba también que no haya SPF duplicado. Debe publicarse una sola política SPF por nombre, integrando las autorizaciones, no registros SPF separados para cada servicio. Para reorganizar una configuración compleja, consulta crear correo con dominio, alojamiento multidominio e imapsync.

El papel de TrekMail en una configuración mantenible

TrekMail no elimina el límite de consultas SPF. Es una restricción del protocolo. Su modelo puede facilitar una arquitectura con menos cuentas dispersas, pero el coste y la sencillez dependen de tus necesidades y del plan.

Esto puede resultar relevante para dos grupos.

Los equipos pequeños pueden mantener una política sencilla para la correspondencia raíz y elegir SMTP propio o administrado donde corresponda. Agencias y proveedores de servicios gestionados pueden separar tráfico de clientes y comparar funciones de incorporación de dominios y tarifas sin cargos por usuario. Hay que confirmar los recursos actuales y documentar las identidades de cada remitente.

Enfoque anterior frente a enfoque actual:

Anterior: reunir correspondencia, alias, aplicaciones y marketing en un proveedor y una política SPF para evitar posibles costes adicionales.

Actual: evaluar una plataforma multidominio con tarifa fija, centralizar buzones IMAP, separar identidades por subdominio y mantener políticas revisadas frente a cambios de proveedores.

Según la fuente, Starter empieza en $3.50 al mes. Free cuesta $0 e incluye 10 dominios, 5GB de almacenamiento compartido y SMTP propio. Los planes de pago añaden SMTP administrado, límites superiores y automatización según la oferta. Precios, nombres de planes y recursos pueden cambiar; consulta los precios de TrekMail.

Conclusión: trata el límite SPF como una restricción de diseño

El límite de consultas SPF es una restricción del protocolo que conviene incluir en el diseño. Si incorporas herramientas, reserva margen y revisa dependencias, sin asumir que cualquier ampliación acabará necesariamente en un fallo.

No esperes a permerror para revisar una política sobrecargada. Inventaría remitentes, retira autorizaciones obsoletas verificadas y considera separar flujos por subdominios. Prueba SPF y la alineación DMARC después de los cambios y prepara una reversión si afectan al tráfico legítimo.

Para gestionar esta arquitectura en pocos o muchos dominios, compara las funciones actuales de TrekMail: dominios personalizados, buzones IMAP, almacenamiento compartido, migración de buzones y opciones SMTP bajo condiciones sin cargos por usuario. Consulta la oferta gratuita en trekmail.net o compara planes en trekmail.net/pricing. Ninguna plataforma garantiza por sí sola DNS correcto ni entrega a la bandeja de entrada.