Cómo implementar DMARC

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.

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 las pruebas de SPF y DKIM. Si una de las pruebas pasa, el mensaje es entregado.

Si ambas pruebas fallan, el mensaje no pasará la validación de DMARC y la infraestructura de correo del destinatario podrá tomar las acciones especificadas en la política del dominio de origen.

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:postmaster@pablofain.com;ruf:postmaster@pablofain.com”

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, quarantineo 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 alguien@example.org, éste será aceptado. Sin embargo, si el mensaje proviene de alguien@a.example.org será rechazado. Si no se especifica esta etiqueta, se considerará adkim=r.
  • 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 alguien@example.org, 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 dmarc-reports@example.org) o a direcciones en otro dominio (por ejemplo rua@destinationdomain.com). 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:fainpablo@dmarc.report-uri.com; ruf:postmaster@pablofain.com”; 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).

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!

Publicado por Pablo Alejandro Fain

Senior Cloud Engineer at Toyota Argentina. IT professional focused on Azure, Microsoft 365, Identity, and Cybersecurity. You can find me on Twitter as @FainPablo.

Un comentario en “Cómo implementar DMARC

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s