Dev Life
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.
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=spf1indica la versión del protocolo SPF que se está utilizando. Todos los registros SPF deben comenzar por esta etiqueta.include:mailgun.orgespecifica que el dominiomailgun.orgtiene autorización para enviar emails en nombre de tu dominio. Cuando el servidor de correo electrónico receptor recibe un email demailgun.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, comoinclude:mailgun.org include:google.com.~allespecifica 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:

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:
| Componente | Propósito | Valor de ejemplo |
|---|---|---|
| v | Versión de DKIM | v=1 |
| a | Algoritmo de firma | rsa-sha256 |
| c | Método de canonicalización | relaxed |
| d | Dominio de firma | example |
| s | Selector para la búsqueda de clave pública DNS | dkim |
| t | Marca de tiempo | 1672618838 |
| h | Encabezados incluidos en la firma | from:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references |
| bh | Hash del cuerpo | RKkrHxZminSEI0 |
| b | Firma criptográfica | lndiW4xUpmGq |
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=DKIM1especifica la versión de DKIM.k=rsadefine 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.
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"
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:
| Componente | Propósito | Valor(es) de ejemplo |
|---|---|---|
| v | Versión de DMARC | En la actualidad es siempre DMARC1 |
| p | Política aplicable a los emails infractores | Los valores posibles son none, quarantine o reject |
| rua | URI de informes para los informes agregados (direcciones de email a las que se envían los informes) | mailto |
| ruf | URI de informes para los informes forenses (direcciones de email a las que se envían los informes detallados) | mailto |
| adkim | Modo de alineación de DKIM | r para relajado, s para estricto |
| aspf | Modo de alineación de SPF | r para relajado, s para estricto |
| pct | Porcentaje de emails sujetos a la política DMARC | 0–100 |
| fo | Opciones de informes forenses | 0 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ónfrom:. - Relajada
(adkim=r):el dominio de la firma DKIM debe compartir el mismo dominio organizativo que el dominio de la direcciónfrom:. Esto significa que los subdominios están permitidos.
- Estricta
- Alineación de SPF:
- Estricta
(aspf=s):el dominio de la rutaReturn-Pathde SPF debe coincidir exactamente con ladirección from:. - Relajada
(aspf=r):el dominio de la rutaReturn-Pathde SPF debe compartir el mismo dominio organizativo que el dominio de la direcciónfrom:. Se permiten los subdominios.
- Estricta
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:

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.