Un registro SPF que necesita más de diez consultas DNS está roto, pero no de la forma que describen casi todas las guías. La evaluación se detiene en el primer mecanismo que coincide con el servidor que conecta, así que un remitente al que empareja el segundo término nunca llega al duodécimo. Pasarse del límite significa que el registro puede devolver un error permanente, y lo hace para todo remitente al que no haya emparejado antes. El orden decide a quién le toca.
Esa distinción importa porque cambia la solución. Si el límite rompiera todos los mensajes te darías cuenta enseguida. En vez de eso rompe a los remitentes que están al final del registro, que suele ser la plataforma que añadiste la última y la que menos revisas.
include le dice al receptor que vaya a consultar otro registro
El mecanismo include no copia el registro de otro dominio dentro del tuyo. Le dice al servidor receptor que evalúe el registro SPF de ese otro dominio como una comprobación aparte y use el resultado: si la IP que conecta pasa allí, el include empareja y la evaluación se detiene.
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Ese registro dice: consulta la lista de Google, luego la de SendGrid, y luego aplica ~all a todo lo que no haya emparejado ninguna. Cada include le entrega al receptor un registro nuevo que analizar, que a su vez puede contener más términos include, y ahí es donde se va el presupuesto.
La palabra confunde en un punto concreto. include solo devuelve un pase o un no-empareja. Un -all dentro de un registro incluido no rechaza tu correo; solo significa que ese registro no emparejó, y la evaluación sigue con tu término siguiente. Solo el all de tu propio registro decide el resultado.
Cinco mecanismos gastan presupuesto, y tres son gratis
El RFC 7208, sección 4.6.4, limita una evaluación SPF a diez términos que consultan DNS. Pasarse es un error permanente de nivel MUST, no un aviso blando.
| Término | Cuesta una consulta |
|---|---|
include | Sí, y además todo lo que lleva dentro |
a | Sí |
mx | Sí |
ptr | Sí, y además está obsoleto |
exists | Sí |
ip4 | No |
ip6 | No |
all | No |
exp | No |
Dos detalles de esa tabla se cuentan mal a menudo. Un término mx cuesta una consulta por el término, no una por cada registro MX devuelto, y un registro que lista cien direcciones IP con ip4 no gasta nada en absoluto. Ese segundo punto es la base entera del aplanado de SPF.
La macro %{p} también se carga al mismo presupuesto de diez, porque expandirla exige una consulta inversa.
La cuenta es de términos evaluados, no de dominios nombrados
Esta es la regla que hace que un registro cueste más de lo que parece costar. El límite cuenta cada término con consulta DNS que un receptor evalúa durante una comprobación, y un dominio alcanzado por dos ramas distintas se evalúa dos veces.
Si tu registro incluye a dos proveedores y los dos incluyen el mismo dominio de infraestructura compartida, todo el subárbol de ese dominio se paga dos veces. Contar nombres de dominio distintos te da un número más bajo que el que alcanzará un receptor, y por eso un registro que sobre el papel parecen seis consultas puede dar permerror en la práctica.
Dos casos emparentados tienen el mismo sabor:
- Un bucle es un error permanente, no una rama que saltarse. Si A incluye a B y B incluye a A, un receptor no se para en silencio: falla el registro.
- Los términos posteriores a
allno se evalúan nunca.allsiempre empareja, así que lo que venga detrás es código muerto y no cuesta nada. Unredirectpuesto junto a unalles inerte por la misma razón.
Pasarse del límite hace fallar a los remitentes del final del registro
Un receptor evalúa tus términos en orden y se para en el primero que empareja. Eso produce tres resultados distintos a partir de un mismo registro roto, según quién esté enviando.
- Un remitente emparejado antes de que se agote el presupuesto pasa con normalidad. Para él no hay nada roto, y en tus registros no aparece nada.
- Un remitente emparejado después de la décima consulta recibe un error permanente. La mayoría de receptores tratan un permerror como un fallo y no como un registro ausente, así que DMARC no ve ningún pase de SPF.
- Un remitente que no está en tu registro llega a tu término
all, exactamente como estaba previsto, si la evaluación sobrevive hasta ahí.
Así que el síntoma práctico es que el correo de una plataforma empieza de golpe a fallar la autenticación mientras todo lo demás se ve bien. Si esa plataforma se añadió al final del registro, es la primera en caerse por el borde.
Eso también significa que una solución puede salir gratis. Mover tu remitente de mayor volumen al principio del registro no reduce el total, pero sí hace que ese remitente empareje antes de que se gaste el presupuesto. Compra tiempo, no resuelve el problema.
Cómo averiguar el número real
Contar a mano no es fiable, porque no puedes ver dentro del registro de un proveedor sin resolverlo, y los proveedores cambian el suyo sin avisarte. Pasa el dominio por un comprobador SPF gratuito, que recorre el árbol entero, resuelve cada include de forma recursiva e informa del total que alcanzaría de verdad un receptor, en vez del número de términos que escribiste.
Qué mirar en el resultado:
- El total frente al límite de diez. Cualquier cosa por encima significa que el registro puede dar permerror.
- Qué rama sale cara. Un proveedor suele ser responsable de la mayor parte del coste, y los proveedores varían muchísimo.
- Subárboles duplicados. La infraestructura compartida alcanzada dos veces es el exceso oculto más común.
- Consultas vacías. Un término que no resuelve a nada tiene su propio presupuesto aparte, y un
includeque apunta a un dominio sin registro SPF es un error permanente ya en la primera aparición. - Lo que haya detrás de
all. Los términos muertos son inofensivos, pero suelen ser señal de que el registro lo han editado varias personas que no lo leyeron.
En los dominios que probamos para el Unspam 2026 Email Deliverability Benchmark, el 93% publica un registro SPF válido, así que el fallo habitual en esta área no es un registro ausente sino un registro que ha ido creciendo en silencio por encima de su presupuesto.
Cuatro formas de volver por debajo de diez
Más o menos por orden de cuánto deberías preferirlas.
Quita lo que ya no usas. La mayoría de registros excedidos llevan un proveedor por el que nadie envía desde hace dos años. Es gratis, es permanente y casi siempre está disponible.
Sustituye un include por rangos ip4 cuando el proveedor publique rangos estables. Un término ip4 no cuesta nada. La pega es que el mantenimiento pasa a ser tuyo: cuando el proveedor cambie de IP, tu correo falla y nadie te avisa. Hazlo solo cuando el proveedor documente un rango estable y se comprometa a notificar los cambios.
Mueve el envío a un subdominio. Tu plataforma de marketing puede enviar desde mail.example.com con su propio registro SPF y su propio presupuesto de diez. Es la solución estructural, escala, y de paso separa las reputaciones.
Aplana el registro con un servicio. El aplanado de SPF resuelve cada include y publica por ti la lista de IP resultante, refrescándola sola. Funciona, y convierte la disponibilidad de un tercero en una dependencia de la autenticación de tu correo. Trátalo como la última opción, no como la primera.
Si estás construyendo un registro en vez de reparar uno, un generador de registros SPF produce un registro inicial correcto, y nuestra guía sobre registros SPF cubre la sintaxis al completo.
Qué comprobar cuando el registro ya está por debajo del límite
Que SPF pase es necesario pero no basta por sí solo, porque DMARC necesita que el dominio de SPF se alinee con la dirección de tu cabecera From, y SPF se rompe con el reenvío por muy pulcro que esté el registro. Nuestra guía sobre autenticación del correo cubre cómo dependen unos de otros los tres registros y por qué es DKIM, y no SPF, el que sobrevive a una lista de correo.
Vuelve a comprobar el total cada vez que añadas una plataforma de envío, y otra vez unos meses después aunque no hayas tocado nada, porque la cuenta incluye los registros de los proveedores y esos se mueven por debajo de ti. Para ver qué aspecto tiene un mensaje real en un receptor, con el resultado de SPF junto a todo lo demás que decide la ubicación, haz una prueba de spam gratis.
