SPF: demasiadas búsquedas DNS — Redúcelo con seguridad y pasa las comprobaciones

Tu correo saliente está “configurado”, tu DNS parece “bien”, y aun así la entregabilidad se hunde de la noche a la mañana porque SPF devuelve permerror: demasiadas búsquedas DNS. Marketing jura que no cambiaron nada. Tu mesa de ayuda jura que cambiaron todo. Toca ser el adulto en la sala.

Este es uno de esos fallos que parece un problema menor de formato hasta que recuerdas que es autenticación. Los receptores no negocian con la autenticación. Juzgan, a escala y en silencio.

Qué significa realmente “demasiadas búsquedas DNS”

SPF (Sender Policy Framework) lo evalúa el servidor de correo receptor. Cuando ven un mensaje que afirma ser de user@yourdomain, consultan el registro SPF de tu dominio (un TXT que empieza por v=spf1) y evalúan si la IP emisora está autorizada.

Durante la evaluación, ciertos mecanismos de SPF obligan al receptor a consultar DNS. La especificación limita cuántos mecanismos basados en DNS se pueden expandir. Si la evaluación requiere más de 10 búsquedas DNS, el receptor debe detenerse y devolver permerror (error permanente). “Permanente” aquí significa: no vale la pena reintentar; la política está rota.

Así que “demasiadas búsquedas DNS” no es una advertencia. Es el receptor negándose a seguir haciendo tu tarea.

Detalle operativo importante: el recuento de búsquedas no es “cuántos TXT ves tú personalmente”. Es cuántas consultas DNS podría necesitar el receptor tras seguir includes, redirects y resolver objetivos A/MX. Los includes pueden explotar recursivamente. Una plataforma de marketing que parece inofensiva puede arrastrar la mitad del universo SaaS.

Broma #1: SPF es el único sitio donde “solo un include más” parece inocuo hasta que se convierte en toda tu personalidad y Gmail deja de devolver tus llamadas.

Hechos y contexto que puedes usar en reuniones

• SPF es anterior a DMARC. SPF nació para reducir la suplantación de remitente mucho antes de que DMARC convirtiera la “alineación” en palabra de junta directiva.
• El límite de 10 búsquedas es fricción deliberada. Los receptores no pueden permitir que los remitentes forcen una recursión DNS ilimitada; es una medida de control de recursos y abuso.
• La evaluación SPF ocurre en el receptor. Que tu MTA saliente registre “SPF pasado” no es autoritativo. Solo cuenta la evaluación del receptor.
• Algunos mecanismos no cuestan búsquedas. Las semánticas de ip4, ip6, all y exists importan; solo ciertos mecanismos disparan búsquedas DNS.
• Los includes son el culpable habitual. Los proveedores distribuyen fragmentos SPF con include: porque es cómodo para ellos, no porque sea económico para ti.
• Los receptores varían en caché y comportamiento de resolutor. La especificación es clara sobre el límite, pero la forma de alcanzarlo puede diferir según el cacheo DNS y la configuración de recursión.
• Los errores SPF pueden matar silenciosamente la entregabilidad. Algunos receptores tratan permerror como fallo, otros como neutral con peso en el scoring de spam. En cualquier caso, pierdes.
• Un dominio puede tener varios registros TXT, pero SPF no debería. Múltiples registros SPF en el mismo nombre pueden causar “permerror: multiple SPF records”, una falla distinta pero igual de irritante.

Guía rápida de diagnóstico

Este es el orden que encuentra el cuello de botella más rápido, sin convertirte en arqueólogo DNS durante una semana.

Primero: confirma el modo de fallo desde la perspectiva del receptor

• Mira una muestra real de cabeceras desde un receptor que rechazó o puso el correo en spam.
• Extrae el resultado SPF: pass, fail, neutral, softfail, temperror, permerror.
• Si es permerror con “too many DNS lookups” (o “exceeded maximum DNS lookups”), tienes un problema de expansión SPF, no de propagación DNS.

Segundo: calcula el recuento de búsquedas para tu registro SPF

