SPF PermError: qué significa y cómo corregirlo

Causa n.º 1: demasiadas resoluciones DNS

Es con diferencia la causa más frecuente. La RFC 7208 limita la evaluación a diez resoluciones DNS. Cada include, a, mx, ptr, exists y redirect consume una, y los include de proveedores se despliegan en cascada. Supera diez, y es PermError. Es tan común que le dedicamos una guía entera: el límite de búsquedas DNS de SPF. La corrección pasa por la limpieza de los include inútiles, la separación por subdominio, o un aplanamiento controlado.

Causa n.º 2: demasiados «void lookups»

Más discreta, pero bien real. Un void lookup es una resolución DNS que no devuelve nada (dominio inexistente o registro vacío). La RFC limita el número de esas resoluciones vacías a dos. Más allá, también es un PermError. La causa típica: un include que apunta a un dominio de proveedor eliminado, o una errata en un nombre de dominio. El síntoma es solapado porque el registro «parece» correcto; hay que desplegar cada mecanismo para localizar los que no resuelven hacia nada.

Causa n.º 3: una sintaxis inválida

Una simple errata puede romper todo el registro: un ip4: mal formado, un include sin dos puntos, un carácter parásito, dos mecanismos pegados sin espacio. SPF es estricto: si el analizador del destinatario no puede interpretar un mecanismo, devuelve PermError en lugar de adivinar. Una relectura atenta se impone o —más seguro— una validación de la sintaxis por una herramienta.

Causa n.º 4: un doble registro SPF

Un dominio solo debe tener un único registro v=spf1. Si existen dos (uno puesto por IT, otro por marketing, por ejemplo), la situación es ambigua y muchos destinatarios devuelven PermError, o ignoran los dos. La corrección: fusionar los dos en un único registro, combinando sus mecanismos y verificando que no se superan diez resoluciones al hacerlo.

Causa n.º 5: mecanismos obsoletos o prohibidos

Algunos mecanismos plantean problema. El ptr, por ejemplo, está desaconsejado por la RFC: lento, poco fiable, puede contribuir a un PermError y debería retirarse. Del mismo modo, macros SPF exóticas o modificadores mal colocados pueden hacer el registro inevaluable. Por regla general, un SPF sano se limita a include, ip4, ip6, a, mx (con parsimonia) y la cualificación terminal.

Cómo diagnosticar un PermError

La buena noticia es que un PermError es determinista: tiene una causa precisa, y basta con encontrarla. El método:

1. Recuperar el registro (dig +short TXT ejemplo.es) y confirmar que solo hay uno.
2. Desplegar el árbol de los include para contar las resoluciones reales y localizar los void lookups.
3. Validar la sintaxis mecanismo por mecanismo.
4. Identificar la causa entre las cinco de arriba.

Todo se hace a mano, pero un analizador va mucho más rápido. Nuestro analizador gratuito despliega el SPF, cuenta las resoluciones, localiza los void lookups y las erratas de sintaxis, y dice con precisión por qué el dominio está en PermError. El procedimiento completo de verificación está en cómo verificar un registro SPF.

PermError vs SoftFail vs Fail: no confundir en los informes

En la lectura de los informes agregados, conviene distinguir bien lo que aparece. Un fail SPF (que puede venir de un PermError o de una IP no autorizada) no tiene la misma causa que un softfail. Y sobre todo, hay que recordar que el campo SPF de los informes refleja la alineación, no solo el resultado en bruto. Una fuente en PermError aparecerá en fallo; una vez reparado el registro, debería volver al verde. Es la prueba definitiva de que la corrección ha surtido efecto.

Un PermError diseccionado: caso real

Tomemos un dominio que acaba de caer en PermError sin avisar. El equipo jura no haber «cambiado nada». Desenrollemos. El registro:

v=spf1 include:_spf.google.com include:_spf.antiguo-router.com
  include:mail.socio.com include:_spf.salesforce.com include:servers.mcsv.net -all

Primer paso por el analizador: dos problemas coexisten. Primero, include:_spf.antiguo-router.com no resuelve hacia nada: el proveedor cerró su servicio hace seis meses. Es un void lookup, y hay un segundo, más adelante, sobre un subdominio muerto. Dos void lookups es el límite; el más mínimo otro hace bascular. Después, al desplegar los include restantes, se cuentan once resoluciones: el límite de las diez también se supera. Dos causas de PermError apiladas, lo que explica por qué el diagnóstico «a ojo» había fallado.

La corrección es en dos tiempos. Primero se retiran los dos include muertos (antiguo-router y el subdominio difunto): el correo ya no sale de esas fuentes de todos modos. Esta simple limpieza suprime los void lookups y hace caer el recuento a ocho o nueve resoluciones. Luego, como el margen sigue siendo escaso, se traslada Mailchimp (servers.mcsv.net) a un subdominio news. con su propio SPF. El dominio raíz vuelve a bajar ampliamente de la barra, sin void lookup. PermError resuelto, y la verdadera lección es que «no hemos cambiado nada» es casi siempre falso: un proveedor ha cerrado, y es el registro el que ha envejecido bajo el equipo.

Preguntas frecuentes

¿Significa PermError que mi correo es rechazado? No directamente por SPF, sino a través de DMARC: si SPF está en PermError y DKIM no se alinea, el mensaje falla en DMARC y sufre la política publicada. En la práctica, un PermError no corregido acaba costando emails.

¿Cuál es la diferencia entre PermError y TempError? El TempError es temporal (problema de DNS pasajero) y se resuelve a menudo solo o al reintentar. El PermError es permanente: viene del propio registro y no desaparecerá hasta que se corrija.

¿Por qué mi SPF está de repente en PermError cuando funcionaba? Casi siempre porque un proveedor añadido ha hecho cruzar el límite de las diez resoluciones, o porque un include apunta ahora a un dominio eliminado (void lookup). Es un umbral cruzado, no una degradación continua.

¿Cuántos void lookups se permiten? Dos. Más allá de dos resoluciones DNS que no devuelven nada, es PermError. Los include muertos y las erratas en los nombres de dominio son lo primero que hay que rastrear.

¿Puede un analizador corregir automáticamente mi PermError? Lo diagnostica con precisión, pero la corrección depende de la causa (limpieza, fusión, sintaxis). Un copiloto como Thomas va más lejos: propone el registro corregido adaptado al caso tratado.

Prevenir los futuros PermError

Un PermError nunca llega sin razón, y las mismas causas reaparecen. Tres hábitos las evitan de forma duradera:

• Retirar el include de un proveedor el día en que se abandona su servicio. Es precisamente lo que crea un void lookup cuando el servicio cierra más tarde, meses después de que todo el mundo lo haya olvidado.
• Vigilar el recuento de resoluciones en cada añadido de fuente: guardar un margen antes del límite de las diez, sin rozarlo nunca. Un registro a nueve resoluciones es una bomba de relojería.
• Centralizar la gestión del SPF. El doble registro viene casi siempre de dos equipos que modifican el DNS cada uno por su lado. Una sola mano sobre el registro suprime la ambigüedad de raíz.

Un control trimestral basta para detectar un include que se ha muerto o un recuento que sube, mucho antes de que el PermError golpee en producción y expida las facturas al spam.

Thomas diagnostica y corrige

Un PermError siempre tiene una causa precisa; falta encontrarla rápido, antes de que el correo lo sufra. Thomas, el CISO virtual, despliega el registro, identifica la causa exacta (desbordamiento, void lookup, sintaxis, doble registro), y genera el registro SPF corregido, limpio y bajo la barra de las diez.

Analizar un dominio gratis o crear una cuenta para salir del PermError y quedarse fuera.