Pase cualquier dominio por este verificador de SPF y obtendrá el registro en vivo, expandirá cada mecanismo y le mostrará la lista completa de direcciones IP en las que su dominio confía actualmente para enviar correo. Todo lo que quede fuera de esa lista es lo que los servidores receptores cuestionarán o rechazarán. Si es nuevo en el concepto, empiece por qué es una consulta SPF y por qué importa.
Qué aspecto tiene un registro SPF
Un registro SPF es una única entrada TXT publicada en sus registros DNS que indica a los receptores qué servidores de correo pueden enviar mensajes en nombre de su dominio. Un registro típico tiene este aspecto:
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 -all
Cada pieza es un mecanismo. El mecanismo include: incorpora los remitentes autorizados de otro dominio, ip4: autoriza una dirección IP o un rango de IP específico, y el -all final rechaza a cualquier otro remitente. Cuando ejecuta este verificador de SPF, expande cada mecanismo, valida la sintaxis frente a la especificación de Sender Policy Framework (SPF) (RFC 7208) y enumera todas las direcciones IP que su dominio autoriza actualmente.
Errores habituales de SPF y qué significan
Cuando el verificador analiza su registro, el resultado se resuelve en uno de varios desenlaces de SPF. Los errores que conviene reconocer:
- PermError (se muestra como
PermErroren la salida de la herramienta): un fallo permanente en el propio registro. Casi siempre es un error de sintaxis o un registro que supera el límite de consultas DNS. Los receptores tratan el registro como si no existiera. Corrija la sintaxis o reduzca los includes anidados para resolverlo. - TempError (
TempError): un problema temporal de resolución DNS, a menudo un servidor de nombres lento o inaccesible. Vuelva a probar en unos minutos; si persiste, revise su proveedor de DNS. - softfail (el cualificador
~all): el remitente no está autorizado, pero los receptores deberían aceptar el mensaje y marcarlo como sospechoso. Habitual en configuraciones de transición antes de pasar a rechazo estricto. - hardfail (el cualificador
-all): el remitente no está autorizado, así que los receptores rechazan el mensaje directamente. Es la configuración que desea una vez que todos los remitentes legítimos están contemplados. - none: el dominio no publica ningún registro SPF, por lo que los receptores no tienen nada con lo que comprobar al remitente y a menudo tratan el correo como no fiable.
- neutral (el cualificador
?all): el dominio se abstiene explícitamente de afirmar la autorización. Se trata de forma parecida a none.
Cada desenlace se corresponde con una corrección distinta. Los errores de sintaxis, los registros TXT ausentes y los remitentes no autorizados aparecen en el verificador como categorías de error diferenciadas, para que pueda actuar sobre ellos sin escarbar en respuestas DNS en bruto.
Cómo funciona SPF con DKIM y DMARC
SPF es uno de los tres estándares de autenticación de correo que funcionan juntos, así que una comprobación de SPF rara vez cuenta toda la historia por sí sola. SPF verifica el servidor emisor, DKIM añade una firma criptográfica que demuestra que el mensaje no se alteró en tránsito, y DMARC vincula ambos: comprueba que SPF o DKIM se alinea con el dominio de la dirección "From" visible e indica a los receptores qué hacer cuando la autenticación falla. Gmail, Yahoo y Microsoft ahora exigen los tres a los remitentes masivos, así que un registro SPF válido es la base sobre la que se construye el resto de su autenticación de correo, y su defensa frente a la suplantación y el fraude por correo.
Cuando resuelva un problema que este verificador de SPF detecte, vuelva a comprobar DKIM y DMARC al mismo tiempo. Un registro SPF técnicamente válido que no esté alineado con su política DMARC puede fallar igualmente, y endurecer SPF a -all antes de que sus otros remitentes estén cubiertos bloqueará correo legítimo.
El límite de 10 consultas DNS
include, a, mx, ptr y exists cuenta para el límite de 10 consultas DNS. Si lo cruza, el registro falla con PermError.La especificación de Sender Policy Framework limita las consultas DNS a diez por evaluación (RFC 7208, sección 4.6.4). Cada mecanismo include:, a, mx, ptr y exists cuenta para el límite, y los includes anidados cuentan de forma recursiva. Cuando su registro supera el límite de 10 consultas DNS, los receptores devuelven PermError y sus mensajes pueden ir a spam por muy correcto que sea el resto de su registro: cada dirección IP que haya enumerado deja de importar en cuanto el límite de consultas rebasa las diez.
El verificador cuenta cada consulta que desencadena su registro, incluidas las ocultas dentro de directivas include: de terceros. Si supera las diez —o está cerca—, AutoSPF puede aplanar su registro SPF automáticamente, preservando las direcciones IP autorizadas al tiempo que colapsa las consultas anidadas en un único registro SPF válido.
Cuándo ejecutar una comprobación de SPF
Ejecute una comprobación de SPF siempre que añada o elimine un proveedor de correo, migre de plataforma o note que los mensajes acaban en spam; estas comprobaciones del registro SPF son higiene rutinaria, así que audite su registro al menos una vez por trimestre. Cada vez que cambie quién envía correo por su dominio, una consulta SPF confirma que el registro sigue resolviéndose, se mantiene por debajo del límite de 10 consultas y solo enumera los servidores en los que confía. Herramientas como esta convierten eso en una comprobación de 10 segundos en lugar de una sesión manual de dig, y combinan bien con un verificador de DMARC y una consulta de DKIM para una visión completa de su autenticación de correo. Compruebe también sus subdominios por separado: un subdominio no hereda el registro SPF del dominio principal, así que cada subdominio que envíe correo necesita el suyo propio.