• Recupera el TXT SPF actual y enumera los mecanismos.
• Sigue include y redirect recursivamente.
• Cuenta los mecanismos que disparan DNS: include, a, mx, ptr (no lo hagas), exists, redirect.

Tercero: identifica qué includes de proveedores son innecesarios o duplicados

• Lista cada sistema que realmente envía correo con tu dominio: tu MTA, Microsoft 365/Google Workspace, ticketing, CRM, automatización de marketing, facturación, plataforma de RR. HH., etc.
• Mapea esos sistemas a mecanismos SPF. Elimina los que no envían con tu dominio o que pueden moverse a un subdominio.

Cuarto: arregla empezando por la reducción de menor riesgo

• Sustituye a/mx por ip4/ip6 explícitos cuando sean estables.
• Colapsa includes redundantes (algunos proveedores incluyen a otros que ya incluyes).
• Usa subdominios para emisores de alta rotación y alinea DMARC apropiadamente.

Mecanismos SPF que agotan el presupuesto de búsquedas

No todo en SPF cuesta búsquedas. El presupuesto se consume por consultas DNS durante la evaluación.

Mecanismos que típicamente disparan búsquedas DNS

• include: cuesta al menos una búsqueda por el SPF del dominio incluido; puede encadenarse.
• redirect= similar a include en términos de búsquedas; transfiere la evaluación a otro registro.
• a y mx: cuestan búsquedas para resolver objetivos A/AAAA o MX y luego sus A/AAAA.
• exists: cuesta una búsqueda DNS para el nombre generado.
• ptr: cuesta múltiples consultas y está ampliamente desaconsejado; muchos evaluadores lo tratan duramente. No lo uses.

Mecanismos que no consumen el límite de búsquedas

• ip4, ip6: rangos IP directos en el registro. No requieren DNS.
• all: mecanismo terminador (-all, ~all, etc.). No requiere DNS.

Por qué “solo 10” duele en el mundo SaaS moderno

Diez búsquedas era generoso cuando “tu sistema de correo” significaba uno o dos MTAs y quizá un proveedor de respaldo. En 2026, tu huella de correo es un zoológico: producto envía onboarding, finanzas envía recibos, RR. HH. envía notificaciones, marketing envía campañas y media docena de herramientas envían notificaciones. SPF se convierte en un espacio de nombres compartido sin modelo de propiedad. Así es como llegas a 11 búsquedas sin que nadie lo note.

Audita tu SPF como un SRE

No trates al SPF como una cadena. Trátalo como un grafo de dependencias con dominios de fallo.

Inventario de remitentes, no de proveedores

Empieza con “¿quién realmente envía correo usando @yourdomain en el RFC5321 MAIL FROM (envelope from)?” Eso es lo que SPF evalúa. Un proveedor puede enviar correo mostrando tu dominio en el From visible mientras usa su propio dominio de sobre de correo. En ese caso, el SPF de tu dominio raíz es irrelevante y estás gastando presupuesto de búsquedas por nada.

Separa los emisores de alta rotación

Las plataformas de marketing cambian IPs y contenido de include con frecuencia. Los MTAs transaccionales (propios o un proveedor estable) son relativamente constantes. Poner todo en un registro SPF acopla tasas de cambio no relacionadas. Usa subdominios para aislar la rotación: m.yourdomain para marketing, notify.yourdomain para producto, billing.yourdomain para finanzas, etc. Luego alinea DMARC (o usa políticas DMARC separadas por subdominio) según tolerancia al riesgo.

Prefiere IPs explícitas cuando las controles

Si operas MTAs salientes con IPs de egreso estables, usa ip4/ip6. Los includes son para delegar a terceros. Delegar es conveniente, pero también es ceder a otro el derecho a gastar tu presupuesto de búsquedas.

Sé conservador con el “flattening”

Aplanar significa resolver includes y convertir los rangos IP resultantes en ip4/ip6 explícitos en tu registro. Reduce búsquedas, pero crea una obligación de mantenimiento: si el proveedor cambia rangos IP, debes actualizar tu SPF. Esto es seguro solo si puedes automatizarlo o aceptar el riesgo de desalineación periódica.

