Demasiadas consultas DNS en SPF: cómo resolver el límite de 10 y el permerror

Qué significa «demasiadas consultas DNS»

Cuando un servidor receptor comprueba SPF, lee el registro TXT que empieza por v=spf1 en el dominio del remitente del sobre (la dirección MAIL FROM, que después aparece como Return-Path) y evalúa sus términos de izquierda a derecha. Algunos términos obligan al receptor a hacer otra consulta DNS. El apartado 4.6.4 del RFC 7208 limita esos términos a 10 por comprobación, incluidos los que hay dentro de cada registro incluido. Si la evaluación necesita un undécimo, el receptor debe detenerse y devolver permerror, el resultado que indica que los registros publicados no se pudieron interpretar correctamente.

Normalmente lo descubres en uno de estos tres sitios: la cabecera Authentication-Results de un mensaje entregado (RFC 8601), por ejemplo spf=permerror smtp.mailfrom=example.com; un mensaje de rebote que habla de demasiadas consultas; o los errores de SPF en los informes agregados de DMARC.

Dos detalles lo vuelven confuso. Los receptores cuentan las consultas mientras evalúan, y la evaluación se detiene en el primer término que coincide. El correo de un servicio que aparece pronto en el registro puede seguir pasando, mientras que el de un servicio cuyo include queda después de la décima consulta recibe permerror, así que el fallo puede parecer intermitente. Además, permerror no equivale a fail: simplemente SPF deja de ayudar. DMARC pasa cuando SPF o DKIM pasan para un dominio alineado con la dirección From (RFC 9989), de modo que un mensaje con una firma DKIM alineada sigue pasando y uno que dependía solo de SPF, no. Más allá de eso, cómo trate cada receptor un permerror es decisión suya.

Qué términos de SPF cuentan para el límite y cuáles no

El presupuesto es de toda la evaluación, no de un registro concreto. Un include cuesta una consulta por sí mismo y, además, lo que cueste el registro al que apunta, hasta el último nivel de anidamiento. Los proveedores cambian sus propios registros, por ejemplo al repartir sus rangos de direcciones en más include anidados, así que tu total puede variar sin que toques nada.

El límite existe porque un registro SPF hace que los receptores lancen consultas DNS por cuenta de quien lo publica; el apartado 11.1 del RFC 7208 describe cómo un atacante podría aprovecharlo para inundar el DNS de un tercero. El RFC también sugiere un tiempo máximo para toda la comprobación, de al menos 20 segundos. Agotarlo da temperror, un error temporal, y no permerror.

El segundo límite: no más de dos consultas vacías

El RFC 7208 añade un límite aparte para las consultas que vuelven vacías: una respuesta sin registros (NOERROR con cero respuestas) o un error de nombre (NXDOMAIN, el nombre no existe). Se llaman consultas vacías (void lookups). Las implementaciones DEBERÍAN admitir como máximo dos, y superar esa cifra también produce permerror, aunque el total siga por debajo de 10. Así se evita que un registro SPF mande a los receptores a buscar largas listas de nombres inexistentes.

Las consultas vacías suelen venir de restos de configuraciones antiguas:

• a:old-web.example.com después de borrar el nombre DNS del servidor antiguo.
• mx o mx:example.org en un nombre sin registros MX. El mecanismo no debe recurrir al registro A del nombre, así que simplemente no encuentra nada.
• a en el dominio raíz cuando la web se ha trasladado a un alojamiento que solo responde en www.

Con include: la regla es más estricta. Si el nombre incluido no existe o no publica registro SPF, el include no cuenta solo como consulta vacía: convierte todo el resultado en permerror de inmediato (apartado 5.2). Es lo que pasa cuando un proveedor que ya no usas retira el dominio que tu registro sigue incluyendo. Consulta cada nombre al que apunta tu registro; si alguno no devuelve nada, corrígelo o elimínalo.

Cómo contar a mano las consultas de tu SPF

Empieza por el dominio del remitente del sobre, que puedes leer en la cabecera Return-Path de un mensaje que hayas enviado, y recorre el registro de forma recursiva:

1. Lee el registro: dig +short TXT example.com, o nslookup -type=TXT example.com en Windows.
2. Suma 1 por cada include, a, mx, ptr, exists y redirect, y 0 por ip4, ip6 y all.
3. Para cada include y redirect, lee el registro al que apunta y puntúalo igual, hasta el nivel más profundo.
4. Súmalo todo y apunta cualquier nombre que no haya devuelto registros.

Este es un registro hipotético con solo cinco términos de consulta a la vista:

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

El total es el peor caso. Un remitente que coincide con el primer include necesita como mucho cinco consultas y pasa. Uno que no coincide con nada antes llega al a final, que es la undécima consulta, así que el correo falsificado recibe permerror en lugar del fail que debía producir -all. Repite el recuento cada vez que añadas un servicio de envío y, de todos modos, de vez en cuando, porque los registros incluidos cambian sin previo aviso.

Cómo bajar de diez sin perder correo

