Chat +1-888-563-5277 Contact sales

¿Por qué falla DMARC?

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:

Email-Header
Encabezado de correo electrónico

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

GSuite-DKIM

Fallo de DMARC cuando Office365 usa su firma DKIM sin registro SPF autorizado

Office365-DKIM

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

Sendgrid-dmarc-failing

Fallo DMARC causado por correos enviados a través de una cuenta ZenDesk sin una firma DKIM o un dominio único SPF.

Zendesk-DMARC-failing

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.
E.g

Threats-and-Unknowns

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.

Email-Vendors

  • 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.

 

What is an Impersonation Attack?

What is an Impersonation Attack?

An impersonation attack is a type of fraud where an attacker poses as a...

Read More
What is Email Encryption, and How Does it Work?

What is Email Encryption, and How Does it Work?

Over the years, email has become the dominant collaboration tool used by businesses and...

Read More
Advantages of Technology as a Business Strategy

Advantages of Technology as a Business Strategy

As technology evolves, businesses and organizations must continually adapt to an ever-shifting landscape. Everything...

Read More
×