Cuenta cada consulta DNS del registro

Herramienta gratuita

Verificador SPF

Comprueba el registro SPF de cualquier dominio y lo cerca que está del límite de consultas

Comprobación gratuita del registro SPF de cualquier dominio. Resolvemos el registro completo desde tu navegador, seguimos cada include y cada redirect igual que un servidor receptor, y te mostramos las consultas DNS sobre 10, las consultas vacías, la política por defecto y todos los rangos de IP que el registro autoriza.

Escribe cualquier dominio. No necesitas una cuenta ni acceso a su DNS.

La comprobación se ejecuta en tu navegador mediante DNS-over-HTTPS, así que el registro SPF llega hasta ti sin pasar por nuestros servidores. Recibimos el nombre de cada dominio comprobado, y ese nombre lanza una comprobación independiente desde nuestros propios servidores cuyo resultado, incluido el propio registro SPF, guardamos para mantener al día nuestro índice público de dominios.

Cómo usar este verificador SPF

Tres pasos para pasar de un nombre de dominio a una respuesta sólida sobre su configuración SPF.

  1. 1

    Escribe un dominio

    Escribe cualquier dominio en el formulario de arriba. No necesitas ser su propietario ni tener acceso a su DNS.

  2. 2

    Resolvemos el registro completo

    Tu navegador consulta los registros TXT del dominio mediante DNS-over-HTTPS y después sigue cada término include, redirect, a, mx y exists que encuentra, igual que haría un servidor receptor.

  3. 3

    Lee el conteo y el resultado

    Obtienes el total de consultas DNS sobre 10, el total de consultas vacías sobre 2, la política por defecto del mecanismo all, cada error de sintaxis y cada rango de IP autorizado, agrupado por el include del que procede.

Qué te dice una comprobación de SPF

Un registro SPF puede tener una sintaxis correcta y aun así fallar en producción. Usa esta comprobación para:

  • Confirmar que un remitente nuevo se agregó bien tras conectar Google Workspace, Microsoft 365, SendGrid o Mailchimp.
  • Ver cuánto margen queda antes del límite de 10 consultas, antes de agregar otro include.
  • Diagnosticar un permerror que hace fallar el DMARC aunque el correo sea legítimo.
  • Encontrar una consulta vacía que dejó un host dado de baja o un proveedor cancelado.
  • Comprobar si el registro termina en -all, ~all, ?all o en nada.
  • Auditar el SPF de un proveedor o de un dominio adquirido antes de dejar que envíe en tu nombre.

Entender el SPF

El límite de 10 consultas DNS

El RFC 7208, sección 4.6.4, obliga a los receptores a detenerse tras 10 términos que provocan una consulta DNS dentro de una misma evaluación de SPF. Esos términos son los mecanismos include, a, mx, ptr y exists y el modificador redirect. Los mecanismos ip4, ip6 y all no cuestan nada, y el modificador exp queda exento porque su consulta ocurre cuando la evaluación ya ha terminado. Si se cruza el límite, el resultado es permerror, que los receptores tratan como un fallo de SPF en todos los mensajes que envía el dominio. El conteo es recursivo: cada include suma las consultas del registro al que apunta, así que cuatro include pueden costar quince con facilidad.

Las consultas vacías y por qué el tope es dos

Una consulta vacía es una consulta DNS hecha durante la evaluación del SPF que no devuelve nada: o NXDOMAIN, o NOERROR con la sección de respuesta vacía. El RFC 7208, sección 4.6.4, indica que las implementaciones deberían limitar las consultas vacías a dos y recomienda dos por defecto; más allá de ahí, el resultado es permerror. Vale la pena corregir las consultas vacías incluso cuando el total de consultas es holgado, porque cada una significa que el registro sigue nombrando un host o un include que ya se dio de baja.

-all, ~all, ?all y +all

El mecanismo all va al final del registro y coincide con todo remitente que no haya coincidido antes (RFC 7208, sección 5.1). Su calificador decide el resultado. -all es fail: una declaración explícita de que el remitente no está autorizado. ~all es softfail: el dominio dice que el remitente probablemente no está autorizado, pero no llega a afirmarlo, y pide a los receptores que no rechacen solo por eso. ?all es neutral, y la sección 8.2 exige a los receptores tratarlo exactamente igual que si no hubiera registro. +all autoriza a cualquier host de internet y anula el sentido de publicar SPF. Un registro sin mecanismo all y sin redirect también termina en neutral. Apunta a -all en cuanto tus informes DMARC muestren que todos los remitentes legítimos están cubiertos.

Las macros de SPF

Las macros (RFC 7208, sección 7) permiten que un registro construya el nombre DNS que consulta a partir del mensaje que se está comprobando, escritas como un signo de porcentaje y una letra entre llaves. La macro i se expande a la IP remitente, s a la dirección MAIL FROM completa, l a su parte local, o y d a nombres de dominio, y h al nombre HELO. Las grandes plataformas las combinan con el mecanismo exists para que un solo registro responda por cliente o por IP sin publicar miles de registros. Las macros son legítimas y esta herramienta resuelve lo que puede, pero una macro implica que la respuesta real depende del mensaje, así que ninguna comprobación estática puede predecirla del todo. La macro que conviene evitar es p: obliga a una consulta DNS inversa, el mismo motivo por el que la sección 5.5 del RFC 7208 desaconseja el mecanismo ptr.

