Dev Life

Cómo autenticar tu email para mejorar la tasa de entrega

Los protocolos de autenticación de emails como SPF, DKIM y DMARC desempeñan un rol crucial a la hora de proteger tus emails frente al spoofing o suplantación y mejorar la entregabilidad. A continuación te explicamos cómo configurarlos y mantener su funcionamiento.
Imagen para Cómo autenticar tu email para mejorar la tasa de entrega

Al crear aplicaciones que envían emails, como las plataformas de marketing o los sistemas CRM, la base de usuarios necesita tener la certeza de que los mensajes llegarán a su bandeja de entrada. Sin embargo, dada la evolución de las medidas antispam, incluso los emails legítimos pueden enfrentarse a obstáculos.

Los protocolos de autenticación de emails como SPF, DKIM y DMARC verifican la identidad del remitente, evitan el spoofing o suplantación y contribuyen a forjar una buena reputación como remitente. Este artículo explica cómo funcionan estos protocolos, cómo configurarlos y cómo confirmar que se han establecido correctamente para que tus emails se entreguen como es debido.

Por qué es importante la entregabilidad del email

Si tu aplicación ofrece la función de email, debes asegurarte de que los mensajes realmente se entreguen. Una mala configuración de la autenticación no debería hacer creer a la base de usuarios que los mensajes se han enviado cuando en realidad no es así.

Autenticación y los problemas de configuración pueden resultar en altas tasas de rebote, quejas por spam y direcciones IP incluidas en listas de bloqueo. También te expone a ataques de phishing y spoofing o suplantación de emails, lo cual puede afectar a tu reputación como remitente y a la estrategia de seguridad de tu organización.

Los problemas de entregabilidad también pueden consumir el tiempo del equipo de desarrollo y afectar a la productividad. Imagina aquellos casos en los que los problemas de entrega intermitentes se derivan desde asistencia al cliente hasta el equipo de desarrollo. El equipo de desarrollo debe interrumpir sus tareas para averiguar qué ha sucedido con los emails afectados, ya sea que hayan rebotado o se hayan enfrentado a otros problemas de entrega. Diagnosticar este tipo de incidencias requiere mucho tiempo y puede acabar con la productividad si ocurren con frecuencia.

Afortunadamente, ninguno de estos problemas es nuevo y existen soluciones a tu alcance para mejorar la entregabilidad de tus emails. Los protocolos de autenticación de emails (incluidos SPF, DKIM y DMARC) se pueden utilizar para mitigar estos problemas. Además, si se emplean en conjunto, tu aplicación de envío de emails estará en las mejores condiciones para lograr una entrega de emails fiable y de confianza.

Para obtener una visión más completa de los retos que supone la entrega de emails, asegúrate de consultar el informe sobre el estado de la entregabilidad del email.

Autenticación de tu email para conseguir mejores tasas de entrega

SPF es un mecanismo que permite definir registros DNS encargados de rastrear qué servidores están autorizados a enviar emails en nombre de tu dominio. Sin registros SPF, cualquiera podría enviar emails con spoofing o suplantación fingiendo que provienen de tu dominio sin que hubiera forma alguna de verificar su procedencia. Del mismo modo, una mala configuración de los registros SPF puede ser problemática: podrías enviar un email legítimo desde tu propio dominio, pero si los registros SPF no están configurados para incluir el servidor de envío como un origen válido, es probable que el email se marque como spam o sea rechazado.

Configuración de SPF

Para comprobar si tu dominio ya tiene registros SPF, puedes usar una herramienta como MxToolbox. O bien, si prefieres usar el terminal, puedes utilizar el comando dig de la siguiente manera:

$ dig +short TXT yourdomain.com | grep spf

Si te falta un registro SPF, no verás ningún resultado. Sin embargo, si ya dispones de uno, deberías ver algo parecido a esto:

v=spf1 include:mailgun.org ~all

Este registro consta de tres componentes clave:

  • v=spf1 indica la versión del protocolo SPF que se está utilizando. Todos los registros SPF deben comenzar por esta etiqueta.
  • include:mailgun.org especifica que el dominio mailgun.org tiene autorización para enviar emails en nombre de tu dominio. Cuando el servidor de correo electrónico receptor recibe un email de mailgun.org, busca un registro SPF que incluya esto para validar el servidor de envío. Ten en cuenta que aquí puedes incluir varios dominios si lo deseas, como include:mailgun.org include:google.com.
  • ~all especifica la política aplicable a los emails que no cumplen las reglas SPF. En este caso, ~ indica un “soft fail” o fallo leve, en el que los emails que no cumplen la política deben aceptarse, pero marcarse como sospechosos en lugar de rechazarse de pleno. Como alternativa, puedes usar -all para especificar un “hard fail” o fallo grave en el caso de aquellos emails que no cumplan la política.

