El SPF o Sender Policy Framework es un registro que identifica a uno o varios servidores como enviadores permitidos por el dominio que está realizando el envío. Tal vez lo hayas leído en algún correo, pero no tienes muy claro lo qué es; no te preocupes, en este artículo te lo vamos a compartir, tomando en cuenta las enseñanzas de nuestro máster Javi Burgos.
El objetivo del Sender Policy Framework es, a grandes rasgos, evitar que se envíe email desde servidores que no tienen nada que ver con el dominio del enviador, identificando así posibles actos de “phising” o “spoofing» para que posteriormente los servidores destino marquen esos email como “spam” (aunque se parece en la descripción, no hay que confundirlo con el DKIM).
¿Qué significa todo esto?
Ok, vamos despacio – esto del Sender Policy Framework lo vamos a explicar paso a paso. Cuando recibimos un email lo normal es que nos fijemos en dos datos principalmente: el título del email (subject) y quien nos envía este mensaje (from).
[tweetthis twitter_handles=»@mittum»]El #SPF en el #email nos ayuda a evitar enviar mail desde servidores no permitidos – @elogiaburgos[/tweetthis]
Este origen del mensaje es identificado con un alias y una dirección de email que nos indica quien nos ha enviado el email; dicha dirección de email está formada por un identificador y un dominio separados ambos por la famosa @ (arroba).
Es justo en este punto donde interviene el Sender Policy Framework. Los servidores que gestionan el correo electrónico y lo distribuyen a sus buzones correspondientes revisan esos dominios para ver si verdaderamente vienen de donde verdaderamente dicen que vienen.
¿Dónde se define el Sender Policy Framework y por qué se llama «registro»?
El Sender Policy Framework se define en un registro de tipo TXT (texto, como en el bloc de notas) en el DNS (Domain Name Server) de nuestro dominio.
[tweetthis twitter_handles=»@mittum»]En todos los casos, el #SPF se define como un registro tipo TXT – @elogiaburgos[/tweetthis]
Los registros DNS son como una guía telefónica, dónde a un cierto nombre (dominio) se le asigna un número de identificación (en este caso, una IP); esta guía tiene varios tipos de registros que desglosan diversos bloques de información del dominio al que se refieren. Con esto vamos a registros de los siguientes tipos:
- Tipo A (identificación de IP para un dominio)
- Tipo CNAME (alias de dominio)
- Tipo MX (identificación de servidores que contienen los buzones de correo electrónico)
- Registros TXT (que contienen información de texto respecto a nuestro dominio.
En lo particular, es este último es el que nos interesa ya que es el que contendrá la información correspondiente para asignar el Sender Policy Framework.
Montando un registro Sender Policy Framework
Esto es muy sencillo, siempre y cuando tengamos acceso a nuestro panel de administración de dominio (si éste no es el caso, deberemos de delegarlo a quien tenga ese control).
Suponiendo que podemos acceder a dicho panel, lo único que deberemos hacer es acceder a la parte de gestión de DNS de nuestro dominio e indicarle que queremos añadirle un registro TXT. Una vez indicado nos pedirá el contenido de este registro, ahí deberemos indicar:
- La versión del SPF a utilizar: v=spf1
- Las máquinas autorizadas, podemos realizarlo con la palabra include para indicar un dominio (el cual resolverá con su registro a las ips implicadas), o con la palabra ip4 para ponerle unas ip o un rango, o podemos ponerle mx para indicarle los servidores definidos en el registro mx del servidor
- Por último, ~all o -all, que indica que lo que no cumpla con el resto de reglas no será autorizado, la diferencia de – con ~ es la respuesta del servidor respecto al mail que recibe indicando si es un Fail o un SoftFail
Por ejemplo podemos observar el registro TXT del dominio elogia.net :
- elogia.net text = «v=spf1 include:_spf.google.com include:spf.mittum.com ip4:149.202.247.113/28 ~all»
En este caso, tenemos la versión 1 de Sender Policy Framework. En ellos tenemos como include dos dominios: _spf.google.com y spf.mittum.com. Estos indican qué mails recibidos desde las IPs de esos dominios serán bien recibidas.
Tenemos también un rango de IPs: ip4:149.202.247.113/28 y por último ~all, para que se nos devuelva un SoftFail para aquellos enviadores que no cumplan con las reglas.
Desglose de casos correctos e incorrectos del Sender Policy Framework
Hasta ahora ya te hemos enseñado lo que es el Sender Policy Framework y en donde se aplica y como se aplica, pero… ¿Dónde podemos ver el resultado de todo este esfuerzo informático?
Cuando recibimos un email, al abrir su cabecera podemos ver el servidor que nos lo envía (Dirección IP) y con que dominio (from). Si revisamos el registro TXT de dicho dominio y la IP, encontraremos en alguno de los rangos definidos de ese email si se están cumpliendo o no las reglas del Sender Policy Framework.
Vamos a ver un ejemplo más concreto, de un caso erróneo o incorrecto:
Delivered-To: javier.burgos@elogia.net
Return-Path: <hola@viko.net>
Received: from p212.pmkt0.com (p212.pmkt0.com. [213.229.189.212])
by mx.google.com with ESMTP id t62si3636266wmf.12.2016.03.04.03.51.21
for <javier.burgos@elogia.net>;
Fri, 04 Mar 2016 03:51:22 -0800 (PST)
En esto último, la IP que envía es la remarcada en negrita (213.229.189.212).
Received-SPF: softfail (google.com: domain of transitioning hola@viko.net does not designate 213.229.189.212 as permitted sender) client-ip=213.229.189.212;
Aquí, «does not designate 213.229.189.212 as permitted sender» nos está dando un error soft fail.
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning hola@viko.net does not designate 213.229.189.212 as permitted sender) smtp.mailfrom=hola@viko.net
De nueva cuenta, el smtp.mailfrom=hola@viko.net nos marca un error soft fail.
Received: from [127.0.0.1] (mailer.ibrands.es [213.229.186.30])
by p212.pmkt0.com (Postfix) with ESMTP id AB8338008A
for <javier.burgos@elogia.net>; Fri, 4 Mar 2016 12:51:21 +0100 (CET)
Subject: =?utf-8?B?RWwgR3J1cG8gVklLTyB0ZSBpbnZpdGEgYWwgZVNob3c=?=
To: javier.burgos@elogia.net
From: =?iso-8859-1?B?VklLTw==?=<hola@viko.net>
Por último, identificamos el from claramente. Todo este compuesto es un ejemplo de un soft fail, ya que El dominio que realiza el envío es viko.net, la IP que envía es 213.229.189.212 y el registro TXT de este dominio (hay una herramienta para ello) desglosa lo siguiente:
- viko.net text = «google-site-verification=XvsWy5C1PWlzKQ_fmlNkPQPTTh2yO2BC0PnPb5FFLMg»
- viko.net text = «v=spf1 include:_spf.google.com ~all»
- viko.net text = «v=spf1 a mx include:spf.mittum.com ~all»
- viko.net text = «google-site-verification=XL48i2HYITZCqw1jcjA825-NImZqp69UNbQYkU8vsOo»
Aquí tenemos ejemplo de un registro TXT con dos entradas Sender Policy Framework, pero cmo la primera termina con un ~all ya no continúa «mirando», y por lo tanto al no estar esta IP definida en la primera línea del registro TXT nos da un soft fail.
Ahora un caso correcto del Sender Policy Framework:
Delivered-To: javier.burgos@elogia.net
Received: by 10.202.225.7 with SMTP id y7csp2282567oig;
Wed, 24 Feb 2016 06:32:07 -0800 (PST)
X-Received: by 10.28.9.71 with SMTP id 68mr23987708wmj.33.1456324327136;
Wed, 24 Feb 2016 06:32:07 -0800 (PST)
Return-Path: <spfcorrecto@elogia.net>
Received: from p215.pmkt0.com (p215.pmkt0.com. [213.229.189.215])
by mx.google.com with ESMTPS id kj7si3903944wjb.87.2016.02.24.06.32.06
for <javier.burgos@elogia.net>
(version=TLS1 cipher=AES128-SHA bits=128/128);
Wed, 24 Feb 2016 06:32:07 -0800 (PST)
Received-SPF: pass (google.com: domain of enric.aparici@elogia.net designates 213.229.189.215 as permitted sender) client-ip=213.229.189.215;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of enric.aparici@elogia.net designates 213.229.189.215 as permitted sender) smtp.mailfrom=spfcorrecto@elogia.net
Subject: =?utf-8?B?Z2VuZXJhbmRvIG1pbmlhdHVyYQ==?=
Reply-To: =?iso-8859-1?B?RW5yaWMgQXBhcmljaQ==?=<spfcorrecto@elogia.net>From: =?iso-8859-1?B?RW5yaWMgQXBhcmljaQ==?=<spfcorrecto@elogia.net>
To: javier.burgos@elogia.net
Si te fijas, hemos marcando en negrita los mismos campos o conceptos que marcamos como incorrectos en el primer caso, pero en todos ellos de designa a la IP o sender como un emisor aceptable.
Esperamos que con estos casos, el concepto del Sender Policy Framework te haya quedado mucho más claro. Comparte tus opiniones y aprendizajes alrededor de este importante concepto en el mundo del email y email marketing.
Imagen: ShutterStock