• Quita los include que ya no usas. Un proveedor de correo anterior, una herramienta de newsletters que diste de baja, un CRM que evaluaste unas semanas. Los informes agregados de DMARC muestran qué fuentes envían realmente en nombre de tu dominio, y eso ayuda a localizar include que nadie necesita. Habla con el responsable de cada servicio antes de quitarlo.
• Comprueba si un include llega a evaluarse. SPF se verifica sobre el dominio del remitente del sobre. Si los mensajes de un servicio muestran su propio dominio en Return-Path, los receptores consultan el registro SPF de ese dominio, no el tuyo, y tu include no aporta nada a ese correo. Confírmalo en la documentación del proveedor antes de eliminarlo.
• Sustituye a y mx por ip4 e ip6 en los servidores que controlas. Si tu propio servidor envía desde 192.0.2.10, ip4:192.0.2.10 no cuesta nada, mientras que a cuesta una consulta. Plantéate si mx debe estar ahí: los servidores que reciben tu correo no tienen por qué enviarlo, y si son de tu proveedor de correo, puede que su include ya recoja sus servidores de envío. Actualiza la dirección cuando el servidor cambie.
• Da a cada remitente de gran volumen su propio subdominio. Haz que un servicio de newsletters o de tickets use como remitente del sobre un dominio de rebote como news.example.com, con su propio registro SPF y su propio límite de 10. SPF no se hereda, así que el subdominio necesita ese registro. Con la alineación relajada que DMARC aplica por defecto, news.example.com sigue alineado con una dirección From en example.com. Muchos servicios lo llaman dominio de rebote o return-path personalizado.
• Elimina ptr. El RFC 7208 dice que NO DEBERÍA publicarse: es lento, depende del DNS inverso que controla el propietario de la IP que se conecta y gasta consultas. Sustitúyelo por ip4/ip6 o por el include del proveedor.
• Reordenar no es una solución. Si pones el remitente con más volumen al principio, menos mensajes llegan a la undécima consulta, pero el registro sigue roto para todo lo que viene detrás, incluido el correo falsificado que debería toparse con -all.

DKIM también alivia la presión. DMARC solo necesita un resultado alineado que pase, y DKIM suele sobrevivir al reenvío, mientras que SPF no. Asegúrate de que todos los servicios firman con tu dominio y después recorta el registro SPF.

Aplanar el SPF (flattening): menos consultas, más mantenimiento

El aplanamiento sustituye un include por los rangos ip4 e ip6 a los que se resuelve hoy. El número de consultas baja, pero tu registro pasa a guardar una copia de la lista de otro, y esa copia no se actualiza sola.

Los servicios de aplanamiento automático resuelven los include con regularidad y reescriben tu registro. Eso evita los rangos desfasados, pero da a un tercero un papel en tu DNS, y una actualización fallida rompe tu SPF. Recurre antes a las otras soluciones. Si aun así aplanas, anota qué include sustituiste y cuándo, compara con regularidad con los rangos que publica el proveedor y verifica SPF después de cada cambio (Microsoft Learn da el mismo consejo a sus clientes).

Un solo registro SPF por nombre, bien dividido

Un nombre debe tener exactamente un registro TXT que empiece por v=spf1. Si hay dos, el receptor no puede elegir y devuelve permerror (apartado 4.5 del RFC 7208). Suele pasar cuando la guía de alta de un servicio nuevo dice «añade este registro TXT» y alguien crea un segundo registro SPF en lugar de editar el primero. Un segundo registro, por tanto, no duplica el presupuesto; une los dos:

# Mal: dos registros SPF en el mismo nombre
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Bien: un solo registro
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Otros registros TXT en el mismo nombre, como los tokens de verificación de servicios, no molestan; solo cuentan los que empiezan por v=spf1. Una cadena dentro de un registro TXT admite como máximo 255 caracteres. Un registro SPF más largo sigue siendo un único registro TXT formado por varias cadenas entre comillas, que los receptores unen sin añadir espacios (apartado 3.3), así que termina cada cadena con un espacio donde acaba un término:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

Otros errores producen el mismo permerror: un error de sintaxis en cualquier parte del registro, como include= en vez de include: (apartado 4.6), o un include de un dominio sin registro SPF. Los registros SPF tampoco se heredan, así que cada nombre que se use como remitente del sobre necesita su propio registro, y cada uno tiene su propio límite de 10.

Qué cuenta el verificador gratuito de SPF y DMARC

El snapshot gratuito ejecuta ocho comprobaciones pasivas sobre un dominio público, sin registro; una de ellas lee los registros DNS del correo. No es un pentest ni la auditoría de seis áreas, y no envía correo.

• Nombre de host exacto. Lee el registro SPF del nombre que escribes, sin recurrir al dominio principal. Escribe el propio dominio del remitente del sobre, por ejemplo example.com en lugar de www.example.com.
• Recuento del primer nivel. Cuenta los términos con consulta DNS de ese registro (include, a, mx, ptr, exists y redirect) y marca más de diez como señal de riesgo media.
• Lo que no sigue. No sigue include: ni redirect=, no cuenta las consultas vacías y no marca un segundo registro SPF en el mismo nombre. El ejemplo de cinco términos de arriba sale bien parado en este recuento aunque los receptores necesiten once consultas, así que haz también tú el recuento recursivo.
• Otras señales de SPF. +all se marca como riesgo alto y ?all como bajo; la falta de registro SPF o DMARC se señala cuando el host tiene registros MX.

Para abrir primero la comprobación del DNS de correo, usa el verificador de SPF y DMARC gratuito: ejecuta el mismo snapshot y muestra esa comprobación encima de las otras siete. Para el resto del registro, desde ~all frente a -all hasta llevar DMARC de none a reject, consulta la guía de SPF y DMARC.