Creación de un registro SPF

Ahora que comprendes los componentes de un registro SPF, crear un registro para tu dominio es simplemente cuestión de añadir un nuevo registro DNS TXT.

Si no tienes la certeza de cómo hacerlo, el centro de ayuda de Mailgun cuenta con guías para los siguientes proveedores de DNS:

Si ya tienes un registro SPF y necesitas agregar un dominio nuevo, ten en cuenta que no puedes añadir varios registros SPF para un mismo dominio. En su lugar, debes modificar tu registro existente y añadirle un valor nuevo. Por ejemplo, si tu registro SPF actual es v=spf1 include:example.com ~all y quieres añadir mailgun.org, tu nuevo registro sería v=spf1 include:example.com include:mailgun.org ~all.

Aunque los registros SPF básicos son bastante fáciles de crear y administrar, pueden suponer un obstáculo para el equipo de desarrollo a la hora de tener que gestionar registros SPF de diversos servicios de envío. Por ejemplo, si cuentas con herramientas de marketing, CRM y servicios de mensajería que envían emails desde un mismo dominio, podrías acabar con registros SPF extensos y complejos.

El protocolo SPF también tiene un límite de 10 búsquedas DNS, por lo que solo se ejecutarán las 10 primeras búsquedas de tu registro SPF. Si el email no coincide en estas 10 búsquedas, se considerará que no está autenticado. Cuando esto sucede, hay varias cosas que puedes probar:

  • Subdominios dedicados: puedes asignar un subdominio dedicado a cada servicio de envío y luego definir registros SPF sencillos en cada subdominio. De esta forma, se facilita la gestión de un gran número de servicios de envío y se sortea el límite de búsquedas, ya que cada registro es mínimo.
  • Herramientas de simplificación de registros SPF: existen herramientas para simplificar o aplanar registros SPF para convertirlos en direcciones o rangos de IP, lo cual puede ayudar a hacer frente al límite de búsquedas. No obstante, esto puede introducir nuevos problemas, de modo que es preferible utilizar subdominios dedicados.

Configuración de DKIM

DKIM es un protocolo de autenticación de emails que permite adjuntar una firma digital a los emails para lograr identificar y prevenir cualquier tipo de manipulación. Cuando un email se firma con DKIM, se lleva a cabo el siguiente flujo:

DKIM signature flow

El propósito principal de DKIM es demostrar que un email no ha sido manipulado y ha llegado con el contenido original enviado por el servidor del remitente que ha firmado. Sin embargo, como efecto secundario, también puede ayudar a reducir las probabilidades de que un email se marque como spam a causa de la heurística de contenido. Esto se debe a que validar los emails de forma coherente con DKIM mejorará tu reputación como remitente con el paso del tiempo, lo cual, en última instancia, reducirá la dependencia que los filtros de spam tienen respecto a los marcadores de spam basados en contenido.

Comprobar si tienes configurado DKIM en un dominio es un poco más complejo que en el caso del SPF porque el registro DNS para DKIM se encuentra en un subdominio especial que utiliza un “selector” arbitrario. Dado que el selector puede ser cualquier cadena alfanumérica, la única forma de determinar cuál hay que comprobar es recurrir al mismo método que utiliza el servidor receptor: examinar el encabezado DKIM-Signature del email. Si observas el contenido en bruto de un email firmado con DKIM y buscas este encabezado, verás algo parecido a esto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=dkim; t=1672618838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:to:to:cc:mime-version:mime-version:content-type:content-type:content-transfer-encoding:content-transfer-encoding:in-reply-to:in-reply-to:references:references; bh=RKkrHxZminSEI0rxtiN3+8wFv6vKCozhmrATLVIZFcw=; b=lndiW4xUpmGqbbIxjiER0FEa67zPqpmW+MqrmMcvuvgd+Gta851Jd+lU4yJ4rmiCHSPfRA gDh+ZsPC8UWZ8U5cfg14uFuvtxUWr6N9Ncy1mntgz7ZNhMIovpknioDIOLYD2wM72mglVP BAeTy2oHVZ0B6tBQqC4/hePtzyF0dnU=

Este encabezado está compuesto por varios componentes:

ComponentePropósitoValor de ejemplo
v Versión de DKIMv=1
aAlgoritmo de firmarsa-sha256
cMétodo de canonicalizaciónrelaxed
dDominio de firmaexample
sSelector para la búsqueda de clave pública DNSdkim
tMarca de tiempo1672618838
hEncabezados incluidos en la firmafrom:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references
bhHash del cuerpoRKk­rH­xZ­minSEI0
bFirma criptográficalnd­iW­4x­UpmGq