Broma #2: Aplanar SPF manualmente es como editar a mano una tabla de enrutamiento: te forma carácter, mayormente en forma de remordimiento.

Tareas prácticas con comandos, salidas y decisiones

Estas son tareas de campo que puedes ejecutar desde un equipo Linux con herramientas estándar. Cada tarea incluye qué buscar y la decisión a tomar. Asume que estás probando example.com; sustituye por tu dominio.

Task 1: Fetch the domain’s TXT records and spot SPF candidates

cr0x@server:~$ dig +noall +answer TXT example.com
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
example.com.     300 IN TXT "google-site-verification=abc123"

Qué significa: El SPF es la cadena TXT que empieza por v=spf1. Si ves más de un v=spf1 TXT en el mismo nombre, eso es otro permerror (múltiples registros SPF).

Decisión: Confirma que hay exactamente un registro SPF en el dominio organizacional (o intencionalmente en un subdominio). Si hay múltiples, consolida primero.

Task 2: Check for multiple SPF records (common after “DNS cleanup”)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
1

Qué significa: Conteo de registros SPF devueltos. Cualquier valor mayor que 1 es problemático.

Decisión: Si >1, combínalos en un solo registro y elimina los demás. Los receptores pueden tratar múltiples como permerror aunque el conjunto combinado sería válido.

Task 3: Pull the exact SPF string for parsing

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1'
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Qué significa: Has obtenido el contenido crudo sin comillas.

Decisión: Guarda esta cadena en las notas del incidente. Trata los cambios SPF como cambios de código: quieres un diff antes/después.

Task 4: Enumerate includes quickly

cr0x@server:~$ dig +short TXT _spf.google.com | sed 's/"//g'
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Qué significa: Un include puede expandirse en varios includes. Así es como te quedas sin presupuesto.

Decisión: Construye un grafo de includes. Si tu registro raíz ya incluye dos proveedores y cada uno se expande en 3–6 includes, probablemente estés cerca del límite.

Task 5: Check if you’re using expensive mechanisms (mx/a/ptr)

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | egrep '^(a|mx|ptr|exists)'
mx

Qué significa: Este SPF usa mx, lo cual cuesta búsquedas DNS (MX + resolución A/AAAA) durante la evaluación.

Decisión: Si no necesitas mx/a, elimínalos. Si los necesitas, considera reemplazarlos por rangos IP explícitos.

Task 6: Inspect MX targets and their A/AAAA records (lookup budget cost)

cr0x@server:~$ dig +noall +answer MX example.com
example.com. 300 IN MX 10 mail1.example.com.
example.com. 300 IN MX 20 mail2.example.com.

cr0x@server:~$ dig +noall +answer A mail1.example.com
mail1.example.com. 300 IN A 203.0.113.10

Qué significa: Si SPF usa mx, el evaluador puede necesitar resolver estos nombres. Eso consume búsquedas.

Decisión: Si los hosts MX son solo para correo entrante y no para salida, no uses mx en SPF. SPF es para autorización de salida, no para enrutamiento de entrada.

Task 7: Verify what IP your outbound mail actually uses

cr0x@server:~$ grep -R "client-ip" -n /var/log/mail.log | tail -n 3
/var/log/mail.log:98765: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98766: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98767: ... client-ip=198.51.100.24 ...

Qué significa: Tus logs pueden revelar la IP de egreso usada para la entrega SMTP (depende del MTA y formato de logs).

Decisión: Si controlas la IP y es estable, autorízala explícitamente con ip4:198.51.100.24 y reduce la dependencia de mecanismos DNS.

Task 8: Count lookups with a purpose-built SPF checker (local tool)

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@example.com

Qué significa: spfquery evalúa SPF de forma similar a los receptores. No todas las versiones imprimen recuentos de búsquedas, pero sigue siendo útil para comprobaciones funcionales.

Decisión: Usa esto para validar que tu SPF candidato sigue pasando para emisores conocidos después de cambios. Si cambia a fail/neutral, rompiste la autorización.

