Verificador de registros SPF

Qué hace un registro SPF

SPF (Sender Policy Framework) permite que un dominio publique, en DNS, la lista de servidores autorizados a enviar correo en su nombre. Cuando llega un mensaje, el servidor receptor mira el dominio del remitente del sobre (el Return-Path, también llamado MAIL FROM) y lee el registro SPF de ese dominio. Si la dirección IP que se conecta está en la lista, SPF pasa. Si no, el registro indica qué debe hacer el receptor al respecto.

SPF no mira la dirección From que ven sus destinatarios. Por eso un mensaje puede pasar SPF y aun así fallar DMARC: los dos dominios tienen que coincidir, y SPF por sí solo no lo logra.

Cómo leer el registro

Un registro SPF es una sola línea de texto que empieza por v=spf1 y consta de términos leídos de izquierda a derecha. El primer término que coincide con la IP emisora decide el resultado.

El límite de 10 consultas DNS

El estándar SPF (RFC 7208) permite al receptor gastar como máximo diez consultas DNS al evaluar un registro. Los términos include, a, mx, ptr, exists y redirect cuentan cada uno, y también cada consulta dentro de un registro incluido. Si se superan diez, el resultado es un error permanente, que los receptores tratan como un fallo.

La causa habitual es acumular varios servicios de correo: una plataforma de marketing, un helpdesk, un CRM y un proveedor de correo pueden consumir casi todo el presupuesto entre ellos. El verificador sigue cada include como lo hace un receptor y muestra el recuento frente al límite, para que vea qué rama es costosa.

El estándar también limita a dos las consultas "void" (nombres que no devuelven nada). Por eso un include que apunta a un dominio sin registro SPF se cuenta como un problema.

Soluciones que funcionan: elimine los servicios que ya no use, sustituya los términos a, mx e include por rangos ip4 e ip6 cuando el proveedor publique rangos estables, y envíe distintos tipos de correo desde subdominios distintos para que cada uno tenga su propio registro.

Errores que señala el verificador

Estos son los problemas que vemos con más frecuencia; el verificador informa de cada uno con una solución en lenguaje claro.

• Más de un registro SPF en el mismo dominio. Los receptores lo tratan como un error, así que combine los registros en uno solo.
• Un registro que termina en +all, o en ?all en un dominio que envía correo real. +all autoriza a todos los servidores de internet.
• Ausencia total del término all, lo que deja sin definir el resultado para los servidores no incluidos.
• Un error tipográfico en el nombre de un mecanismo o en una dirección IP, que invalida todo el registro.
• Un include que apunta a un dominio sin registro SPF, o un bucle en el que dos registros se incluyen entre sí.
• El mecanismo ptr, que es lento, poco fiable y está obsoleto.
• Un registro de más de 255 caracteres pegado como una sola cadena, o uno que ya no cabe en una única respuesta DNS.

Lo que un SPF correcto no le dice

Un registro limpio significa que la política está bien formada. No demuestra que un mensaje concreto haya pasado. Para probar un mensaje real, abra sus encabezados y lea la línea Authentication-Results, o péguelos en nuestro analizador de encabezados de correo.

SPF también se rompe cuando el correo se reenvía, porque la IP del servidor que reenvía no está en su registro. Es una de las razones por las que DMARC acepta SPF o DKIM, y por la que también debería firmar su correo con DKIM.

¿Soft fail o hard fail?

Tanto ~all (soft fail) como -all (hard fail) indican al receptor que el remitente no estaba autorizado. En la práctica, la mayoría de los receptores usan SPF como una señal más entre varias y aplican su propio criterio; es DMARC el que decide qué ocurre con el correo que falla. Muchas organizaciones publican ~all mientras siguen descubriendo todos sus remitentes y pasan a -all cuando la lista está completa. Ambos son aceptables; +all y la falta de all no lo son.