SPF checker: comprueba tu registro SPF

Qué es un registro SPF y qué comprueba un SPF checker

Un registro SPF indica qué servidores están autorizados a enviar correo para un dominio. Se publica como un registro TXT que empieza por v=spf1. El servidor receptor puede comparar la IP que entrega un mensaje con esa política para obtener un resultado de autenticación.

Un SPF checker permite localizar el registro y detectar problemas en su configuración: políticas duplicadas, sintaxis incorrecta o dependencias de otros dominios. Es una comprobación útil cuando añades un proveedor de email o investigas un error SPF.

La consulta de Abalola analiza la política publicada y sus dependencias. No recibe un email de prueba ni evalúa una IP remitente concreta, por lo que no certifica que un mensaje haya obtenido spf=pass.

Cómo comprobar el registro SPF del dominio correcto

SPF se evalúa sobre el dominio del remitente de sobre, conocido como MAIL FROM. En un mensaje recibido suele aparecer en Return-Path. Ese dominio puede ser diferente del que ves en el campo De del correo.

Por ejemplo, una tienda puede mostrar [email protected] como remitente y utilizar envios.example.com para el Return-Path. En ese caso, comprobar únicamente example.com no permite conocer la política SPF utilizada en ese envío. Consulta el dominio exacto que aparece en el mensaje.

Introduce ese nombre en el SPF checker. La herramienta consulta sus TXT, identifica la política SPF y sigue las referencias include y redirect que puede analizar. No añadas un nuevo registro antes de revisar si ya existe uno.

Ejemplo de registro SPF: include, ip4, -all y ~all

En el ejemplo, ip4 autoriza una dirección IPv4 y -all establece un resultado fail para las IP que no coincidan con los mecanismos anteriores. La IP pertenece a un rango de documentación: sirve para entender la sintaxis, no para copiarla a tu DNS.

include permite evaluar la política SPF de otro dominio, algo habitual con proveedores de correo. ip6 declara direcciones IPv6; a y mx pueden autorizar direcciones obtenidas de los registros correspondientes. redirect remite a otra política cuando la evaluación llega a ese modificador.

El final ~all produce softfail para los emisores no autorizados; ?all expresa neutralidad. +all autoriza cualquier IP y deja sin utilidad esa restricción. -all no obliga por sí solo al receptor a rechazar el mensaje: el resultado SPF es una señal que el receptor utiliza junto con sus demás comprobaciones.

v=spf1 ip4:192.0.2.1 -all

SPF y el límite de 10 consultas DNS

SPF limita a diez los términos que provocan consultas DNS durante una evaluación. include, a, mx, exists y redirect pueden consumir ese presupuesto; las referencias anidadas también cuentan. ip4, ip6 y all no requieren ese tipo de consulta.

Tener pocos include visibles no garantiza quedar por debajo del límite: cada proveedor puede referenciar otras políticas. Si la evaluación supera el límite permitido, puede terminar en permerror.

Este SPF checker muestra los términos potenciales de las ramas analizadas. El recorrido real depende de la IP y del remitente del mensaje; no es un contador exacto de cada envío. Las macros que dependen del mensaje quedan pendientes y no se evalúa el límite de consultas vacías de un envío concreto.

Para reducir dependencias, empieza por identificar proveedores que ya no utilizas. No borres un include activo ni lo sustituyas por una lista de IP sin un proceso que mantenga esa lista actualizada.

Errores SPF habituales: duplicados, permerror y registro no encontrado

Dos registros TXT que empiezan por v=spf1 no forman una política conjunta: provocan un error. Si dos servicios necesitan autorización en el mismo dominio, sus instrucciones deben integrarse en una única política coherente. No confundas dos registros independientes con los fragmentos de texto de un mismo TXT.

SPF permerror indica un problema permanente de evaluación, como una sintaxis inválida o un límite excedido. Temperror se refiere a un fallo temporal, por ejemplo de DNS. Un fail significa que la IP evaluada no está autorizada por la política aplicable; son situaciones distintas.

Si no aparece un registro SPF, comprueba el Return-Path y que el DNS se haya editado en el proveedor correcto. Si se publica un cambio, vuelve a consultar cuando caduquen las cachés anteriores. Encontrar un registro no basta: sus referencias también deben ser válidas.

Diferencias entre SPF, DKIM y DMARC

SPF autoriza servidores de envío. DKIM añade una firma al mensaje que el receptor verifica con una clave pública. DMARC utiliza el resultado de SPF o DKIM y comprueba su alineación con el dominio visible del remitente.

Un correo puede pasar SPF y fallar DMARC si el dominio autenticado no está alineado y tampoco existe una firma DKIM válida y alineada. Por eso, un registro SPF correcto no demuestra por sí solo que la autenticación de tu newsletter esté completa.

Para comprobar un email real, revisa Authentication-Results en el mensaje recibido. El reenvío también puede alterar el resultado SPF al cambiar la IP que entrega el correo; una firma DKIM que siga siendo válida puede aportar la otra vía de autenticación.

Cuándo revisar el SPF de una tienda online

Revisa SPF al conectar o retirar una plataforma de email, cambiar de proveedor de buzones o activar un servicio que envíe notificaciones en tu nombre. Antes de editar, reúne los sistemas de marketing, atención al cliente y correo transaccional que utilizan ese dominio.

Después, prueba un envío de cada sistema y contrasta sus cabeceras. No des por resuelto un problema de spam solo porque el SPF checker no detecte errores: la reputación, las quejas y la calidad de la lista también influyen.

Preguntas frecuentes

Documentación técnica

• Cloudflare DNS JSON API
• RFC 7208 — SPF