Task 9: Trace DNS resolution paths and TTLs (caching matters)

cr0x@server:~$ dig +trace TXT example.com | tail -n 8
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
;; Query time: 42 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Sat Jan 03 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 164

Qué significa: Puedes ver TTLs y si la delegación es sensata. El TTL influye en la frecuencia con que los receptores necesitan volver a obtener registros, pero no cambia el límite duro de 10 búsquedas.

Decisión: Si los TTLs son extremadamente bajos (como 30s) para registros relacionados con SPF, considera aumentarlos para reducir la rotación y fallos DNS intermitentes. No solucionará “demasiadas búsquedas”, pero reduce temperrors.

Task 10: Detect “SPF record too long” risk when flattening

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | wc -c
142

Qué significa: Conteo de caracteres de la cadena SPF actual (aprox.). Las cadenas TXT tienen restricciones de tamaño; los proveedores y receptores pueden tener límites de implementación. También las respuestas DNS pueden alcanzar límites de tamaño UDP si te pasas.

Decisión: Si aplanar convertiría tu SPF en un zoo de IPs de 1.800 caracteres, replantea. Más corto no es solo estético; se entrega más fiable por DNS.

Task 11: Check for accidental recursion via redirect/include loops

cr0x@server:~$ dig +short TXT spf-a.example.com | sed 's/"//g'
v=spf1 include:spf-b.example.com -all

cr0x@server:~$ dig +short TXT spf-b.example.com | sed 's/"//g'
v=spf1 include:spf-a.example.com -all

Qué significa: Esto es un bucle. Los evaluadores alcanzarán límites o fallarán.

Decisión: Rompe el bucle inmediatamente. Los grafos SPF deben ser acíclicos. Si necesitas contenido compartido, usa un único registro compartido incluido por otros, no referencias circulares.

Task 12: Validate that each third-party include is still live and resolvable

cr0x@server:~$ dig +noall +answer TXT spf.vendor-example.net
spf.vendor-example.net. 300 IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Qué significa: Los proveedores ocasionalmente deprecian hostnames SPF. Si un include objetivo hace NXDOMAIN o responde con timeout, los receptores pueden devolver temperror o permerror según su comportamiento.

Decisión: Si el include objetivo no resuelve de forma fiable, elimínalo o reemplázalo por un mecanismo soportado. Tu SPF no debería depender de un nombre DNS abandonado por un proveedor.

Task 13: Spot “include everything” anti-patterns

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | grep '^include:' | sort
include:_spf.google.com
include:mailgun.org
include:spf.protection.outlook.com
include:sendgrid.net
include:spf.salesforce.com
include:spf.zendesk.com

Qué significa: Este dominio está intentando autorizar media Internet. Algunos de estos servicios podrían ni siquiera enviar con tu envelope-from.

Decisión: Cuestionalos uno por uno con evidencia: “Muéstrame un mensaje donde el envelope-from sea nuestro dominio y vino de ese proveedor.” Elimina includes que no sean necesarios.

Task 14: Quick check of a candidate reduced SPF before publishing (staging name)

cr0x@server:~$ dig +short TXT spf-test.example.com | sed 's/"//g'
v=spf1 ip4:198.51.100.24 include:spf.protection.outlook.com -all

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@spf-test.example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@spf-test.example.com

Qué significa: Puedes probar un registro SPF candidato en un subdominio antes de cambiar producción. SPF se aplica por nombre de dominio, así que puedes ensayar.

Decisión: Siempre prepara cambios cuando sea posible. Publícalo en spf-test, valida y luego pásalo al dominio real durante una ventana de cambio controlada.

Estrategias para reducir sin prender fuego al correo

Solo hay unas pocas formas honestas de quedarse por debajo del límite de búsquedas. Cualquiera que prometa un “compresor” mágico de SPF o está aplanando, o eliminando autorizaciones, o escondiendo búsquedas en otro sitio.

1) Elimina lo que no usas (la victoria más fácil)

