Tu registro SPF parece correcto, todos los remitentes que usas están listados y, sin embargo, un día un informe DMARC o un rebote dice permerror. La causa habitual es el límite de 10 consultas DNS: a SPF solo se le permite lanzar un número fijo de consultas DNS mientras se evalúa, y cada herramienta que añades con un include: gasta parte de ese presupuesto. Esta guía muestra cómo contar tus consultas, qué términos cuestan una y cuáles son gratis, y en qué orden arreglar un registro que se pasa del límite sin romper el correo de un remitente que olvidaste.
La respuesta breve#
SPF se define en el RFC 7208, que dice que una implementación debe limitar a 10 los términos que provocan consultas DNS durante la evaluación. Los términos que cuentan son include, a, mx, ptr, exists y el modificador redirect. Los términos que no necesitan consulta, ip4, ip6 y all, son gratis. El conteo es recursivo: un include: cuesta uno, más todo lo que hay dentro del registro al que apunta. Si pasas de 10, la comprobación devuelve permerror, lo que significa que SPF no pasa para ningún correo del dominio. Para arreglarlo, elimina los include de herramientas que ya no usas, luego sustituye lo que puedas por ip4/ip6 para servidores estables y después mueve los remitentes masivos a un subdominio. Aplana el registro solo como último recurso. El verificador de SPF, DKIM y DMARC gratuito y la comprobación de salud del dominio muestran el registro que has publicado, pero no siguen los include ni cuentan consultas, así que cuentas a mano como se describe abajo o usas una herramienta que recorra la recursión.
Qué cuenta para el límite#
| Término | ¿Cuesta una consulta? | Notas |
|---|---|---|
include:domain | Sí, 1 más su contenido | También se evalúa el registro incluido, así que sus propios include cuentan |
a o a:domain | Sí, 1 | Un término, sin importar cuántas direcciones devuelva |
mx o mx:domain | Sí, 1 | Fácil de olvidar; puede que no lo necesites |
ptr | Sí, 1 | Desaconsejado en el RFC; elimínalo |
exists:domain | Sí, 1 | Poco frecuente, a menudo usado en configuraciones con macros |
redirect=domain | Sí, 1 más su contenido | Se ignora si el registro también tiene un término all |
ip4: y ip6: | No | Gratis, pero tú debes mantenerlos al día |
all | No | Siempre al final; los términos posteriores nunca se evalúan |
Un ejemplo concreto muestra lo rápido que se acumula.
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"
Ese registro tiene seis términos que cuestan consultas en el nivel superior, y cada include: puede contener más términos dentro. El conteo visible es 6, el conteo real es lo que sumen los registros anidados. Por eso un registro que parece corto puede pasarse del límite, y por eso el número cambia sin que toques tu DNS: un proveedor edita su propio registro SPF y tu total se mueve.
El RFC también dice que las implementaciones deberían limitar a dos las "consultas vacías" (void lookups), las que no devuelven nada. Es una recomendación y no un requisito estricto, pero un término include:, a o mx que apunta a un nombre que ya no existe es exactamente ese tipo de consulta. Es otra razón para eliminar primero los include muertos.
Paso 1: confirma que es un problema de conteo#
Antes de cambiar nada, descarta las demás cosas que producen un error de SPF.
- Más de un registro SPF. Dos registros TXT
v=spf1en el mismo nombre también son un error permanente, y es fácil provocarlo por accidente cuando la página de configuración de una herramienta dice que añadas un registro. Ejecutadig +short TXT example.comy cuenta las líneas que empiezan porv=spf1. Si encuentras dos, fusiónalas. Cuando SPF, DKIM y DMARC dejan de funcionar cubre esto y las demás causas habituales. - Un error de sintaxis. Un fallo como
includesin dominio, un rangoip4incorrecto o un espacio que falta rompe el registro. - Un include en bucle. Dos dominios que se incluyen mutuamente nunca terminan de evaluarse.
- Un include que no apunta a nada. El dominio de destino no publica ningún registro SPF.
Si nada de eso aplica, cuenta las consultas. Hazlo a mano una vez para entender el árbol: consulta el registro de nivel superior, lista cada término que cuesta, luego consulta cada destino de include: y redirect= y repite. Una herramienta que sigue los include hace la recursión por ti y vale la pena usarla, porque el registro anidado de un proveedor puede tener varios niveles de profundidad. Los verificadores gratuitos de este sitio leen el registro, pero no cuentan.
Paso 2: elimina lo que ya no usas#
Es la solución más barata y normalmente recupera varias consultas. Revisa cada include: y pregúntate si algo sigue enviando a través de él.
- Herramientas de prueba. Servicios que probaste durante un mes y nunca quitaste.
- Plataformas retiradas. La herramienta de marketing que reemplazaste hace dos años, o el helpdesk antiguo.
- Proveedores que solo reconoces por el include. Si no sabes decir qué es, averígualo antes de borrar. Los informes agregados de DMARC muestran qué fuentes enviaron realmente como tu dominio, así que un include que nunca aparece en un mes de informes es un buen candidato.
Borra uno cada vez, vuelve a contar y conserva el texto del registro antiguo para poder volver atrás. Elimina también los términos mx y a sueltos salvo que de verdad envíes desde esos hosts, y elimina ptr por completo.
Paso 3: sustituye include por rangos de IP, con cuidado#
Para un remitente con un conjunto pequeño y estable de direcciones, como tu propio servidor de correo, puedes cambiar un include: o un mx por entradas ip4: y ahorrar consultas.
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all
La contrapartida es el mantenimiento. Una entrada ip4: es una promesa de que te darás cuenta cuando las direcciones cambien. Hazlo solo con infraestructura que controles. Nunca copies en tu registro la lista de IP de un ESP grande: los proveedores añaden y retiran direcciones sin avisarte, y tu copia queda desactualizada en silencio.
Paso 4: mueve los remitentes masivos y de marketing a un subdominio#
Cada dominio de envío tiene su propio registro SPF y su propio presupuesto. Si tu plataforma de marketing, tu servicio transaccional y tu soporte envían todos como example.com, comparten un único presupuesto de 10. Dale a la newsletter un subdominio como news.example.com, publica ahí un registro SPF corto y configura la plataforma para que lo use en el return-path y en la dirección From. Esto también aísla la reputación, algo que la guía de subdominios de envío explica por completo.
Ten presente DMARC cuando hagas esto. La alineación compara el dominio del From con el dominio que pasó SPF o DKIM. La alineación relajada permite que news.example.com se alinee con example.com, pero el remitente aún tiene que autenticarse bajo uno de esos dominios. Configurar DMARC cubre la alineación.
Paso 5: aplanar el registro, y por qué se queda obsoleto#
Aplanar significa sustituir los términos include: por las direcciones IP literales a las que se resuelven, de modo que el registro no necesite consultas. Funciona, y también es la solución más arriesgada, porque el include existe precisamente para que el proveedor pueda cambiar de direcciones sin que tú edites el DNS. Un registro aplanado congela las direcciones en el momento en que lo construiste. Cuando el proveedor añade un servidor, el correo que sale de él falla SPF hasta que alguien actualice tu registro.
Se aplican dos límites más. Un registro aplanado puede superar el tamaño que un único registro TXT admite con comodidad, y el DNS limita la respuesta UDP, así que los registros grandes hay que dividirlos o servirlos con cuidado. Y ahora eres responsable de una tarea de actualización. Si aplanas, hazlo con un servicio o script que vuelva a resolver con regularidad y te avise cuando falle, nunca como una copia y pega única.
Para la mayoría de los dominios el orden anterior basta. Primero borrar, segundo subdominio, tercero ip4, aplanar al final.
Mantener el conteo bajo control#
El número de consultas no es fijo. Se mueve cuando añades una herramienta y cuando un proveedor edita su propio registro, así que un registro que pasaba en marzo puede fallar en septiembre sin ningún cambio por tu parte. Tres hábitos te mantienen por delante.
- Cuenta antes de añadir. Comprueba el total antes de añadir cualquier include, para saber si el nuevo remitente cabe.
- Vuelve a comprobar con regularidad. Las comprobaciones de salud del dominio recalculan el conteo recursivo cada vez.
- Alerta en 9, no en 11. Cuando el conteo pasa de 10 ya estás fallando.
El monitoreo de salud del dominio se encarga de los dos últimos. Cada dominio cubierto recibe una comprobación diaria de SPF que sigue los include y los redirect y cuenta las consultas como describe la sección 4.6.4 del RFC 7208. Genera una advertencia con 9 o 10 consultas y un problema de gravedad "bad" por encima de 10, y te envía un correo cuando ocurre. También señala los demás problemas de SPF del paso 1: registros múltiples, errores de sintaxis, un include que no publica ningún registro, un final +all o ?all y el mecanismo ptr. Un límite que conviene conocer: cada informe tiene un presupuesto de 40 consultas DNS por dominio, así que en un registro muy grande algunos elementos aparecen como no comprobados y el conteo es una cota inferior. El argumento más amplio para comprobar algo más que SPF está en monitoreo de la salud del dominio de correo, y las guías de SPF por proveedor muestran qué añade cada remitente a tu conteo.
Preguntas frecuentes
01¿Qué es el límite de 10 consultas DNS de SPF?
El RFC 7208 dice que una comprobación SPF debe limitar a 10 los términos que provocan consultas DNS. Cuentan los términos include, a, mx, ptr, exists y redirect, y los include anidados también cuentan. Pasarse devuelve permerror, que los receptores tratan como un fallo de SPF.
02¿Los mecanismos ip4 e ip6 cuentan para el límite?
No. ip4, ip6 y all no necesitan consulta DNS, así que son gratis. El coste es el mantenimiento: tienes que actualizar tú las direcciones cada vez que el remitente las cambie.
03¿Aplanar mi registro SPF es una buena solución?
Funciona, pero congela las direcciones actuales del proveedor, así que el correo falla cuando este añade servidores si no se actualiza el registro. Prueba primero a eliminar los include que no usas y a mover los remitentes masivos a un subdominio, y aplana solo con actualización automática.
04¿Por qué se rompió mi SPF si no cambié nada?
Los include se evalúan de forma recursiva, así que cuando un proveedor edita su propio registro SPF cambia tu total. Un registro con 9 o 10 consultas puede pasarse sin ninguna edición tuya, y por eso conviene alertar antes de llegar a 10.
SPF solo dice qué servidores pueden enviar como tú, y no puede decirte si las personas de tu lista quieren saber de ti, ni siquiera si existen. Los 100 créditos gratuitos de la página de precios ejecutan la verificación completa en una lista, así que puedes ver cuántas direcciones rebotarían. Un registro que pasa SPF sigue necesitando una lista sana para ganarse la bandeja de entrada.
