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. Relee con atención o —más seguro— haz validar 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 tu PermError

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

1. Recupera tu registro (dig +short TXT tu-dominio.com) y confirma que solo hay uno.
2. Despliega el árbol de los include para contar las resoluciones reales y localizar los void lookups.
3. Valida la sintaxis mecanismo por mecanismo.
4. Identifica la causa entre las cinco de arriba.

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

PermError vs SoftFail vs Fail: no confundir en los informes

Cuando lees tus informes agregados, distingue bien lo que ves. 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, recuerda 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 tu 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 tu política. 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 de tu registro y no desaparecerá hasta que se corrija.

¿Por qué mi SPF está de repente en PermError cuando funcionaba? Casi siempre porque has cruzado el límite de las diez resoluciones al añadir un proveedor, 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. Rastrea los include muertos y las erratas en los nombres de dominio.

¿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 a tu caso.

Prevenir los futuros PermError

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

• Retira el include de un proveedor el día en que dejas de usarlo. 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.
• Vigila tu recuento de resoluciones en cada añadido de fuente: mantén un margen antes del límite de las diez, no lo roces. Un registro a nueve resoluciones es una bomba de relojería.
• Centraliza 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 tus facturas al spam.

Deja que Thomas diagnostique y corrija

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

Analiza tu dominio gratis → o crea una cuenta para salir del PermError y quedarte fuera.