La mayoría de los registros SPF hinchados cargan includes muertos: proveedores que diste de baja, pilotos olvidados, unidades de negocio regionales haciendo lo propio. SPF no avisa de “include no usado”. Toca disciplina.

Cómo hacerlo de forma segura:

• Recolecta una semana de muestras salientes de cada sistema. Observa el Return-Path y la identidad autenticada por SPF en los receptores.
• Mantén includes solo para sistemas que realmente usan tu dominio en el envelope-from.
• Si un proveedor envía con su propio dominio de rebote, deja de autorizarlo en tu dominio raíz. No aporta nada.

2) Mueve emisores de alta rotación a subdominios

Esta es la solución de adulto. Te da registros SPF independientes y dominios de fallo independientes.

Ejemplo:

• example.com: correo corporativo (M365), relays internos.
• m.example.com: SPF de la plataforma de marketing (y DKIM/DMARC alineados a ese subdominio).
• notify.example.com: proveedor de notificaciones del producto.

Qué vigilar: Alineación DMARC. Si usas DMARC con alineación estricta, asegúrate de que el From visible coincida con el dominio envelope-from o con el d= de DKIM. Si no, arreglas SPF y aún fallas DMARC.

3) Reemplaza mx y a por IPs explícitas cuando sean estables

mx y a son populares porque son cómodos y se actualizan solos cuando cambian IPs. También cuestan búsquedas y pueden autorizar hosts que no querías autorizar.

Regla práctica: Si el conjunto de IPs cambia rara vez y puedes gestionarlo, usa ip4/ip6. Si cambia con frecuencia y no puedes automatizar, no aplanes; aísla con subdominios.

4) Colapsa includes redundantes

Es habitual incluir tanto un dominio “padre” como uno “hijo” del mismo proveedor porque distintas guías dicen cosas distintas. A veces uno ya incluye al otro. A veces dos proveedores incluyen la misma infraestructura. Pagas presupuesto dos veces.

Método: Expande includes y busca solapamiento. Si include:spf1.vendor se expande a include:spf2.vendor, puede que solo necesites uno, según qué producto uses.

5) Usa redirect= cuando realmente quieras una política canónica

redirect= no es un truco para ahorrar búsquedas; también cuesta. Lo que te da es control de política: un registro se convierte en el autoritativo y otros mecanismos se ignoran tras el redirect.

Buen caso de uso: gestionas muchos dominios de marca que deben compartir el mismo SPF que tu dominio principal. Publicas registros mínimos en dominios vanity con v=spf1 redirect=example.com y gestionas la política en un único lugar.

6) Aplana—solo con automatización y protecciones

Aplanar puede ser correcto cuando:

• tienes uno o dos proveedores terceros,
• publican rangos IP estables,
• puedes refrescar y republicar automáticamente,
• pruebas antes del despliegue.

Aplanar es arriesgado cuando lo haces una vez, a mano, durante un incidente y luego lo olvidas nueve meses. Eso no es ingeniería. Es folclore.

7) No “soluciones” aflojando -all a ~all

Cambiar el calificador final no reduce el número de búsquedas. Cambia la aplicación de la política. A veces tiene sentido durante una migración, pero no es una solución para permerror. Si estás obteniendo permerror, el receptor puede ni siquiera llegar al mecanismo all.

Una cita operativa para mantener la honestidad

Idea parafraseada, atribución: W. Edwards Deming afirmó que no puedes gestionar lo que no mides. La limpieza de SPF es trabajo que empieza por medición.

Tres microhistorias corporativas desde el frente

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana llevaba felizmente Microsoft 365 para correo corporativo y una plataforma de marketing para campañas. Alguien añadió un nuevo sistema de ticketing que “envía correo como tu dominio”, y la guía de onboarding del proveedor decía añadir otro include SPF en el dominio raíz.

La suposición: “Los includes SPF son baratos y los receptores hacen cache DNS de todos modos.” Así no funciona SPF. El límite de búsquedas es un tope duro durante la evaluación; el cacheo puede ayudar en latencia, pero no te da más de diez búsquedas.

