En este artículo expondremos algunas de las razones por las cuales la política DMARC puede fallar y lo que debes hacer para solucionar el problema.
Antes de que entremos en detalles, hablaremos un poco acerca del valor de la clave DMARC, el cual es intrínseco a la alineación de dominio.
Alineación DMARC y Razones por la que Falla el Programa
Primero debemos conversar acerca de lo que es la alineación de un dominio. La alienación de dominio es el concepto central de DMARC. Es lo que permite verificar cuando un correo electrónico ha sido enviado por un remitente real. En términos prácticos significa que el chequeo SPF es válido (proceso que está basado en la revisión del remitente o su paso a través de la vía de retorno). También indica que el protocolo DKIM ha autenticado el dominio del remitente y este está alineado con el mensaje del emisor al chequear la etiqueta (d=example.ent)
Puedes ver cómo funciona esta configuración a continuación:
Ahora vamos a conversar acerca de los tipos de fallos que pueden surgir con DMARC y discutiremos las causas que nos pueden llevar a estos escenarios, así como la forma que tenemos de chequear lo que ha sucedido, reconocer el problema y solucionarlo.
Tipos de fallo DMARC
Caso 1: Si no configuras debidamente tu firma DKIM, proveedores de servicios tales como GSuite y Office365 firman los correos enviados desde tu dominio con su propia clave y configuración básica DKIM (por ejemplo: d=domain.gappssmtp.com para Google & d=domain.onmicrosoft.com para Office365) Esta firma digital no es la que corresponde a tu dominio. Esto solo puede lograrse si configuramos correctamente los DNS de nuestros proveedores (tales como GoDaddy, Rackspace o Cloudflare), De esta forma si alguien recibe un correo de “ejemplo.com” pero la firma DKIM es “example.gappssmtp.com” o “example.onmicrosoft.com” DMARC registrara una falla por no estar debidamente alineado.
Puedes ver ejemplos de este caso en específico con capturas de pantallas incluidas en tu tablero de inicio en EasyDMARC
Fallo en DMARC cuando GSuite usa su firma DKIM sin registro SPF autorizado
Fallo de DMARC cuando Office365 usa su firma DKIM sin registro SPF autorizado
Caso 2: cuando usas servicios de terceros tales como MailChimp, SendGrid, HubSpot, o ZenDesk para tus estrategias de marketing y correos transaccionales, debes permitir que estos envíen correos electrónicos de parte de tu dominio.
Esto solo se logra señalando los accesos a los DNS con tus configuraciones SPF y DKIM desde tu proveedor de DNS (servicios tales como GoDaddy, Cloudflare, o Rackspace) para que otorguen las autorizaciones pertinentes y permitan el flujo de correos sin problemas.
Estos proveedores colocarán la firma electrónica con sus dominios en tus correos electrónicos de manera automática y tus receptores generalmente verán mensajes tales como “vía sendgrid.net”, “vía thirdpartyprovider.com”, lo cual conlleva a la falta de alineación de DMARC y al fallo en la aplicación del chequeo.
A continuación, puedes ver algunos ejemplos de este caso en las siguientes capturas de pantallas obtenidas de una consola EasyDMARC:
Fallo DMARC causado por correos enviados a través de una cuenta SendGrid sin una firma DKIM o un dominio único SPF
Fallo DMARC causado por correos enviados a través de una cuenta ZenDesk sin una firma DKIM o un dominio único SPF.
Caso 3: Entidades remitentes alteran el cuerpo de tu mensaje y los encabezados, conllevado a un fallo DKIM. Puedes leer más sobre el comportamiento de envíos de los protocolos SPF/DKIM/DMARC en este artículo.
Caso 4: Eres blando de un cambio de identidad. Esto significa que criminales cibernéticos están enviando correos haciéndose pasar por tu dominio. El origen de todas estas fuentes no son autorizadas por lo que las autenticaciones SPF y DKIM no les afectan, lo cual conlleva por default al fallo de DMARC. Esto queda evidenciado en la pestaña señalando una “amenaza desconocida” en tu tablero EasyDMARC.
Ejemplo:
Proceso de investigación
Ya que has empezado a entender DMARC y estás recibiendo reportes en tu tablero EasyDMARC, probablemente estés pensando “¿Y qué hago ahora? Probablemente también estés considerando como fortalecer tus políticas DMARC para que funcionen sin rechazar correos de fuentes legítimas.
Vamos a cubrir este proceso con una serie de pasos muy sencillos que te facilitarán esta labor:
- Paso 1: Activa el modo de monitoreo en tu tablero DMARC (p=none)
- Paso 2: Analiza el ecosistema de tu sistema de correo electrónico por tres o cuatro semanas
- Paso 3: detecta todas las fuentes legítimas y autenticadas con SPF y DKIM
En nuestro paquete Plus & Business, te ofrecemos la opción de identificar proveedores de servicios de correos electrónicos y te guiamos con todos los pasos de configuración para cada uno de ellos.
- Paso 4: Asegúrate de que has autenticado apropiadamente tus servidores legítimos con SPF y DKIM para que el protocolo DMARC esté debidamente alineado y cumpliendo sus funciones.
- Paso 5: Refuerza tu política DMARC configurándola a los niveles más altos de forma gradual para que los correos no deseados sean rechazados o enviados a cuarentena.
Puedes aprender mucho más sobre DMARC en DMARC RFC.