SPF PermError significa que tu registro SPF genera más de 10 consultas DNS, el límite fijado por RFC 7208. Cada include, a, mx, ptr, exists y redirect cuenta, y cada include suma las consultas que contiene. Corrígelo eliminando includes sin uso, sustituyendo algunos por direcciones ip4:/ip6: o aplanando el registro.
El receptor evalúa SPF en tiempo real, así que la especificación limita el trabajo de DNS a 10 consultas para evitar abusos y entregas lentas. Si se supera, el resultado es PermError, tratado como un fallo que puede enviar tu correo legítimo a spam o rechazarlo bajo DMARC.
Cuentan hacia el límite de 10: include, a, mx, ptr, exists, redirect y, recursivamente, todo lo que hay dentro de cada include. No cuentan: los mecanismos ip4: e ip6: ni el mecanismo all. Esa asimetría es la clave de la solución.
1. Elimina lo que ya no uses. Los ESP y herramientas antiguos en SPF son la causa más común. 2. Consolida. Algunos proveedores publican un include más ligero. 3. Sustituye includes por IP. Si un servicio publica rangos de IP estables, cambia include:servicio.com por sus bloques ip4:: no cuestan consultas. 4. Aplana como último recurso y solo con monitorización, porque un proveedor que cambie sus IP romperá en silencio un registro aplanado.
Confirme que hay exactamente un registro SPF y vea sus mecanismos:
$ dig TXT yourdomain.com +shortEl verificador SPF anterior expande cada inclusión e informa su recuento de búsqueda real y cuál incluye cuesta más.
Comprueba tu registro SPF ahora
Abrir el verificador SPF gratuito →No. Los mecanismos ip4: e ip6: cuestan cero consultas DNS, por eso sustituir un include por sus rangos de IP es una solución eficaz.
Funciona pero es frágil: fija las IP actuales de un proveedor en tu registro, así que tu correo falla cuando cambian de IP. Si aplanas, usa un servicio que actualice el registro automáticamente y supervísalo.
Sí: publicar más de un registro SPF es una causa aparte de PermError. Un dominio debe tener exactamente uno.