El servidor receptor necesita esta información para verificar el email. Vuelve a calcular el hash del email (incluidos los encabezados especificados en el componente h) y recupera la clave pública del registro DNS utilizando el selector presente en el componente s (dkim, en este caso). Cuando el selector se combina con el dominio del remitente, la ubicación completa de la clave DKIM se vería de la siguiente manera: ._domainkey..

Por ejemplo, si tu selector fuera dkim y tu dominio fuera example.com, el registro DNS se ubicaría en dkim._domainkey.example.com. En este caso, podrías ver el registro DNS usando una herramienta en línea o dig:

$ dig +short TXT dkim._domainkey.example.com

Si se encuentra un registro, el resultado será similar a este:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE...

Este registro consta de tres componentes:

  • v=DKIM1 especifica la versión de DKIM.
  • k=rsa define el tipo de clave (RSA es el estándar).
  • p= contiene la clave pública.

Creación de claves DKIM

Al configurar DKIM, es necesario generar un par de claves formado por una clave pública y otra privada. El servidor de envío utiliza la clave privada para firmar los emails y la clave pública se publica como un registro DNS que el servidor receptor usa para validar dichos emails.

Por lo general, si configuras DKIM en un servicio de envío de emails, el propio servicio genera las claves en tu nombre (o te permite utilizar las tuyas, en algunos casos). Por ejemplo, Mailgun proporciona instrucciones paso a paso sobre cómo generar y configurar registros DKIM para un dominio determinado. No obstante, es conveniente comprender el proceso subyacente y, en algunos casos, tal vez prefieras asumir la custodia íntegra del par de claves.

Rotar con frecuencia tus claves DKIM es una de las mejores prácticas para mantener la seguridad de tu programa de email. Aprende a hacerlo en nuestra guía sobre rotación de claves.

En este ejemplo, puedes generar el par de claves mediante una herramienta como openssl. En primer lugar, genera la clave privada de la siguiente manera:

openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048

Este comando crea un archivo denominado private.key que contiene la clave privada RSA. A continuación, puedes utilizar esta clave privada junto con openssl para crear la clave pública:

openssl rsa -pubout -in private.key -out public.key

Una vez que tengas la clave pública, podrás crear su correspondiente registro DNS mediante el selector que elijas (dkim, en este caso). El registro DNS se vería de esta manera:

dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE...etc"

Mailgun dispone de guías del centro de ayuda que orientan sobre cómo añadir registros en los proveedores de DNS más comunes.

Al igual que el SPF, el protocolo DKIM puede entrañar cierta complejidad para tu equipo de desarrollo. Podrían surgir contratiempos, como una mala gestión de las claves privadas y posibles conflictos entre los servicios del remitente.

El nivel de protección que ofrece DKIM depende exclusivamente de la calidad de tus prácticas en la gestión de claves. Una clave de firma vulnerada podría dejarte a merced de agentes maliciosos y de emails con spoofing o suplantación. Por ello, es fundamental mantener unos buenos hábitos de seguridad al tratar con las claves privadas y guardarlas de forma segura en un servicio como AWS Secrets Manager o HashiCorp Vault. Del mismo modo, suele ser conveniente rotar las claves de firma de forma periódica, ya que esto acota el posible impacto que tendría una clave vulnerada. El hecho de que los selectores DKIM sean arbitrarios resulta útil en este caso, dado que puedes empezar a enviar emails con un nuevo selector y una nueva firma de clave privada a la par que retiras el par de claves antiguo de forma progresiva.

Implementación de DMARC

DMARC es otro protocolo de autenticación de emails diseñado para ayudar a mitigar el spoofing o suplantación, el phishing y el spam. DMARC se basa tanto en SPF como en DKIM. En concreto, DMARC se vale de SPF y DKIM para realizar comprobaciones en los emails entrantes y aplicar la política DMARC definida según el resultado de esas validaciones.

DMARC también lleva a cabo una comprobación de alineación de SPF y DKIM, de forma que se garantice que el dominio estipulado por dichos mecanismos también coincida con el dominio que figura en el encabezado from: del email. De este modo, se intensifica aún más la seguridad para evitar el spoofing o suplantación.

Los registros DMARC se publican en un subdominio conocido (_dmarc) de tu dominio de envío. Por ejemplo, si quisieras comprobar el registro DMARC de example.com con dig, tendrías que ejecutar un comando como este:

$ dig +short TXT _dmarc.example.com

Si tuvieras un registro configurado para este dominio, el resultado se vería de esta forma:

"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=s"

Este registro de ejemplo contiene cinco componentes. Sin embargo, un registro DMARC puede incluir un número mayor de posibles componentes:

ComponentePropósitoValor(es) de ejemplo
vVersión de DMARCEn la actualidad es siempre DMARC1
pPolítica aplicable a los emails infractoresLos valores posibles son none, quarantine o reject
ruaURI de informes para los informes agregados (direcciones de email a las que se envían los informes)mailto
rufURI de informes para los informes forenses (direcciones de email a las que se envían los informes detallados)mailto
adkimModo de alineación de DKIMr para relajado, s para estricto
aspfModo de alineación de SPFr para relajado, s para estricto
pctPorcentaje de emails sujetos a la política DMARC0–100
foOpciones de informes forenses0 para “todos los fallos”, 1 para “solo fallo de DKIM”

Un concepto clave para DMARC es la noción de “alineación”. La alineación determina el grado de similitud que los dominios utilizados en SPF y DKIM deben guardar con el dominio del encabezado from: del email. El modo de alineación está controlado por los componentes adkim y aspf del registro DMARC, cuyo significado respectivo es el siguiente:

  • Alineación de DKIM:
    • Estricta (adkim=s): el dominio de la firma DKIM (d=) debe coincidir exactamente con la dirección from:.
    • Relajada (adkim=r): el dominio de la firma DKIM debe compartir el mismo dominio organizativo que el dominio de la dirección from: . Esto significa que los subdominios están permitidos.
  • Alineación de SPF:
    • Estricta (aspf=s): el dominio de la ruta Return-Path de SPF debe coincidir exactamente con la dirección from:.
    • Relajada (aspf=r): el dominio de la ruta Return-Path de SPF debe compartir el mismo dominio organizativo que el dominio de la dirección from:. Se permiten los subdominios.

Partiendo del supuesto de que el SPF, el DKIM y el DMARC estén configurados correctamente al enviar un email, se desencadenará la siguiente serie de acontecimientos:

Assuming SPF, DKIM, and DMARC are all configured correctly when an email is sent, the following sequence of events will take place

Se considera que el protocolo DMARC ha superado la validación si el SPF o bien el DKIM es válido y está alineado. Si ambos son no válidos o no están alineados, se considerará entonces que DMARC ha fallado y pasará a aplicarse la política DMARC.

Esta política está definida por el componente p= y presenta tres modalidades posibles:

  • p=none: no se toma ninguna acción, pero se generan informes.
  • p=quarantine: los emails se procesan como sospechosos y se derivan a la carpeta de spam.
  • p=reject: los emails se rechazan y no llegan a entregarse.

Recuerda que la política DMARC que definas no afecta a tus emails entrantes, sino que indica al resto del mundo qué es lo que debe hacerse con los emails no autenticados que afirman proceder de tu dominio. Esto incluye las etiquetas de informe agregado (rua) y forense (ruf), que especifican adónde deben mandar los servidores receptores los informes de cumplimiento relativos a aquellos emails sin autenticar que afirman provenir de tu dominio.

Es importante establecer estas opciones y cerciorarse de que se supervisan activamente las bandejas de entrada a las que apuntan. Todo ello se debe a que estos informes resultan de un valor inestimable a la hora de comprender el uso que se hace del email en tu dominio, identificar remitentes no autorizados y perfeccionar tus ajustes de autenticación.

Al igual que con el resto de mecanismos de autenticación de emails que ya hemos abordado, configurar tu registro DMARC se resume en crear el correspondiente registro DNS TXT, el cual se vería de manera muy similar a esta:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; aspf=s; adkim=s; pct=100"

Ten presente que, si es la primera vez que configuras la autenticación de emails para un dominio, conviene que te lo tomes con calma. En lugar de empezar por una aplicación estricta de la política (p=reject), tal vez sea preferible recurrir primero a una aplicación gradual de la misma (p=none) e ir supervisando los informes DMARC para garantizar que tus emails superan las validaciones como es debido. De lo contrario, una mala configuración podría afectar a la entregabilidad de tus emails legítimos.

En resumen

Los protocolos de autenticación de emails como SPF, DKIM y DMARC desempeñan un rol fundamental para garantizar la entregabilidad de tus emails y salvaguardar la reputación de tus dominios. Una autenticación de emails bien configurada forja la confianza y mejora tu reputación como remitente, lo que reduce las posibilidades de que tus emails se marquen como spam.

Si no has configurado o no has comprobado recientemente tus ajustes de autenticación de emails, deberías tomarte un tiempo para revisar e implementar estos pasos en tu infraestructura de email. Recuerda supervisar de forma activa tus informes DMARC y probar la entregabilidad de tus emails para cerciorarte de que todo se haya configurado de manera adecuada. Si precisas de un recurso fiable con el que poner a prueba y gestionar la entregabilidad de tu email, Mailgun te lo pone fácil.