SPF: Parte del ADN de cualquier Sistema de Correo Electrónico moderno

Saludos amigos, hoy os traigo algo de teoría, aunque será muy breve. Como muchos ya sabéis, tener un SPF correcto nos garantiza que nuestros correos electrónicos lleguen a a destinatarios que implementan medidas de seguridad adicionales gracias a la comprobación del SPF, entre otros.

Gmail, Hotmail, Yahoo, etc. son los proveedores de correo electrónico gratuito más conocidos, y por lo tanto que lleguen los correos usuarios que alojan allí su cuenta de correo electrónico es importante.

Ya os deje hace un tiempo un artículo sobre cómo configurar SPF, DKIM, rDNS, etc en nuestro sistema de Correo Electrónico Zimbra para conseguir enviar a todos estos dominios, o cualquier otro, podéis volver a leer este artículo haciendo click en esta entrada.

¿Qué es SPF?

Sender Policy Framework (SPF) es un sistema de validación de correos diseñado para prevenir los correos no deseados detectando el spoofing de correos, un problema de seguridad común, mediante la verificación de la dirección IP del remitente.

¿Donde se configura?

SPF se configura a nivel de DNS pública del dominio.

¿Cómo se configura?

Primero debemos generar nuestra entrada SPF correcta para nuestro dominio. Hay varias webs que nos ayudan en este aspecto o tenemos mucha más literatura en los siguientes enlaces:

• http://tools.ietf.org/html/rfc7208
• http://www.openspf.org/
• http://www.openspf.org/SPF_Record_Syntax

¿Cómo luce un registro SPF?

Una entrada TXT SPF muy sencilla es la que os traigo a continuación, permitiendo una IP en concreto y marcando como FAIL si se intenta enviar desde otra IP

En este ejemplo "v=spf1 ip4:60.70.80.90 -all":

• v=spf1 es la versión del SPF
• 60.70.80.90 es la IP que permitimos que envie en nombre de nuestro dominio
• -all al tener el simbolo del menos (-) indicamos que solamente esta IP podrá enviar correo, si se intenta enviar desde otra IP con el dominio causará lo que se llama un Hard Fail.

Securizando nuestro SPF mucho más

Una práctica muy común que casi todo el mundo utiliza es usar el parámetro ~all, que es uno de los más light, y concuerde o no todo el SPF, marcar simplemente como softfail. Aquí os dejo al tabla completa de lo que significa los diferentes parámetros.

Parámetro	Resultado	Significa
+all	pass	Permite todo el email, como si no tuvieramos nada
-all	fail	Solamente marcará como válido si la IP, MX, etc. concuerda con el sistema que está enviando el correo.
~all	softfail	Permite enviar el correo, concuerde o no con los parámetros de la entrada TXT SPF (el 98% de las empresas que conozco suele utilizar este parámetro )
?all	neutral	Sin política

¿Cuál es la diferencia entre ~all y -all?

Esta configuración es siempre subjetiva, yo suelo recomendar (-) si estamos sufriendo ataques de SPAM, cambiando la entrada a hard fail con el símbolo de -, obtendremos una reducción del SPAM. Podemos seguir usando (~) cuando todo se haya calmado o para el día a día.

Añadiendo plataformas externas como Mailchimp, Salesforce, etc.

Si en tu empresa haces uso de Mailchimp, Salesforce, o cualquier otro Software que acabe enviando emails en nombre de tu dominio, tienes que añadir los mismos a la entrada SPF o de lo contrario me temo que ese boletín tan interesante sobre las últimas novedades está llegando a SPAM, seguramente. Os dejo aquí las entradas más comunes que se deben añadir al registro SPF:

• include:servers.mcsv.net (Mailchimp)
• include:_spf.salesforce.com (Salesforce)
• include:_spf.google.com (Google Apps)

Si estáis buscando alguno en concreto, en la búsqueda de Google introducir “spf include nombreservicio”

Comprobando la entrada SPF

Hay varias herramientas para comprobar el SPF, dos que me gustan mucho son:

• http://tools.wordtothewise.com/spf (nos muestra un resumen de todas las IP a las que estamos dando permiso de enviar en nombre de nuestro dominio)
• http://www.kitterman.com/getspf2.py (un clásico que nos muestra la entrada SPF, y además si el test pasa, o da algún tipo de error)
• http://mxtoolbox.com/

Por ejemplo el SPF de google se vería así usando el primer link:

Entradas de tipo SPF vs TXT SPF

En Abril de 2014, se deprecaba de manera oficial las entradas DNS de tipo SPF, dejando solamente válidas las de tipo TXT que dentro contengan el SPF. Para que os hagáis una ídea antes de Abril de 2014, era necesario tener estas dos entradas, o una de ellas para tener un SPF válido:

Pero desde Abril de 2014, debemos borrar la entrada DNS del tipo SPF, y dejar únicamente la de TXT. Aquí el texto de la RFC donde se explica:

No solamente eso, si no que si seguimos obsoletos con entradas de tipo SPF en vez de TXT, es muy probable que estemos dando un Soft Fail cuando enviamos correo, podemos comprobarlo por ejemplo con el dominio google.com usando http://mxtoolbox.com/

Introducimos el dominio en el campo de búsqueda:

Pulsamos abajo a la derecha sobre la opción llamada spf lookup.

Y podemos ver que google.com no tiene una entrada obsoleta y deprecada del tipo SPF, si no que utiliza TXT y dentro introduce el valor SPF.Nada más, hasta aquí este post que espero que os sirva y os ilustre en este noble arte de las entradas SPF, un tema que si tenemos mal configurado