SPF supera diez consultas DNS: cómo localizar el problema sin romper los envíos
Localice referencias SPF que agotan el límite de consultas DNS y revise las salidas legítimas antes de acortar o reemplazar el registro.
Añadió una plataforma de facturación al registro SPF y apareció un permerror. El registro sigue existiendo, pero ya no se evalúa como esperaba. Antes de eliminar un include, averigüe qué rutas legítimas autoriza y cómo se llega al límite.
El límite no equivale a diez direcciones IP ni a diez palabras en el TXT. Determinados mecanismos y modificadores provocan consultas durante la evaluación; las referencias anidadas también importan.
Un ejemplo de consultas anidadas
Este ejemplo es ficticio; los nombres se usan solo para explicar el límite. Suponga que su política incluye a A; A incluye a B, y así sucesivamente hasta J. Si el origen no coincide con ninguna IP anterior, la evaluación recorre los diez mecanismos include: A, B, C, D, E, F, G, H, I y J. Si J necesita un include adicional hacia K, ese sería el undécimo término y la evaluación excedería el límite.
Una política con muchas direcciones ip4 no consume esos términos de la misma manera. Por eso contar direcciones, registros TXT o palabras de la primera línea no basta. El resultado depende también de la ruta que siga la evaluación.
Empiece por el dominio que realmente se evalúa
Conserve un mensaje afectado y el resultado de autenticación emitido por el receptor confiable. Identifique la identidad SPF utilizada, normalmente el dominio de MAIL FROM, que puede diferir del remitente visible. No diagnostique automáticamente el dominio que aparece en la firma.
Desde un equipo con dig, esta consulta es de lectura; sustituya example.com por el dominio autorizado que está revisando:
dig TXT example.com +shortBusque los registros que comienzan con v=spf1. Varios fragmentos entre comillas dentro de un mismo TXT no son necesariamente varios registros SPF. En cambio, publicar dos registros SPF separados para el mismo nombre es un problema distinto del límite de consultas.
Siga las referencias, no cuente solo la primera línea
El RFC 7208 limita a diez los términos que requieren consultas DNS durante la evaluación. Incluye mecanismos como include, a, mx, exists y ptr, además de redirect; ip4 e ip6 no consumen ese mismo presupuesto. Hay otros límites, por lo que resolver el contador no descarta todo error SPF.
Construya un árbol de los servicios referenciados y examine la ruta evaluada. Un include puede abrir otras referencias. La documentación de resolución de problemas SPF de Google también señala ese efecto de las consultas anidadas.
Una calculadora puede ayudar a visualizar el árbol, pero registre qué comprobó y en qué fecha: un proveedor puede cambiar sus referencias. No publique la IP de un cliente ni cabeceras completas para pedir ayuda en un foro.
Corrija el inventario antes de acortar el TXT
Liste qué envía por cada plataforma: personas, CRM, facturación, formularios y campañas. Confirme con sus responsables cuáles siguen en uso. Retirar un servicio abandonado tiene sentido; borrar el que menos reconoce puede interrumpir una salida legítima.
Evite convertir todas las referencias en IP estáticas copiadas una sola vez. Si el proveedor cambia sus servidores, ese resultado puede quedar desactualizado. Una estrategia de aplanamiento exige mantenimiento y una decisión explícita; no es una reparación automática.
Separar determinadas aplicaciones en subdominios puede ordenar la autenticación, pero requiere que la plataforma soporte esas identidades y que se compruebe DMARC. No consiste solo en crear un TXT nuevo y esperar que cambie el remitente de las aplicaciones.
Valide el cambio con las salidas reales
Guarde el registro anterior y prepare una corrección acotada. Tras aplicarla con autorización, compruebe resolución DNS, evaluación SPF y mensajes de prueba de cada origen legítimo afectado. Verifique también alineación y resultado DMARC, no únicamente que desapareció permerror.
El criterio de cierre es que las rutas necesarias sigan autenticándose como corresponde y que el error investigado deje de producirse. Eso no equivale a prometer bandeja de entrada: autenticación y clasificación son decisiones diferentes.