El lunes por la mañana, los correos de restablecimiento de contraseña empezaron a aterrizar en spam en un proveedor grande. Nadie vio rebotes. No hubo muchos. El proveedor aceptó el correo, pero penalizó fallos de autenticación en el scoring. El equipo de seguridad vio que los datos agregados de DMARC empeoraban, pero iba con retraso y no saltó una alerta.

Al mediodía, la cola de soporte parecía un ataque de denegación de servicio hecho por humanos confundidos. Los ingenieros revisaron la aplicación, luego el MTA, luego configuraciones TLS. Eventualmente alguien pegó cabeceras completas en el chat, y ahí estaba: spf=permerror (too many DNS lookups).

La solución fue aburrida: eliminar el include del sistema de ticketing, porque en realidad no usaba el dominio de la empresa como envelope-from. Habilitaron DKIM para el dominio de rebote del ticketing y ajustaron la estrategia de alineación DMARC. La entregabilidad se recuperó. La lección quedó: nunca apruebes un include SPF sin evidencia de uso de envelope-from.

Microhistoria 2: La optimización que salió mal

Una organización global decidió “limpiar DNS” y reducir dependencia de terceros. Alguien propuso aplanar todos los includes SPF a rangos IP explícitos en el dominio raíz. Parecía elegante: cero includes, búsquedas mínimas, problema resuelto para siempre.

Aplanaron agresivamente. El registro se infló con docenas de rangos IP, al límite práctico del tamaño de respuesta DNS. Aún así se publicó, mayormente. Algunos resolutores empezaron a truncar respuestas. Algunos receptores reintentan por TCP y tienen éxito. Otros hacen timeout. El fallo fue intermitente e irritante.

Peor aún, un proveedor cambió sus rangos IP salientes. El include SPF del proveedor lo habría actualizado automáticamente. El registro aplanado no. Durante un fin de semana, parte del flujo de marketing empezó a fallar SPF y DMARC empezó a fallar para esos mensajes. Una “mejora de fiabilidad” se convirtió en una trampa de mantenimiento.

El plan de recuperación fue des-aplanar para proveedores de alta rotación, moverlos a subdominios y mantener IPs explícitas solo para los MTAs propios. El diseño resultante tenía un poco más de búsquedas que el sueño del aplanado, pero se mantenía por debajo de 10 y no requería heroísmos cada trimestre.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una empresa con una postura de correo sorprendentemente madura trataba SPF como configuración-como-código. Todo cambio DNS pasaba por revisión y tenían una comprobación previa simple: calcular la profundidad de expansión SPF y el uso estimado de búsquedas para cualquier registro modificado.

Cuando la empresa adquirió otra marca, marketing pidió “añadir el include de su plataforma a nuestro SPF raíz para que envíen desde el dominio principal.” El ingeniero en revisión pidió una muestra de mensaje y el comportamiento de envelope-from del proveedor. Resultó que la plataforma usaba bounces.brand-vendor.tld para SMTP MAIL FROM por defecto.

Rechazaron el include en el dominio raíz. En su lugar montaron m.example.com con su propio SPF, DKIM y política DMARC. El dominio principal se mantuvo pequeño: Microsoft 365 más los relays corporativos. Las búsquedas se mantuvieron dentro del presupuesto. La fusión no creó un incidente de entregabilidad.

Sin fuegos artificiales. Sin llamadas fuera de horario. Ese es el objetivo.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “spf=permerror (too many DNS lookups)” en las cabeceras

Causa raíz: La evaluación SPF excedió el límite de 10 búsquedas DNS debido a cadenas de includes y/o mecanismos mx/a.

Solución: Elimina includes no usados; reemplaza mx/a por IPs explícitas donde proceda; mueve emisores a subdominios; evita aplanar a menos que esté automatizado.

2) Síntoma: SPF a veces pasa, a veces temperrors

Causa raíz: Timeouts DNS o NXDOMAIN intermitentes para dominios incluidos; TTL bajos; DNS de proveedor frágil; problemas de resolutor.

Solución: Aumenta TTLs para tus registros SPF; elimina o reemplaza includes poco fiables; asegura que tu DNS autoritativo esté sano; considera redundancia para los servidores autoritativos.