El flattening de SPF

El flattening sustituye los términos include, a y mx por los rangos ip4 e ip6 a los que resuelven en ese momento. Copiado a mano, el registro resultante cuesta cero consultas DNS; un servicio gestionado lo publica detrás de un único include alojado, es decir, una sola consulta. En ambos casos es la única manera fiable de devolver por debajo del límite de 10 un registro con muchos remitentes. La contrapartida es que congela una foto fija: cuando un proveedor cambia los rangos que hay detrás de su include, un registro aplanado a mano sigue autorizando los antiguos y empieza a hacer fallar correo que sí enviaste. Por eso el flattening solo es seguro si algo lo vuelve a resolver de forma periódica. Los registros aplanados también son largos, y un registro TXT de más de 255 caracteres debe publicarse en varias cadenas que los receptores vuelven a unir (RFC 7208, sección 3.3).

Preguntas frecuentes

¿Qué es un registro SPF?
El SPF (Sender Policy Framework, RFC 7208) es un registro TXT publicado en el DNS de un dominio que indica qué servidores pueden enviar correo usando ese dominio en la dirección SMTP MAIL FROM. El servidor receptor lee el registro, lo compara con la dirección IP que se conecta y devuelve pass, fail, softfail, neutral, none, temperror o permerror. El DMARC usa después ese resultado, siempre que el dominio del MAIL FROM esté alineado con el del encabezado From visible.
¿Qué es el límite de 10 consultas DNS del SPF?
El RFC 7208, sección 4.6.4, obliga a los receptores a detenerse tras 10 términos que provocan una consulta DNS al evaluar un registro SPF. Los mecanismos include, a, mx, ptr y exists y el modificador redirect cuentan todos; ip4, ip6 y all no cuestan nada. El límite es recursivo, así que cada include arrastra también las consultas del registro al que apunta. Por eso un registro con solo cuatro o cinco include supera el límite con frecuencia.
¿Qué pasa cuando un registro SPF supera las 10 consultas?
El receptor deja de evaluar y devuelve permerror, que se trata como un fallo de SPF en todos los mensajes, incluidos los que salen de tus propios servidores. Si esos mensajes tampoco llevan una firma DKIM alineada, el DMARC también falla y el correo puede acabar en cuarentena o rechazado. El fallo es silencioso para quien envía: en tu DNS no cambia nada, así que el registro puede cruzar el límite el día en que un proveedor agrega un rango a su propio include.
¿Qué es una consulta vacía en SPF?
Una consulta vacía es una consulta DNS hecha durante la evaluación del SPF que vuelve sin datos: o bien NXDOMAIN, o bien una respuesta NOERROR sin registros. El RFC 7208, sección 4.6.4, indica que las implementaciones deberían limitar las consultas vacías a dos y recomienda dos por defecto; a partir de ahí el resultado es permerror. En la práctica, una consulta vacía significa que el registro sigue nombrando un host o un include que ya no existe.
¿Mi registro SPF debe terminar en -all o en ~all?
-all (fail) es el estado final. Le dice al receptor que el remitente no está autorizado, y es lo que hace que el SPF restrinja algo de verdad. ~all (softfail) es un calificador de transición: el dominio dice que el remitente probablemente no está autorizado, pero pide a los receptores que no rechacen solo por eso. Empieza con ~all mientras confirmas en tus informes DMARC que todos los remitentes legítimos están cubiertos, y pasa después a -all. ?all es neutral y, según la sección 8.2 del RFC 7208, debe tratarse exactamente como si no existiera ningún registro.
¿Qué es el flattening de SPF y es seguro?
El flattening sustituye los términos include, a y mx por los rangos ip4 e ip6 a los que resuelven en ese momento. Copiado a mano, el registro resultante cuesta cero consultas DNS; un servicio gestionado lo publica detrás de un único include alojado, es decir, una sola consulta. Es la única forma fiable de devolver por debajo del límite de 10 un registro con muchos remitentes. Hecho una sola vez a mano no es seguro, porque el registro congela una foto fija y sigue autorizando rangos antiguos después de que un proveedor cambie los suyos. Solo es seguro si algo lo vuelve a resolver y lo republica de forma periódica.
¿Es gratis este verificador SPF?
Sí, y no hace falta registrarse. La consulta se ejecuta en tu navegador contra resolutores DNS-over-HTTPS públicos, así que el registro SPF llega hasta ti sin pasar por nuestros servidores. Lo que sí recibimos es el nombre de cada dominio comprobado. Ese nombre lanza una comprobación independiente desde nuestros propios servidores, y guardamos su resultado, incluido el propio registro SPF, para mantener al día nuestro índice público de dominios. Un registro SPF es un dato DNS público que cualquiera puede consultar.