El interés en las políticas DMARC está creciendo de forma progresiva y exponencial, pero la mayoría de las empresas u organizaciones que implementan DMARC no están aprovechando la totalidad de los beneficios que se pueden obtener de estos protocolos de seguridad en la defensa contra ataques de suplantación de identidad; aquí vamos a explicar cómo superar los problemas más comunes con los que hay que lidiar a la hora de implementar DMARC.
A continuación, vamos a describir cuales son los errores más comunes que cometen los propietarios de dominios al configurar registros DMARC y otros estándares básicos usados para la autenticación de correos electrónicos.
Principales errores al momento de implementar DMARC
Muchos de nuestros clientes generalmente piensan que sus dominios están protegidos, pero una breve revisión con nuestras herramientas de verificación, muestra rápidamente que el registro DMARC está configurado usando la etiqueta p=none durante años. La política p=none, junto con las etiquetas rua y ruf, mantienen tu dominio en modo de monitoreo para que DMARC esté al tanto del flujo de mensajes que circula a través de los servidores usados como puertas de enlace, lo cual permite generar el envío de los informes de agregaduría y los mensajes de autenticación fallida al propietario del dominio.
El asunto es que los servidores y las puertas de enlace solo envían informes y continúan entregando todos los correos como de costumbre, incluso si estos no son autenticados. Es por esto que el monitoreo es un paso útil y necesario para lograr la implementación de DMARC, pero no protege tu dominio contra la falsificación.
Cuando se configura la política DMARC de forma predeterminada, esta se aplica al 100 % a todos los correos recibidos, a menos que se especifique un porcentaje mediante la etiqueta “pct.” Desafortunadamente, si el registro DMARC está configurado con la etiqueta p=quarantine y el porcentaje está establecido en menos de 100, significa que seguirás recibiendo mensajes falsos; es importante recordar que no existe tal cosa como un cumplimiento «parcial» de DMARC, por lo que es de sabios asumir que tu dominio es seguro si la etiqueta “pct” está configurada a menos del 100%.
La configuración predeterminada para los subdominios hereda la política principal establecida en este (por ejemplo, p=reject), ya que en el proceso de obtener acceso a DMARC, los propietarios de dominios se enfocan en hacer cumplir la protección a su dominio principal, lo cual pospone el trabajo que se requiere para poner en acción los subdominios, y establecer la política de subdominio sp=none. Todo esto significa que los subdominios (existentes y no existentes) aún pueden ser falsificados por actores maliciosos, lo que hace que sea vital proteger los subdominios de la misma forma con la cual protegemos el dominio principal de la organización.
Problemas al momento de implementar DMARC
Mucha gente comete errores en la sintaxis de sus políticas DMARC, por ejemplo: un registro DMARC que tiene una política p=rechazar, no puede ir colocado después de otra etiqueta, especialmente si hemos usado la etiqueta v=DMARC1. El uso de las etiquetas debe seguir un orden apropiado, de lo contrario puede generar problemas, tales como fallos en la autenticación DMARC o disrupciones en los procesos manejados por las puertas de enlace de correo, provocando saltos en las comprobaciones DMARC; si quieres más información sobre las etiquetas DMARC, haz clic sobre este enlace.
Uno de los aspectos más importantes de la configuración DMARC es que esta proporciona a los propietarios de dominios información sobre el estado de la autenticación de su flujo de mensajes enviados por correo electrónico, incluidas las omisiones y todas las fallas, a través de informes que compilan estos datos. Si no colocas la dirección de correo para la recepción de los informes en la etiqueta rua, no obtendrás estos datos, por lo que no sabrás nada referente a los fallos de autenticación y cualquier posible ataque que pretenda suplantar tu dominio, de ahí que sea esencial incluir una dirección de correo en la etiqueta “rua” para informar a los servidores de recepción a dónde deben enviar los informes de agregaduría DMARC.
Implementación de SPF y DMARC
El registro SPF es un archivo de texto publicado en el DNS que contiene una lista de direcciones IP que incluye todos los remitentes autorizados a enviar mensajes a nombre de tu dominio, así como directivas que señalan las entradas al DNS de forma específica al mismo dominio o que hacen referencia a los registros SPF de dominios externos. Las configuraciones incorrectas de los registros SPF son múltiples, siendo uno de los errores más comunes la creación de un registro que hace que el dominio receptor imponga 10 búsquedas del DNS por cada mensaje recibido.
La búsqueda de DNS básicamente resuelve las directivas indicadas por la etiqueta mx, para la redirección de direcciones IP, por lo cual, si el registro SPF del dominio de envío requiere demasiadas búsquedas de DNS, se crea una carga pesada en el servidor del receptor, por lo tanto, todos los correos recibidos pueden fallar la verificación de autenticación.
Para sortear esta limitación de la especificación SPF, algunos propietarios de dominio aplanan su registro extrayendo y colocando todas las direcciones IP de los servicios de despacho de mensajes aprobados en el registro SPF principal. El registro SPF aplanado especifica de forma explícita una lista de direcciones IP, lo cual introduce un nuevo problema: la necesidad de mantener la integridad de las listas de direcciones IP en todo momento, ya que el servicio de envío de correos que usas, puede agregar o eliminar direcciones IP de envío de tu lado.
DKIM y DMARC
Las claves de identificación de dominio digitales (DKIM) utilizan una clave criptográfica de índole pública y privada para firmar mensajes de correo electrónico, la cual sirve para confirmar que un mensaje determinado proviene del dominio al que está asociada la clave DKIM y que el correo no ha sido modificado durante el tránsito.
Las claves DKIM son largas cadenas de datos que a primera vista lucen aleatorios y que puede confundirse fácilmente en tu DNS; incluso un simple problema al momento de copiar y pegar la estructura de este, puede generar errores que provocan el bloqueo de las claves DKIM en correos de índole legítimo.
Los expertos en seguridad cibernética a nivel mundial recomiendan rotar las claves DKIM al menos una vez cada seis meses, para así evitar que las claves sean robadas o descifradas por piratas informáticos; cabe destacar que muchas empresas y organizaciones no tienen métodos o protocolos para la administración y rotación de claves; algunas de estas incluso usan la misma clave DKIM para cada servicio de correo que usan, por lo que si esta clave se viese comprometida, cada servicio de la compañía queda expuesto ante un ataque.
Por lo tanto, sin SPF y DKIM correctamente configurados, la aplicación correcta de los protocolos DMARC nunca serán consolidados.
DMARC requiere de una apropiada configuración para pasar la verificación de autenticación SPF y DKIM, la alineación del dominio para las coincidencias, debe ser visible desde el encabezado FROM: dirección del mensaje de correo electrónico y 1) la dirección de retorno, la cual debe llevar el campo del encabezado del mensaje y 2) el dominio de la firma DKIM, la cual debe estar incluida en el encabezado del mensaje.
Es necesario configurar estos protocolos básicos de autenticación para el correo electrónico de tu empresa antes de poder proteger tu dominio con DMARC.
Para obtener más información sobre cómo solucionar estos errores comunes, así como más consejos útiles sobre cómo solucionar otros problemas, lee nuestro artículo: Cómo implementar DMARC con EasyDMARC.