Las claves de dominio para la identificación de correos o “DomainKeys Identified Mail” (DKIM) son un método de autenticación de correos electrónicos diseñado para detectar remitentes falsos en tu flujo de correos.
Las claves DKIM permiten a tus destinatarios verificar el origen de los mensajes y asegurarse que estos están alineados con un dominio específico autorizado por el propietario de dicha página, este proceso se lleva a cabo a través de una firma digital vinculada al nombre del dominio en cada mensaje de correo electrónico saliente.
El sistema receptor verifica esta firma haciendo una búsqueda de la clave pública del remitente que se publica en el DNS. Como puedes suponer, una firma válida también garantiza que partes del mensaje de correo, tales como los archivos adjuntos, no se han modificado desde el momento que el correo recibe la firma. Las firmas DKIM no son visibles para los destinatarios, únicamente lo son para la infraestructura de correo que recibe el mensaje, los remitentes o el servicio que maneja el flujo de correos de este se encarga de verificarlos y colocarlos a cada mensaje que se envía de acuerdo a las especificaciones DKIM definidas en RFC 6376.
DKIM permite que el servidor del destinatario verifique que el mensaje que esté recibiendo está siendo enviado por un remitente genuino de parte del dominio asociado y que el contenido del mensaje original no fue alterado durante el tránsito de este.
¿En qué se diferencia SPF de DKIM?
Las claves DKIM permiten que los servidores del destinatario verifiquen la autenticidad del contenido del mensaje y su asociación con el dominio de donde este se envía, al buscar la cadena DKIM pública que se asocia con el sistema de envío particular de ese proveedor de correos, el registro SPF permite verificar si el correo recibido proviene de una fuente autorizada (a través de algo básico como una dirección IP), la cual es definida por el remitente mediante la publicación de listas con «fuentes de envío» autorizadas en su DNS.
¿Cuál es la ventaja de usar DKIM sobre SPF?
- En la mayoría de los casos, la clave DKIM (o el resultado de la verificación previa) se mantiene durante el reenvío automático de correo electrónico, lo cual permite que el servidor del destinatario se asegure de que el mensaje de correo recibido es genuino (aunque existen algunas excepciones, que se mencionan en los siguiente punto a continuación), mientras que el registro SPF siempre se interrumpe cuando el mensaje es reenviado (con la excepción más obvia, que sería cuando se lleva acabo un reenvío automático entre destinatarios dentro del mismo dominio).
- Los mensajes de reenvío automático usan 2 métodos:
- Algunos ESP (como Outlook/Hotmail, iCloud, o MailRu) conservan la dirección original smtp.mailfrom como la ruta de retorno, por lo que los resultados de la verificación y autenticación del registro SPF muestran alineación del dominio pero fallan el chequeo, ya que el registro SPF del dominio smtp.mailfrom no abarca la dirección IP del servidor de reenvío.
- Otros ESPs como Gmail/G Suite, O365, Yahoo, o Yandex Mail reescriben la dirección smtp.mailfrom que se usa como ruta de retorno con tu dominio, lo que trae como consecuencia que los resultados de la autenticación SPF se vea desalineada con este, pero como el mensaje llega de igual forma, entonces el registro SPF del dominio smtp.mailfrom queda reescrito e incluye la IP del servidor que maneja el reenvío.
Por lo tanto, en ambos casos, la verificación SPF falla, ya que el requisito de la alineación del encabezado con el dominio smtp.mailfrom y su validación del registro SPF nunca se cumplen.
¿Cuándo puede fallar la verificación DKIM?
La verificación DKIM falla cuando no pasan las verificaciones de autenticación DKIM; estas son algunas de las razones de la falla de verificación:
- El dominio de la firma DKIM y el dominio del remitente (o encabezado “from”) no se alinean
- El registro de la clave pública DKIM, que está publicado en el DNS, es incorrecto o no se ha generado uno en absoluto
- El DNS del dominio del remitente no está disponible al hacer búsquedas, situación que es bastante usual para los proveedores de hosting con pobre funcionamiento
- La longitud de la clave DKIM, usada para firmar, es demasiado corta; ten presente que en la actualidad se admiten claves 1024 y 2048 bits, por lo que si tu proveedor de hosting de correo web firma tus mensajes de correo con una clave DKIM de menor longitud, la verificación de la firma DKIM fallará estrepitosamente.
- El cuerpo del mensaje fue modificado durante el reenvío automático.
Vamos a profundizar en este último caso.
Por ejemplo, cuando el destinatario aplica sus sistemas de reenvío, este agrega un texto de pie de página certificando que el mensaje de correo fue recibido y es reenviado automáticamente, lo cual altera el contenido del mensaje original, ya que compromete la integridad del mensaje. El resultado será entonces que el servidor del destinatario no podrá verificar la firma DKIM, incluso si esta viene incluida en el encabezado del mensaje recibido, se leerá como “dkim=neutral (body hash did not verify)”. A continuación, te mostramos un extracto del encabezado del mensaje con los servicios de Gmail.
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) [email protected] header.s=google header.b=QR1SAS6X;
arc=pass (i=2 spf=pass spfdomain=company.com dkim=pass dkdomain=company.com dmarc=pass fromdomain=company.com);
spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)
smtp.mailfrom=”[email protected]”;
dmarc=fail (p=REJECT sp=REJECT dis=NONE arc=pass) header.from=company.com
¿Es posible prevenir el fallo de la comprobación DKIM?
Todos los casos que hemos enumerado, a excepción del último, son problemas técnicos que se pueden solventar tomando medidas de prevención
Con respecto al último caso, este representa un reto mayor ya que no es realista evitarlo; no es factible o posible obligar a los destinatarios a que dejen de agregar pies de página normativos, lo cual es una práctica habitual y, en ocasiones obligatoria, especialmente en los entornos corporativos.
¿Qué sucederá con dichos correos reenviados automáticamente, que fallan SPF y DKIM, cuando se aplica la política de «rechazo» de DMARC?
- Hace algunos años atrás, el manejo de correos no autenticados de índole genuina era un verdadero desafío para los servidores de los destinatarios. En la actualidad muchos de los proveedores de correos principales han empezado a aplicar protocolos de cadenas recibidas y autenticadas (ARC, según sus siglas en inglés), desde entonces, la situación ha mejorado.
- ARC es un protocolo que le permite a cada servidor de correo procesar sus flujos de mensajes, e identificar el servidor de correo que origina cada correo previamente, así como su evaluación de autenticación de dichos mensajes en cada paso de la cadena de manejo.
Entonces, cuando Google recibe un correo electrónico que no pasó las verificaciones de alineaciones de SPF y DKIM, ARC verifica en el encabezado del mensaje si el mensaje de correo electrónico pasó verificaciones de alineación SPF y DKIM con otros servidores de correos anteriormente, sobre todo el mensaje ha sido reenviado a través de sistemas Gmail o G Suite; si verifican su pasó, Google degrada la política de «reject» del dominio de envío a “none” o a “quarantine”, por lo que la política de «reject» no se aplica a este tipo de mensajes, como puedes ver en la captura de pantalla a continuación.
¿Por qué veo chequeos DKIM= neutral (el hash del cuerpo no se verificó)?
Cuando falla la verificación del hash en el cuerpo de un mensaje determinado, eso significa que el hash que se ha calculado del cuerpo del mensaje no está alineado con el valor del hash almacenado en la etiqueta «bh=» de la firma DKIM.
Algunos servidores de correo corporativos agregan texto en las líneas de la parte inferior de los correos electrónicos entrantes, antes de que los agentes antispam los analicen; en situaciones como esa, el hash del cuerpo es invalidado.
Los correos de esta fuente fallan la verificación de DMARC, lo cual significa que el mensaje de correo no cumplía las políticas DMARC, y por lo tanto sus registros SPF y DKIM no son válidos. Esto puede significar dos cosas puntualmente:
La fuente falla las comprobaciones DMARC porque DKIM y/o SPF no están configurados correctamente.
La fuente falla las verificaciones DMARC porque alguien envió correos maliciosos a nombre de tu dominio.
Es importante investigar todas las fuentes que aparecen en la sección fallida para identificar aquellas que son válidas y las que son maliciosas; si reconoces una fuente legítima, puedes profundizar tu data y asegurar una debida configuración y alineación SPF y DKIM apropiada. Si no reconoces una fuente, es necesario que la investigues, ya que podría tratarse de alguien suplantando la identidad de tu dominio para enviar correos maliciosos a nombre de tu empresa.
Razones que pueden causar DKIM = neutral (el hash del cuerpo no se verificó)
- Un sistema de reenvío, un servicio de host inteligente u otro agente de filtrado modificó el cuerpo del correo electrónico
- El firmante no calcula debidamente el valor de la firma
- Alguien falsificó el mensaje de correo y lo firmó sin tener la clave privada correcta.
- La clave pública especificada en el encabezado DKIM es incorrecta
- La clave pública del remitente en tu DNS es incorrecta
Estos son los pasos que puedes seguir para investigar la fuente:
- ¿Reconoces la fuente como socio de tu empresa?
- Busca en Google el tipo de fuente.
- ¿La fuente aparece en las listas negras de RBL?
- Consulte los informes forenses para analizar qué tipo de correos envía la fuente.
- Si la fuente es válida, es necesario que configures DMARC correctamente.
- Ponte en contacto con la fuente tan pronto como te sea posible.
DKIM falla en los informes
Al igual que los registros SPF, DKIM es un aspecto de gran importancia para el funcionamiento de DMARC, ya que cuando la alineación de DKIM falla, o cuando el valor d= en el encabezado no coincide con el valor d= en la firma DKIM, esto afecta negativamente la capacidad de entrega, dado que los proveedores de correos pueden enviar el mensaje directamente al buzón de spam o bloquearlo por completo.
Comprobar el registro DKIM
Error: Múltiples firmas DKIM
Los permisos para los specs de tus mensajes de correo permiten que tus mensajes tengan dos firmas DKIM. La primera firma tiene un valor d= que coincide con el encabezado del dominio del correo, mientras que la segunda tiene un valor d= correspondiente a un dominio que es propiedad del remitente externo.
Vale recordar que para que un mensaje pase la alineación DKIM, el valor d= en la firma debe coincidir con el valor d= en la dirección de origen incluida en el encabezado, ya que al profundizar en el resultado de cada proveedor de buzones de correo, podemos ver que estos informan tanto la aprobación de DKIM como su debida usando el valor d= en la primera firma, el cual a su vez coincide con el dominio d= en el encabezado para verificar la alineación; gracias a esta coincidencia, los proveedores de correos pueden enviar mayor volúmenes de resultados positivos.
El culpable puede ser el valor d= en la firma, ya que no coincide con la dirección de origen del encabezado.
Solución: deshacerse de la segunda firma DKIM
Un remitente crea DKIM al «firmar» el correo de forma digital. Dicha “firma” se encuentra en el encabezado del mensaje. El agente de transferencia de correo (MTA, según sus siglas en inglés) genera la firma usando un algoritmo aplicado al contenido de los campos firmados; este algoritmo crea una cadena de caracteres única o un «valor hash».
Cuando el MTA genera la firma, el dominio almacena la clave pública usada para generarla en cada envío, después de recibir el correo electrónico, el MTA del destinatario puede seguir verificando la firma DKIM y recuperando la clave pública del firmante a través del DNS. El MTA del destinatario usa esa clave para descifrar el valor hash en el encabezado del mensaje de correo y simultáneamente recalcula el valor hash para el mensaje recibido. Si ambas claves coinciden, entonces el correo no se ha alterado, lo que brinda a los usuarios cierta seguridad al saber que el correo se originó en el dominio real y que nada lo ha modificado desde su punto de origen.
Cuando se envían grandes cantidades de mensajes de marketing al día, es inevitable que un porcentaje minúsculo falle DMARC. Algunos de estos mensajes fallan porque los sistemas que los reenvían alteran sus firmas DKIM y, por lo tanto, fallan DMARC en su destino final.
Aunque el porcentaje de fallas es bajo (0,1 % o menos), el volumen del flujo de correo que maneja es de millones o decenas de millones de mensajes por día, lo cual equivale a miles de fallas y esquivar ese pequeño porcentaje es extremadamente desafiante y demanda mucho tiempo.
¿DKIM filtra el correo electrónico?
No, no lo hace. Pero la información que proporciona ayuda a los filtros que configura el dominio receptor; por ejemplo, si el correo viene de un dominio de confianza y se puede verificar con éxito a través de DKIM, es posible que reduzca su puntuación de spam. Si no se puede verificar la firma DKIM del correo, ya sea porque el correo es falso o por algún otro motivo, este mensaje puede marcarse como correo spam y enviarse a cuarentena o agregarle una etiqueta de correo no deseado en la línea de asunto con el fin de advertir a los destinatarios que el correo es sospechoso.
Como propietario de dominio, es importante comprender que tu no controlas lo que se incluye en el informe de fallos generado por DMARC; eso depende del destinatario. Si el informe es un falso positivo, como por ejemplo un correo que falló DMARC que no debería haberlo hecho, eso puede significar que se puede incluir información «real» en el informe de fallo, lo cual hace de este una herramienta única para filtrar información confidencial corporativa o relacionada a tus clientes.