Mi registro SPF tiene demasiadas consultas DNS: ¿cómo lo arreglo?
Tu TXT SPF parece una línea. Los receptores lo expanden en árbol. En la undécima consulta DNS llega permerror y SPF falla para todo el correo en ese nombre.
¿Por qué mi registro SPF tiene demasiadas consultas DNS?
En SMTP el receptor sigue mecanismos que exigen DNS: includes de Google, Microsoft, ESP, CRM, billing, cada uno con includes internos. Añadiste seis tokens; el árbol llegó a once lookups.
Síntomas: validador con too many DNS lookups, cabecera spf=permerror, todo falla tras un include: nuevo.
¿Cuál es el límite de diez lookups del SPF?
RFC 7208: máximo diez lookups por evaluación. Pasado eso, permerror. Sin crédito parcial.
ip4: e ip6: directos no suman lookup. include:, redirect, a, mx, ptr suman.
¿Cómo cuento lookups en mi registro SPF?
No cuentes comas. Expande el árbol en el SPF flattener o email health check. Repite por subdominio que envía correo.
¿Qué causa permerror además de registro duplicado?
Dos TXT v=spf1 en el mismo nombre también da permerror (dos registros). Límite de lookup es otro caso: un TXT solo, validador aún falla en el conteo.
¿Debo quitar includes o aplanar primero?
Poda primero. Flatten después. Subdominio tercero.
| Paso | Acción |
|---|---|
| 1 | Quitar includes de vendors inactivos |
| 2 | Marketing en mail.example.com (split) |
| 3 | Aplanar includes estables que aún revientan |
| 4 | Evitar flatten de Google/Microsoft salvo necesidad |
¿Qué es el flattening de SPF?
Resuelve include: a rangos IP y reescribe con ip4:/ip6:. El TXT crece; los lookups bajan. Detalle en la guía de flattening.
¿Es seguro el flattening?
Condicional. Bien para SaaS pequeño con refresh programado. Arriesgado para Google, M365 o ESP que rota infra. Aplanar una vez y olvidar se convierte en spf=fail silencioso.
¿Cómo corrijo permerror paso a paso?
Confirma lookup en el flattener; inventaria senders en informes DMARC; borra includes muertos; separa flujos; aplana hasta nueve o menos; prueba cada plataforma; documenta quién puede añadir el próximo include:.
Con SPF estable, alinea DKIM y DMARC. Ver requisitos Gmail y Yahoo e incluye el flattener en la rutina semanal si tu stack cambia a menudo.
Preguntas frecuentes
¿Por qué mi SPF tiene demasiadas consultas DNS?
Cada include:, redirect, a, mx y ptr puede consumir lookups, y los includes anidados dentro de vendors cuentan en tu límite de diez. Apilar ESP, CRM y help desk en un dominio lo revienta a menudo.
¿Cuál es el límite de diez lookups del SPF?
RFC 7208 limita a diez consultas DNS en la evaluación. La undécima falla con permerror; SPF falla para todo el correo en ese nombre.
¿Cómo cuento lookups en SPF?
Recorre el registro y expande includes. Usa el [SPF flattener](/tools/spf-flattener/) o validador que muestre el conteo, no adivines por la línea TXT.
¿Qué es el flattening de SPF?
Sustituir cadenas include: por ip4:/ip6: copiados del SPF publicado del vendor, eliminando lookups anidados. Cambias margen por mantenimiento cuando cambian IPs.
¿Es seguro el flattening?
Sí si actualizas cuando el proveedor cambia rangos. Aplanar Google o Microsoft es mantenimiento pesado; podar includes o subdominio separado suele ser más seguro.
¿Cómo corrijo permerror por lookups?
Quita includes de servicios muertos, separa marketing en subdominio con SPF propio, aplana el resto hasta quedar bajo diez, vuelve a probar hasta pass sin permerror.