Por qué es importante DMARC en una estrategia de e-mail

DMARC (o Autenticación de mensajes, informes y conformidad basada en dominios, por sus siglas en inglés), es un mecanismo de autenticación de correos electrónicos relativamente joven que permite a los remitentes garantizar a sus destinatarios que los mensajes que han recibido fueron originados por su organización. Fue establecido mediante el RFC7489 y publicado por primera vez en Marzo de 2012.

Si bien DMARC depende de los mecanismos SPF y DKIM, existen grandes diferencias entre ellos. Mientras que SPF y DKIM están enfocados en lo que conocemos como “SMTP MAIL-FROM” (también llamado envelope-from o 5321.MailFrom, quien especifica la dirección para devolución de mensajes al remitente), DMARC verifica que el dominio del 5321.MailFrom y el de 5322.From (la dirección de correo que vemos en el campo “DE“) se encuentren alineados.

Pongámoslo en un ejemplo:

Mail-From: [email protected]

De: “Frank” <[email protected]>

Para: “Andrew” <[email protected]>

Asunto: Vencimiento de nombre de dominio – Acción requerida

Si el dominio dominiofalso.com tiene correctamente configurado su registro SPF, el servidor de correo de example.com lo tratará como un mensaje “sano” y pasará la prueba de seguridad. Dado que el cliente de correo de Andrew solo le mostrará la dirección en el campo “From“, Andrew creerá que el mensaje proviene de un origen seguro.

Sin embargo, si miempresa.com tuviese configurado el registro _dmarc.miempresa.com con la política de rechazo (p=reject) en su zona DNS, el mensaje enviado a Andrew sería rechazado por la organización de destino.

En resumen, los dominios del 5321.MailFrom y del 5322.From deben estar alineados y pasar tanto la prueba SPF como la DKIM. De lo contrario, el mensaje no pasará la prueba DMARC.

DMARC tiene como principal objetivo prevenir la suplantación de identidad (conocida como “spoofing“), pero también permite que las campañas de e-mail marketing reduzcan su tasa de rebote/rechazo. Para que un mensaje sea validado por DMARC, debe haber superado primero las pruebas de SPF y de DKIM respectivamente. Si alguna de estas pruebas falla, el mensaje no podrá ser validado por DMARC.

Si las pruebas SPF y DKIM son superadas y el registro DNS DMARC del dominio de origen está configurado, el servidor de correo de destino evaluará el mensaje y tomará una acción dependiendo de la configuración que el remitente haya elegido. Existen tres acciones/políticas posibles:

  • None: Permite monitorear los mensajes recibidos. Se utiliza habitualmente durante la etapa de implementación de DMARC para recibir informes de los destinatarios y poder evaluar la siguiente etapa sin interferir con la entrega de mensajes que no pasen la prueba.
  • Quarantine: Permite poner los mensajes en cuarentena cuando no pasen la prueba DMARC (la acción final queda en manos del destinatario, pero normalmente estos mensajes son enviados a la carpeta SPAM).
  • Reject: Esta acción le ordena a los servidores de correo de destino que rechacen los mensajes que no hayan superado la prueba DMARC.

Estas políticas deben ser combinadas con otras etiquetas en el registro DNS del dominio de origen, como la dirección de correo electrónico a la que las organizaciones participantes enviarán periódicamente informes en los que indicará cuántos mensajes superaron la prueba DMARC y cuántos no.

Un registro DNS DMARC debe utilizar el prefijo _dmarc seguido del nombre de dominio:

Tipo de registro: TXT

Registro: _dmarc.pablofain.com

Información: v=DMARC1; p=reject;rua=mailto:[email protected];ruf:[email protected]

Las etiquetas de configuración más utilizadas son las siguientes:

  • v= La versión de DMARC que se está utilizando.
  • p= La acción o política que debe tomar el destinatario con el mensaje. Como explicamos anteriormente, puede ser none, quarantine reject.
  • sp= La acción o política que debe tomar el destinatario con el mensaje cuando provenga de un subdominio del dominio principal. En caso de no estar presente, se tomará la misma acción que tenga especificada el parámetro “p“.
  • adkim = En modo estricto (adkim=s) el dominio del remitente (5322.From) debe corresponderse con el d=x del encabezado de DKIM. En modo relajado (adkim=r) cualquier subdominio de d=x también será aceptado.
    Por ejemplo, si adkim=s, d=example.org y el mensaje proviene de [email protected], éste será aceptado. Sin embargo, si el mensaje proviene de [email protected] será rechazado. Si no se especifica esta etiqueta, se considerará adkim=r.

    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=pablofain.com
    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pablofain.com; s=selector1; h=From:Date:Subject:Message-ID:Content-
  • aspf: En modo relajado (aspf=r), el dominio del 5321.MailFrom  y el dominio del 5322.From deben coincidir o al menos compartir el TLD. En modo estricto (aspf=s), solo se aceptarán mensajes en los que haya una coincidencia exacta.
    Por ejemplo, si el mensaje pasa la prueba SPF con un 5321.MailFrom bounces.example.org y un 5322.From [email protected], el dominio del 5321.MailFrom y el dominio del 5322.From se considerarán “alineados” en modo relajado, pero no en modo estricto. Si no se especifica esta etiqueta, se considerará aspf=r.
  • pct= El porcentaje de mensajes sobre los que se aplicará la acción o política. En caso de no estar presente, se aplicará la acción al 100% de los mensajes.
  • rua= La dirección a la que se enviarán los reportes de las pruebas DMARC.
  • ruf = La dirección a la que se enviarán los reportes forenses (e-mails que fallaron la prueba DMARC).
  • ri = El intervalo (entero, en segundos) en el que se espera que el destinatario envíe los reportes. Por defecto (etiqueta no presente) se consideran 86400 segundos (1 día). Los destinatarios que envíen reportes DMARC están obligados a hacerlo con intervalos no menores a un día y deberían poder hacerlo hora tras hora, pero no es obligatorio.