3) Síntoma: “permerror: multiple SPF records”

Causa raíz: Más de un registro TXT en el mismo nombre empieza por v=spf1.

Solución: Fusiona mecanismos en un único registro SPF. Deja otros TXT no relacionados como están.

4) Síntoma: Eliminaste includes y de pronto el correo crítico falla SPF

Causa raíz: Eliminaste un include que en realidad autorizaba a un emisor que usaba tu dominio en envelope-from, o identificaste mal el dominio que se evalúa (raíz vs subdominio).

Solución: Identifica el flujo fallando desde las cabeceras; reautoriza al proveedor correcto; considera mover ese emisor a un subdominio dedicado para evitar acoplamiento futuro.

5) Síntoma: El registro SPF “parece corto”, pero aún alcanza el límite de búsquedas

Causa raíz: Includes anidados: el registro es corto porque delegaste la complejidad a otro lado.

Solución: Expande includes y cuenta búsquedas en todo el árbol de dependencias. Reduce en la fuente eliminando includes o aislando emisores.

6) Síntoma: El receptor dice permerror, pero tus comprobaciones internas dicen pass

Causa raíz: Diferente entorno de evaluación: cacheo, comportamiento del resolutor, o tu herramienta no aplica los mismos límites; también posible que compruebes la identidad equivocada (MAIL FROM vs HELO).

Solución: Valida con cabeceras reales de receptores; confirma qué dominio se está evaluando; usa varias herramientas y confirma la expansión de búsquedas.

7) Síntoma: Tras aplanar, obtienes fallos esporádicos entre receptores

Causa raíz: Respuestas TXT SPF sobredimensionadas causando truncamiento o fragmentación DNS; o rangos IP aplanados que quedaron obsoletos.

Solución: Deja de aplanar todo. Usa subdominios para proveedores dinámicos. Mantén el SPF raíz compacto y estable.

Listas de verificación / plan paso a paso

Plan de cambio: reducir SPF sin romper el correo

1. Recoge evidencia: Para cada sistema saliente, captura cabeceras de muestra de al menos dos receptores (uno consumidor, uno corporativo). Identifica el dominio envelope-from y la IP emisora.
2. Inventario de dependencias SPF: Expande include y redirect objetivos; lista todos los dominios implicados.
3. Cuenta consumidores de búsquedas: Identifica mecanismos que provocan consultas DNS (include, a, mx, exists, redirect). Estima el peor caso.
4. Elimina peso muerto: Borra includes de proveedores que no usan tu dominio en MAIL FROM.
5. Aísla la rotación: Crea subdominios para marketing/notificaciones y mueve identidades emisoras allí. Publica SPF separado por subdominio.
6. Prefiere IPs explícitas para MTAs propios: Reemplaza a/mx por ip4/ip6 para IPs de salida estables.
7. Prepara el registro: Publica el SPF candidato en spf-test.example.com y ejecuta comprobaciones para todas las IPs emisoras esperadas.
8. Despliega con reloj: Haz el cambio DNS en una ventana controlada; ten en cuenta TTL (si TTL es 300s, espera unos minutos para convergencia, pero planifica más).
9. Monitorea señales de receptores: Observa métricas de entregabilidad, rebotes y tendencias agregadas DMARC. Confirma resultados SPF en cabeceras muestreadas.
10. Documenta propiedad: Haz que los cambios SPF pasen por un equipo o proceso único. “Cualquiera puede añadir un include” es cómo vuelves a este punto.

Lista operativa: antes de aprobar un nuevo include SPF

• ¿Tenemos una muestra de cabecera que demuestre que el proveedor usa nuestro dominio en envelope-from?
• ¿Cuántas búsquedas añadirá este include al expandirse (incluyendo includes anidados)?
• ¿Podemos usar un subdominio en lugar del dominio raíz?
• ¿Podemos autorizar por IP (si es estable) en lugar de delegar vía include?
• ¿Está configurado DKIM para el From visible para mantener DMARC aun si SPF falla?
• ¿Cuál es el plan de rollback (valor TXT previo guardado, TTL conocido)?

