Comprobar registro SPF: ¿funciona bien tu SPF?
¿Tu correo llega a spam o un servicio te dice que tu SPF no es válido? Escribe tu dominio aquí abajo. El comprobador obtiene el registro SPF, sigue cada include, cuenta las consultas DNS frente al límite de 10 y enumera en lenguaje claro qué hay que corregir.
Cómo usa tu registro SPF un servidor receptor
Cuando llega un mensaje, el servidor receptor mira el dominio del remitente del sobre (envelope sender) y obtiene el registro SPF de ese dominio: un registro TXT que empieza con v=spf1. Luego comprueba si la dirección IP del servidor que acaba de conectarse está en la lista. El resultado es pass, fail, softfail o neutral, y el receptor lo pondera junto con otras señales para decidir si el mensaje va a la bandeja de entrada o a la carpeta de spam.
SPF comprueba el remitente del sobre, no la dirección From que la gente ve en su aplicación de correo. Cerrar esa brecha es trabajo de DMARC.
Los términos de SPF de un vistazo
| Término | Qué hace |
|---|---|
| ip4:192.0.2.0/24 | Permite una dirección o un rango IPv4 |
| ip6:2001:db8::/32 | Permite una dirección o un rango IPv6 |
| a | Permite las direcciones de los registros A y AAAA del propio dominio |
| mx | Permite las direcciones de los servidores de correo del dominio |
| include:_spf.example.net | Permite también lo que permita el registro SPF de ese dominio |
| exists:name | Permite cuando una consulta DNS del nombre devuelve una dirección |
| ptr | Obsoleto. Coincide mediante DNS inverso y no debería usarse |
| all | Coincide con todo, por eso va al final y fija el resultado predeterminado |
Un calificador delante de un término define el resultado cuando coincide: + pass (el valor predeterminado), - fail, ~ softfail, ? neutral. Los finales habituales son ~all, que marca como sospechosos a los remitentes no incluidos, y -all, que pide a los receptores que los rechacen.
Por qué SPF se rompe cuando añades un servicio más
SPF permite como máximo 10 términos que provoquen una consulta DNS mientras se evalúa un registro. Cuentan include, a, mx, ptr y exists, y también un modificador redirect. ip4, ip6 y all no cuentan. Las consultas dentro de un registro incluido suman al mismo total.
Así es como un registro sano se estropea: añades una herramienta de newsletters, un helpdesk, un CRM y un sistema de facturación, cada uno con su propio include, y algunos de esos include contienen a su vez otros include. Si pasas de 10, SPF devuelve un error permanente. Los receptores pueden entonces tratar cada mensaje como si el dominio no tuviera SPF, y nadie te avisa.
- Elimina los include de servicios que ya no uses.
- Sustituye un include por rangos ip4 e ip6 cuando las direcciones del proveedor sean estables.
- No uses nunca ptr.
- Dale a cada servicio de envío su propio subdominio siempre que puedas. Cada nombre tiene su propio límite de 10.
- Si aplanas los include en direcciones, recuerda que los proveedores cambian sus rangos, así que un registro aplanado necesita actualizaciones periódicas.
Una forma segura de definir tu política SPF
- Publica exactamente un registro SPF por nombre. Dos registros son un error permanente.
- Empieza con ~all mientras confirmas que todos los remitentes legítimos están en la lista y pasa a -all cuando estés seguro.
- Recuerda que SPF no se hereda. Un subdominio que envía correo necesita su propio registro, y un subdominio que nunca envía correo puede publicar v=spf1 -all.
- Combina SPF con DKIM y una política DMARC. Cada uno cubre las debilidades de los otros.