Reportes

Tanto los reportes agregados (rua) como los forenses (ruf) se pueden enviar a direcciones de e-mail dentro del mismo dominio que tiene la política DMARC (por ejemplo [email protected]) o a direcciones en otro dominio (por ejemplo [email protected]). Para este último caso, el dominio de destino debe tener configurado un registro DNS adicional, de la siguiente manera:

Tipo de registro: TXT

Registro: example.org._report._dmarc.destinationdomain.com

Información: “v=DMARC1”

El siguiente es un ejemplo del registro DNS de MXToolbox para mi dominio:

id 32329
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
pablofain.com._report._dmarc.mxtoolbox.dmarc-report.com. IN TXT
;ANSWER
pablofain.com._report._dmarc.mxtoolbox.dmarc-report.com. 299 IN TXT "v=DMARC1"
;AUTHORITY
;ADDITIONAL

Toda la documentación sobre este proceso, denominado external reporting, se encuentra disponible aquí.

Interpretar los reportes agregados de DMARC puede ser un verdadero dolor de cabeza. Report URI se encarga de todo el trabajo sucio. Una cuenta gratuita permite el procesamiento de hasta 10.000 reportes al mes, incluyendo DMARC, CSP, HPKP, entre otros.

Para insertar los reportes en Report URI es necesario que la etiqueta rua de nuestro registro DNS contenga la dirección de email [subdominio]@dmarc.report-uri.com. El subdominio de la cuenta de Report URI lo pueden obtener desde el asistente de configuración.

Por ejemplo, para el dominio pablofain.com el registro DMARC quedaría de la siguiente manera:

Tipo de registro: TXT

Registro: _dmarc.pablofain.com

Información: v=DMARC1; p=reject; rua=mailto:[email protected]ruf:[email protected]”; adkim=s; aspf=r

Y así se ve un reporte en Report URI.

Verificación

Una vez configurado el registro DMARC, les recomiendo hacer dos pruebas bien sencillas. Para la primer prueba vamos a enviar un mensaje a una dirección en Gmail. Tan pronto el mensaje llegue a destino, vamos a inspeccionar los encabezados en busca de los resultados de las pruebas de autenticación.

Si todo salió bien, deberíamos ver SPF, DKIM y DMARC con la leyenda “PASS”.

La segunda prueba consiste en enviar un mensaje a la dirección temporal que nos proporcione el sitio mail-tester.com. El sitio realizará diversas verificaciones, no solo en los encabezados sino también en el cuerpo del mensaje, y nos dará un puntaje general.

Pero la sección que más nos interesa es la de los resultados de las pruebas de autenticación.

Si hay alguna advertencia en SPF, DKIM y/o DMARC, este es el momento para corregirlas. El sitio dmarcian.com ofrece un asistente de configuración y una herramienta de inspección para verificar la implementación de los registros DMARC.

Comentarios finales

Una recomendación importante para quienes deseen implementar este mecanismo es que comiencen utilizando una política de monitoreo (p=none), lo que les permitirá recibir feedback y evaluar las acciones a tomar sin afectar el flujo de correo electrónico. Luego podrían continuar con una política de cuarentena (p=quarantine), definir un porcentaje de aplicabilidad menor al 100% (pct=50) y seguir incrementando la rigurosidad hasta llegar a configurar una política de 100% de rechazo (p=reject;pct=100).

Antes de implementar DMARC les recomiendo también que se hagan las siguientes preguntas:

  • ¿Las direcciones IP de mis servidores de mail están en el/los registros SPF de mi dominio?
  • ¿Las firmas DKIM se corresponden con el dominio del Mail-From de mis mensajes?
  • ¿El dominio del Mail-From coincide con el dominio del “Header” From?

Si la respuesta a alguna de ellas es no, será indispensable volver a evaluar toda la estrategia de correo electrónico.

Las estadísticas están de nuestro lado. La falsificación de correos electrónicos está en aumento y DMARC parece ser el primer paso para una solución definitiva.

PayPal fue pionero en su implementación en el año 2007, en un trabajo conjunto con Yahoo! y Gmail. El resultado fue increiblemente efectivo, y permitió a PayPal reducir la cantidad de mensajes fraudulentos que recibían sus clientes.

Los detalles del proyecto están disponibles en su sitio web oficial, dmarc.org.

¡Hasta la próxima!

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.