Cómo funciona la comprobación de SPF
Nuestro servidor pide al resolvedor público de Cloudflare los registros TXT del dominio y elige el que empieza por v=spf1. Después consulta el registro SPF de cada dominio nombrado en un include o redirect, y de los dominios que estos nombran, hasta 20 registros y seis niveles de profundidad, como lo haría un servidor de correo receptor. Nunca se conecta a los propios servidores de correo.
Cada término se lee según las reglas de la RFC 7208. Un receptor compara la dirección del servidor que envió un mensaje con los términos de izquierda a derecha; el primero que coincide decide, y su calificador indica cómo: + pasa, - falla, ~ fallo suave, ? neutro. Un término sin calificador pasa.
Los términos include, a, mx, ptr, exists y redirect cuestan cada uno una consulta DNS, y también los que hay dentro de cada registro incluido. La RFC 7208 permite 10 por comprobación: por encima de eso, el receptor se detiene y SPF falla para todo el correo del dominio. ip4, ip6 y all no cuestan nada. En el modo de registro pegado, el registro se lee en tu navegador, así que solo se cuentan sus propias consultas.
Mecanismos y calificadores de SPF
Los términos que puede contener un registro SPF, con qué coincide cada uno y cuánto cuesta de las 10 consultas:
| Término | Coincide cuando el servidor emisor… | Consultas |
|---|---|---|
ip4 | tiene una dirección IPv4 en la dirección o el rango, como ip4:192.0.2.0/24. | 0 |
ip6 | tiene una dirección IPv6 en la dirección o el rango, como ip6:2001:db8::/32. | 0 |
a | tiene una dirección que nombra el registro A o AAAA del dominio (este dominio, o a:other.example). | 1 |
mx | es uno de los servidores de correo del dominio (sus registros MX). | 1 |
include | pasa el registro SPF de otro dominio, normalmente el de un servicio de correo. | 1 + las de su registro |
exists | hace que exista un nombre que el receptor construye a partir del mensaje; para configuraciones especiales. | 1 |
ptr | tiene un nombre DNS inverso dentro del dominio. No lo uses: es lento y poco fiable. | 1 |
all | es cualquiera. Siempre va el último: fija qué pasa con todos los servidores que no figuran. | 0 |
redirect= | está permitido por el registro de otro dominio, que se usa cuando nada de este coincidió. | 1 + las de su registro |
exp= | nunca: solo nombra un texto que explica un rechazo. | 0 |
Calificadores
- + pasa (el valor por defecto si no se escribe nada): el servidor puede enviar.
- - falla: el servidor no puede enviar; los receptores pueden rechazar el correo.
- ~ fallo suave: probablemente no está permitido; el correo se acepta pero se trata como sospechoso.
- ? neutro: sin veredicto, como si no hubiera registro SPF.
Ejemplo
example.com publica "v=spf1 ip4:192.0.2.10 mx include:spf.mailer.example ~all". El término ip4 no cuesta ninguna consulta, mx cuesta una y el include cuesta una más lo que necesite el registro de spf.mailer.example. Ese registro es "v=spf1 ip4:198.51.100.0/24 include:spf2.mailer.example -all": una consulta más, y spf2.mailer.example solo enumera rangos de direcciones. Eso suma 3 de 10. Un mensaje desde 192.0.2.10 pasa en el primer término; uno desde 203.0.113.5, que ningún término enumera, llega a ~all y da fallo suave, por lo que normalmente se acepta pero se trata como sospechoso.
Preguntas
¿Qué es un registro SPF y cómo lo compruebo?
SPF (Sender Policy Framework) es un registro TXT en el DNS de un dominio que enumera los servidores autorizados a enviar correo en su nombre y empieza por v=spf1. Para comprobarlo, escribe arriba el dominio: el comprobador encuentra el registro, sigue sus includes y muestra qué significa cada término y qué está mal. Para comprobar un registro antes de publicarlo, cambia al modo «Un registro pegado».
¿Cómo soluciono el error «too many DNS lookups» de SPF?
SPF permite 10 consultas DNS por comprobación, contando cada include, a, mx, ptr, exists y redirect, también dentro de los registros incluidos. Por encima de 10, el registro falla con un error permanente (permerror). Quita los includes de servicios que ya no usas, sustituye a y mx por las direcciones ip4 e ip6 que representan, y envía el correo masivo desde un subdominio con su propio registro SPF. Aplanar (copiar las direcciones de un servicio en tu registro) también funciona, pero queda desfasado cuando el servicio las cambia.
¿Puede un dominio tener dos registros SPF?
No. Un dominio solo puede publicar un registro TXT que empiece por v=spf1. Con dos, los receptores devuelven un error permanente y SPF falla para todo el correo. Únelos: deja un solo v=spf1, pon en él los términos de ambos y termina con un único ~all o -all. Los subdominios tienen sus propios registros y no cuentan.
¿Qué diferencia hay entre ~all y -all?
-all (fallo) indica a los receptores que el correo de servidores que no figuran no está permitido y puede rechazarse. ~all (fallo suave) dice que probablemente no está permitido: suele aceptarse y marcarse como sospechoso. Con DMARC activado, los receptores siguen la política DMARC en ambos casos, así que ~all es la opción habitual; -all conviene a un dominio que no envía correo en absoluto. Evita ?all y +all: no protegen nada.
¿SPF protege la dirección From que ve la gente?
Por sí solo, no. SPF comprueba el dominio de la dirección de rebote (Return-Path), que la gente nunca ve, así que un falsificador puede pasar SPF con un dominio propio y seguir mostrando el tuyo en From. DMARC cierra esa brecha: exige que SPF o DKIM pasen para el dominio de la línea From. Usa el comprobador de DMARC para ver si el tuyo lo hace.