Como configurar de forma correcta SPF y DKIM en DNS para que los mails de tu servidor no acaben en SPAM

Cómo establecer el Marco de Políticas de Remitentes (SPF)

Sobre el registro de SPF

Un registro SPF es un tipo de registro de Servicio de Nombres de Dominio (DNS) que identifica qué servidores de correo están autorizados a enviar correo electrónico en nombre de su dominio. Es tan fácil de añadir como registros MX o A en tu zona DNS.

¿Por qué es importante?

Hoy en día, casi todos los mensajes de correo electrónico abusivos llevan direcciones de remitente falsas. Los spammers envían correo electrónico desde sus servidores de correo pero con tu "dominio" como el correo electrónico de envío. Las víctimas cuyas direcciones están siendo abusadas a menudo sufren las consecuencias, ya que su reputación se ve disminuida y tienen que renunciar a la responsabilidad por el abuso o pierden su tiempo clasificando los mensajes rebotados mal dirigidos.

El propósito de un registro SPF es evitar que los spammers envíen mensajes con "direcciones de origen" falsas en su dominio. Los destinatarios pueden consultar el registro SPF para determinar si un mensaje que pretende ser de su dominio proviene de un servidor de correo autorizado.

Sender Policy Framework (SPF) es una de las partes más fáciles de establecer y configurar de un despliegue DMARC. El SPF se utiliza para especificar qué intercambios de correo electrónico están autorizados para enviar correo electrónico para un determinado nombre de dominio.

En su nivel más básico, el SPF sólo requiere un simple cambio de una línea a un registro de dominio para funcionar.

1. Inicia sesión en el registrador de tu dominio y haz clic en la opción para administrar o configurar los ajustes de DNS
2. Busca y haz clic en la opción "Añadir un nuevo registro" y elige un registro "TXT".
3. En el diálogo de nombre de host, introduce @ o el nombre de tu dominio.

La siguiente parte es la entrada de "valor", que define las opciones de SPF. Hay múltiples opciones que pueden introducirse en un registro SPF que pueden limitar y definir qué intercambios de correo electrónico son capaces de enviar correo electrónico en nombre de un dominio y con qué rigor debe aplicarse la política.

Ejemplo de registro de SPF:

Así, por ejemplo, en el dominio DMARC.site (un dominio de prueba que creamos sólo para este artículo), una política básica de SPF podría tener este aspecto:

"v=spf1 dmarc.site ~all" 

En la política anterior, sólo un intercambio de correo electrónico alojado en dmarc.site permitiría enviar correo electrónico para el dominio. La parte ~all de la política es típicamente la forma correcta de terminar una entrada de DNS SPF y simplemente significa que la política es todo lo que hay y que ningún otro servidor debería estar enviando correo electrónico en nombre de un dominio determinado.

Usar el ~ (tilde) es típicamente preferible en una configuración inicial de SPF a usar un "-" (por ejemplo : -all en lugar de ~all), como el tilde denota un Soft Fail. Es decir, usar el ~ todavía permitirá enviar correo que no cumpla con la política, pero el correo no será identificado como no conforme. Para tener una política estricta (después de la prueba inicial), el '"-" indica un hard fail si la política no se cumple.

En muchos casos, las organizaciones tendrán servidores de correo que están separados del host del dominio (es decir, Google, Office 365 o un reenviador de correo). Entonces, ¿cómo se habilita una política de SPF para definir servidores de correo electrónico autorizados más allá del host de dominio? Ahí es donde entran los elementos "include:".

Por ejemplo, para especificar una política de SPF que permita a los servidores de correo de Google enviar correo electrónico en nombre de un dominio, funcionará la siguiente política sencilla:

"v=spf1 include:_spf.google.com ~all"

Hay muchas otras opciones que pueden ser introducidas para un registro de SPF. Otra configuración común es permitir específicamente que el correo electrónico se envíe sólo desde los mismos servidores de correo electrónico que ya están definidos en el registro MX (intercambio de correo) para la entrada DNS del dominio dado. Un ejemplo:

"v=spf1 mx mx:DMARC.site ~all" 

Una vez que se ha introducido y guardado el registro TXT del DNS para el SPF, es hora de pasar al siguiente paso del proceso DMARC.

Cómo configurar el correo electrónico de identificación de claves de dominio

DKIM (DomainKeys Identified Mail) tiene más o menos la misma utilidad (evitar la suplantación, mediante la autenticación del correo electrónico). Y lo hace con otro registro en nuestros servidores DNS, para que una organización (en este caso Google) certifique que son ellos los que envían en nombre de nuestro dominio.

El correo electrónico identificado por claves de dominio (DKIM) es un elemento algo más complejo y desafiante de implementar que el SPF. Con DKIM, además de una entrada de DNS, las organizaciones también necesitan hacer cambios en los servidores de correo electrónico saliente.

Hay dos elementos en DKIM: un registro DNS que incluye una clave de criptografía pública para ayudar a verificar que un remitente está autorizado a enviar correo electrónico para un dominio determinado, y la clave privada que se utiliza para firmar el correo electrónico saliente.

Añadir una entrada DKIM al DNS de un dominio es el mismo proceso básico que para el registro SPF:

1. Entra en tu registrador de dominios y pulsa la opción de administrar o configurar los ajustes DNS
2. Encontrar y hacer clic en la opción "Añadir un nuevo registro" y elegir un registro "TXT"
3. Para la opción del nombre del host, DKIM requiere lo que se conoce como un "selector", que es básicamente un prefijo (Ejemplo: dmarc._domainkey.dmarc.site)
4. En lugar de introducir una política (como fue el caso de SPF), lo que se necesita con la entrada DKIM es una clave de criptografía pública

Hay múltiples maneras de generar una clave pública que puede ser usada para un registro DKIM. En los sistemas Linux, un enfoque común es usar la herramienta ssh-keygen, mientras que en Windows, PuTTYgen es una opción razonable.

También hay múltiples herramientas en línea que pueden ayudar a generar el par de claves públicas/privadas; una de las más fáciles es DKIM Core Tools.

Ejemplo de DKIM:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRRCnpKK68hawSd8zpsDz77ntGCR0X2mHVvkf0WEOIqaspaG/A5IGxieiWer+wBX8lW2tE4NHTE0PLhHqL0uD2sif2pKoPR3Wr6n/rbiihGYCIzvuY4/U5GigNUGls/QUbCPRyzho30wIDAQAB"

La entrada del DNS es sólo la mitad de la ecuación para DKIM. La otra mitad es conseguir un firmante DKIM en un servidor de correo, que es un proceso que no es tan fácil para muchos sistemas de correo electrónico. La excepción es la Gsuite de Google, que tiene una simple guía de instrucciones para obtener una firma DKIM en su lugar.

Los usuarios de Microsoft Office 365 pueden beneficiarse de la guía detallada de Microsoft sobre cómo implementar la firma DKIM en esa plataforma.

También hay múltiples proveedores que pueden ayudar a habilitar la firma DKIM con diferentes enfoques, que detallaremos en el próximo artículo de esta serie, un esquema de las soluciones de los proveedores.

Luigi Nori

He has been working on the Internet since 1994 (practically a mummy), specializing in Web technologies makes his customers happy by juggling large scale and high availability applications, php and js frameworks, web design, data exchange, security, e-commerce, database and server administration, ethical hacking. He happily lives with @salvietta150x40, in his (little) free time he tries to tame a little wild dwarf with a passion for stars.