Preguntas frecuentes

1) ¿Qué cuenta exactamente para el límite de 10 búsquedas DNS?

Mecanismos que requieren consultas DNS durante la evaluación: include, redirect, a, mx, ptr y exists. El límite es sobre el número de mecanismos interactivos con DNS evaluados, incluyendo los incorporados vía includes.

2) Si aumento los TTL, ¿arreglará “demasiadas búsquedas DNS”?

No. El TTL puede reducir timeouts DNS y mejorar estabilidad, pero no cambia el tope duro de 10 búsquedas de la especificación. Puede ayudar con temperror, no con permerror por recuento de búsquedas.

3) ¿Es redirect= mejor que include: para límites de búsquedas?

No inherentemente. Ambos pueden costar búsquedas. redirect es útil para centralizar la política, especialmente para muchos dominios que comparten un SPF. No es un agujero para el presupuesto de búsquedas.

4) ¿Por qué no cambiar -all a ~all?

Porque los fallos por límite de búsquedas a menudo impiden que el evaluador llegue al mecanismo all. Incluso cuando llega, cambiar la severidad no reduce búsquedas. Solo baja tu resistencia a la suplantación.

5) ¿Puedo publicar SPF en varios registros TXT y que los receptores los combinen?

No. Múltiples registros SPF en el mismo nombre suelen resultar en permerror. Puedes tener múltiples TXT para otros fines, pero solo uno debe ser tu política SPF.

6) ¿Debería aplanar SPF?

A veces. Aplanar es apropiado cuando puedes automatizar la actualización y publicación, y cuando el registro resultante cabe en límites prácticos de tamaño DNS. Si no puedes automatizar, prefiere subdominios y menos includes.

7) ¿Cómo ayudan los subdominios con el límite de búsquedas?

El límite de búsquedas aplica por evaluación SPF. Si marketing envía usando bounce@m.example.com, el receptor evalúa SPF para m.example.com, no para example.com. Eso te da presupuestos de 10 búsquedas separados y aísla cambios.

8) ¿Qué pasa si debemos usar muchos proveedores y no podemos bajar de 10?

Entonces necesitas arquitectura, no soluciones heroicas: consolida proveedores, mueve flujos a subdominios y asegura DKIM fuerte para que DMARC pueda pasar aun cuando SPF esté limitado. Revisa también si algunos sistemas pueden dejar de usar tu dominio como envelope-from.

9) ¿Hace IPv6 esto más fácil o más difícil?

Ninguno directamente. Los mecanismos ip6 no cuestan búsquedas DNS. Pero los proveedores dual-stack pueden incrementar el tamaño del registro si aplanas todo. Mantenlo ordenado y autoriza solo lo que uses.

10) ¿Cuál es la diferencia entre SPF fail y SPF permerror?

Fail significa que el registro se evaluó y la IP no estaba autorizada. Permerror significa que el propio registro está roto (demasiadas búsquedas, múltiples registros, sintaxis inválida). Permerror suele ser tratado como una señal negativa seria.

Conclusión: próximos pasos que funcionan

Arreglar “SPF: demasiadas búsquedas DNS” tiene menos que ver con ingenio y más con negarse a convertir tu dominio raíz en el vertedero de cada checklist de onboarding SaaS. Mantén el SPF raíz pequeño, estable y con dueños claros. Empuja la rotación a subdominios. Usa IPs explícitas cuando las controles. Delega solo cuando sea necesario — y cuenta el coste.

Próximos pasos:

1. Extrae tu SPF actual y expande cada include en una lista de dependencias.
2. Para cada include, demuestra que es necesario con cabeceras reales que muestren tu dominio en MAIL FROM.
3. Mueve marketing y emisores de alta rotación a subdominios dedicados con su propio SPF/DKIM/DMARC.
4. Reemplaza mecanismos mx/a por ip4/ip6 para MTAs salientes estables.
5. Prueba en un subdominio, valida y luego despliega con plan de rollback y monitorización.