Hello Everyone!!

En el próximo post de Obss, vamos a enfocarnos en la seguridad de los correos electrónicos y exploraremos tres tecnologías clave que trabajan juntas para proteger a los usuarios de la recepción de correos electrónicos falsos: SPF, DKIM y DMARC.

Como CIO considero muy importante la implementación de SPF, DKIM y DMARC para proteger la seguridad de tus correos electrónicos.

Estas tecnologías, aunque pueden parecer complejas, son fundamentales para garantizar la autenticidad y la integridad de los correos electrónicos, evitando así ataques de phishing y suplantación de identidad. ¡Estamos emocionados de compartir nuestros conocimientos sobre cómo estas tecnologías pueden ayudar a mejorar la seguridad de tus correos electrónicos!

Que son los protocolos SPF, DKIM y DMARC

Seguro que has escuchado a colegas o en publicaciones técnicas hablar de los protocolos SPF, DKIM o DMARC y que te asegures de tenerlos en orden cuando envíes tus campañas de email marketing. Y mientras buscas sin descanso cómo configurarlos, de pronto te preguntas “Pero, eso del SPF, DKIM y DMARC… ¿qué es?”

Vamos a empezar por el principio. El phishing es una técnica utilizada por los estafadores para obtener información personal. Los phishers envían un correo electrónico haciéndose pasar por una organización de confianza (un banco, Paypal, eBay, Amazon…), con el fin de robarnos datos confidenciales.

En este tipo de suplantación de identidad también la conocemos como spoofing, gracias a esos datos que consiguen, los estafadores pueden, por ejemplo, realizar transferencias bancarias a sus cuentas o conectarse a un sitio para enviar spam.

Pues para evitar que estos phishers se hagan pasar por nosotros utilizando el mismo nombre de dominio, existen los protocolos de autenticación SPF, DKIM y DMARC. En este post, vamos a explicar detenidamente qué son y cómo configurarlos para hacer tus envíos de correos más seguros.

Como ocurre con todo, cuando nos enfrentamos a siglas en inglés, lo más común es que no sepamos ni a qué corresponden. Vamos a echarle un vistazo a cada una.

¿Qué es el SPF?
El Sender Policy Framework, o SPF, es un estándar de autenticación que vincula un nombre de dominio a una dirección de correo electrónico. Consiste en definir cuál es el remitente (o remitentes) autorizado para enviar emails con un dominio determinado.

Así, los clientes de email como Gmail o Outlook y los servidores de correo electrónico pueden comprobar que el email entrante procede de direcciones IP o servidores autorizados por el administrador del dominio del remitente.

Para esto, los servidores DNS comprueban con los registros SPF si la IP del servidor desde el que se envía tiene relación con el dominio.

¿Qué es el DKIM?
El DomainKeys Identified Mail, o DKIM, es un protocolo de autenticación que vincula un nombre de dominio a un mensaje. Habilitar DKIM nos permite utilizar una clave privada en tus emails salientes a modo de firma digital.

El objetivo del protocolo DKIM no es sólo demostrar que el nombre de nuestro dominio no ha sido usurpado, sino también que el mensaje no ha sido alterado durante la transmisión.

¿Qué es DMARC?
El Domain-based Message Authentication, Reporting and Conformance, o DMARC, es un estándar de autenticación que complementa a SPF y DKIM para combatir más eficazmente el phishing y otras prácticas de spamming.

Nos permite como propietarios de dominio indicar a los ISP (proveedores de servicios de internet) y a los clientes de email qué hacer cuando un mensaje firmado de nuestro dominio no está formalmente identificado por un estándar SPF o DKIM.

DMARC fue desarrollado en 2012 por un grupo de trabajo que incluía a grandes empresas tecnológicas y de comunicaciones como Google, Microsoft, Yahoo, AOL, y otras. La idea era crear un estándar que todos en la industria pudieran utilizar para hacer el correo electrónico más seguro y confiable.

¿Por qué deberías utilizar los protocolos SPF, DKIM y DMARC?
La razón es bastante simple: estos son los principales protocolos para verificar la identidad de los remitentes. Esta es una de las formas más efectivas de evitar que los phishers se hagan pasar por un nosotros y suplanten nuestra identidad utilizando el nombre de nuestro dominio.

Pero evitar ataques de phishing no es la única ventaja. De hecho, la implementación de estos protocolos mejora la entregabilidad del email marketing.

Gracias a estos protocolos, nuestros correos podrán ser identificados mejor por los ISP y los clientes de email de tus destinatarios, lo que mejora las posibilidades de que nuestros correo electrónicos lleguen a la bandeja de entrada de nuestros contactos y no a la carpeta de Spam o Correo no deseado.

Además, estos protocolos se han convertido en estándares para el email. Un mensaje enviado sin firma SPF y/o DKIM puede ser considerado sospechoso por las diferentes herramientas de análisis de email.

En el contenido de este post, vamos a explicar el concepto de DMARC, el protocolo, las definiciones, sus aplicaciones prácticas y las implicaciones que surgen al implementarlo.

Además, vamos a analizar en detalle para qué sirve DMARC, destacando sus beneficios y cómo contribuye a que fortalezcamos la seguridad y la autenticación de los correos electrónicos.

Asimismo, examinaremos las repercusiones que se desencadenan al aplicar DMARC, detallando cómo esta medida puede influir en la identificación y prevención de intentos de suplantación de identidad (phishing) y otros ciberataques relacionados con el correo electrónico.

Vamos a presentar ejemplos concretos de situaciones que nos pueden surgir al implementar DMARC y proporcionar información esencial para comprender cómo esta herramienta contribuye a garantizar la integridad y autenticidad de los mensajes electrónicos.

En resumen, con este post ofrecemos una guía completa sobre DMARC, ofreciendo una visión detallada de su propósito, utilidad y las consecuencias prácticas que se derivan de su aplicación.

Introducción a DMARC

Como hemos explicado, DMARC (Domain-based Message Authentication, Reporting & Conformance) es un protocolo de validación de correo electrónico diseñado para proteger los dominios de correo electrónico de la suplantación de identidad y otras formas de abuso en el correo electrónico, como el fraude y el phishing. Su historia se remonta a la colaboración entre varias organizaciones y expertos en seguridad de correo electrónico y se encuentra especificado en el estándar RFC74891.

DMARC tiene dos funciones principales:

• Verificar la autenticidad del correo electrónico.
• Impedir que correos falsos alcancen su destino.

Antes del protocolo DMARC, ya existían los protocolos SPF (Sender Policy Framework) y DKIM (DomainKeys Identified Mail), que son métodos que utilizamos para verificar si los correos electrónicos provienen de fuentes legítimas. Sin embargo, estos métodos tenían limitaciones, especialmente en cómo se trataban los mensajes que fallaban en estas verificaciones.

Por lo tanto, el protocolo DMARC surgió como una solución para llenar los vacíos dejados por SPF y DKIM. Nos permitía a los propietarios de dominios especificar cómo queremos manejar los correos electrónicos que no pasan las verificaciones individuales mediante políticas, además de construir un formato estándar de informes con mensajes informativos que los servidores de recepción de correo nos envían sobre la autenticidad de los correos electrónicos recibidos.

Estos reportes ayudan a los administradores de dominios a entender cómo están siendo tratados los correos electrónicos en el mundo exterior, incluyendo cuántos mensajes pasaron o fallaron las verificaciones de SPF y DKIM, y cómo son manejados de acuerdo con la política DMARC establecida.

Los informes se envían en un formato XML y proporcionan datos detallados que utilizamos para monitorizar y mejorar las medidas de seguridad del correo electrónico, detectar problemas de configuración, combatir el abuso y el fraude y conocer el grado de alineamiento con DMARC.

Cual es la importancia del protocolo DMARC en nuestras organizaciones

El negocio de la ciberdelincuencia ha encontrado en la suplantación de dominios y correos electrónicos una actividad muy lucrativa. A través de técnicas de phishing e ingeniería social, estos grupos ciberdelincuentes pueden obtener acceso a información sensible, manipular eventos políticos, o incluso paralizar infraestructuras críticas.

La responsabilidad de los departamentos de TI y por lo tanto de los CIO / CISO es trabajar para obtener una política de cuarentena al 100% en un tiempo razonable, ya que, entre otros beneficios, nos van a aportar:

• Protección contra la suplantación de identidad en el correo electrónico. Impidiendo que grupos de ciberdelincuentes envíen correos fraudulentos que parecen provenir de dominios legítimos.
• Integridad de la información. Asegurando que la información que hemos enviado por correo electrónico no ha sido alterada.
• Confianza de nuestros clientes y proveedores. Incrementando la confianza en las comunicaciones por correo electrónico.
• Autonomía. En el contexto geopolítico actual, la protección contra campañas de desinformación y ciberataques es más importante que nunca para preservar la integridad y la soberanía.

Consideraciones técnicas previas a la implementación de protocolos DMARC

Qué es y cómo se configura SPF

SPF nos va permitir especificar qué servidores de correo están autorizados para enviar correos electrónicos en nombre de nuestro dominio. Esto lo logramos mediante la publicación de un registro SPF en los DNS del dominio. Los servidores de recepción de correo pueden consultar este registro para verificar si el correo que están recibiendo proviene de un servidor autorizado por el propietario del dominio del remitente.

Ejemplo de configuración SPF

Vamos a suponer que nuestra organización tiene un con dominio “acme.com” y deseamos implementar SPF para protegernos. Estableceremos una política SPF que solo permita enviar correos desde nuestros servidores de correo internos y, opcionalmente, desde un proveedor de servicios de correo que utilizamos. El registro SPF en el DNS de “acme.com” podríamos configurarlo de la siguiente manera:

• v=spf1 ip4:192.168.0.1 include:mailservice.com -all

Donde:

• v=spf1. La versión de SPF que estamos utilizando.
• ip4:192.168.0.1. Los correos electrónicos que enviamos desde la dirección IP 192.168.0.1 son lo que estarán están autorizados.
• include:serviciocorreo.com. Esta directiva incluye la política de SPF de **mailservice.com** en la política actual. Esto significa que cualquier dirección IP autorizada por **mailservice.com** también estará autorizada para enviar correos electrónicos desde el dominio.
• -all: Un mecanismo de fallo que indica que cualquier servidor que no cumpla con los criterios anteriores no estará autorizado para enviar correos desde “acme.com”.

Cuando un servidor de recepción recibe un correo electrónico que afirma ser de “acme.com”, verificará la identidad contra el registro SPF. Si el correo proviene de un servidor no listado o autorizado en el registro SPF, será rechazado o marcado como sospechoso, dependiendo de la configuración del servidor receptor.

En el ejemplo que hemos expuesto, solo hemos tratado los parámetros esenciales: versión, ipv4, include y all. Esto es lo mínimo necesario que debemos configurar para que SPF funcione correctamente, asumiendo que el resto de los valores por defecto serán adecuados para nuestra política. No es común ver el resto de parámetros, pero estos son:

• v. Este siempre es el primer parámetro en un registro SPF y declara la versión de SPF que vamos a estar utilizando. No hay alternativas para este valor; siempre debe ser spf1.
• ip4 e ip6. Con estos parametros vamos a especificar las direcciones IP (en formato IPv4 o IPv6, respectivamente) que autorizamos para enviar correo en nombre de nuestro. No hay un valor por defecto para estos campos y debemos configurarlos explícitamente con las direcciones IP correctas. ipv4 es una etiqueta diferente a ipv6, comúnmente solo se utiliza ipv4 en la actualidad.
• include. Con este parámetro permitimos incluir la política SPF de otro dominio dentro de nuestro registro SPF. Este parámetro nos será útil cuando utilizamos servicios de terceros para enviar correos electrónicos en nombre de nuestro dominio. Al igual que con ip4 e ip6, no hay un valor predeterminado.
• a y mx. Con estos parámetros permitimos que los correos electrónicos sean enviados desde las direcciones IP asociadas a los registros A o MX de nuestro dominio, respectivamente. Si los usamos sin parámetros adicionales, nos referiremos a nuestro propio dominio. No hay valores predeterminados y solo se aplican si se incluyen explícitamente.
• ptr. No se recomienda usarlo debido a problemas de rendimiento y porque no es efectivo como mecanismo de verificación. Con el parámetro ptr verificamos que la dirección IP inversa del remitente coincida con el dominio especificado.
• exists. Con este parámetro permitimos que nuestro dominio especifique una consulta de DNS que, si resuelve, permite que la IP pase. Se usa raramente debido a su complejidad y carga en los servidores de DNS.
• redirect. Con este parámetro permitimos redirigir la evaluación de SPF a otro dominio. Si lo usamos, reemplazamos completamente la política del dominio original por la del dominio al que la redirigimos.
• all. Es un parámetro con el que especificamos cómo deben ser tratados los correos electrónicos que no coinciden con ninguno de los anteriores mecanismos en el registro SPF. Es el final del registro y tiene mucha importancia porque definimos el comportamiento por defecto para las direcciones IP que no están específicamente autorizadas. Este siempre debe aparecer al final del registro DNS para el SPF:
  • +all. Permitimos a cualquier servidor enviar correo en nombre de nuestro dominio (esto desactiva SPF como medida de seguridad y por lo tanto, no es lo recomendado).
  • -all. Indicamos que los correos enviados desde servidores no especificados en el registro SPF deben ser rechazados. (Recomendado)
  • ~all. Es importante si aplicamos una política de “softfail”, en la que sugerimos pero no requerimos que los mensajes sean tratados como spam o rechazo; es útil para la fase de pruebas.
  • ?all. Indicamos una política neutral donde no se da ninguna instrucción sobre cómo tratar los correos que no coinciden con otros mecanismos del registro.

Qué es y cómo se configura DKIM.

DKIM nos va a permitir asociar nuestro dominio con un mensaje de correo electrónico, añadiendo una firma digital a la cabecera del mensaje. Esta firma digital se crea utilizando una clave privada que solo la posee nuestro dominio como remitente y cualquier receptor puede verificar esta firma utilizando la correspondiente clave pública, la cual la tendremos publicada en el DNS en nuestro dominio.

Ejemplo de configuración DKIM

Siguiendo con nuestro ejemplo anterior, queremos implementar DKIM para nuestros correos electrónicos para nuestro dominio “acme.com”. El rol implicado de la organización deberá generar un par de claves criptográficas (una privada y una pública). La clave privada la utilizaremos para firmar digitalmente los correos salientes de nuestro dominio, mientras que la clave pública la publicaremos en un registro DKIM en el DNS de nuestro dominio. Quedaría así:

• dkim._domainkey.acme.com. IN TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC

Donde:

• dkim._domainkey. El prefijo estándar que indica dónde se encuentra la
• clave pública DKIM para el dominio “acme.com”.
• v=DKIM1. La versión de DKIM.
• k=rsa. El tipo de clave criptográfica utilizada, en este caso RSA.
• p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC, la clave pública que vamos a utilizar para verificar las firmas digitales.

Cuando el servidor remoto que recibe un correo electrónico que afirma ser de “acme.com”, verificará la firma en la cabecera del correo utilizando la clave pública. Si la verificación es validada el mensaje realmente proviene de “acme.com” y que no ha sido modificado en tránsito. Si la verificación falla, el correo debe ser tratado como sospechoso.

En el ejemplo que hemos expuesto, solo hemos tratado los parámetros esenciales: versión, tipo de clave, y la clave pública. Esto es lo mínimo necesario que debemos configurar para que DKIM nos funcione de forma satisfactoria. Asumimos que el resto de los parámetros valores por defecto son adecuados para nuestra política de seguridad. No es común ver el resto de parámetros, pero estos son:

• v. Versión del DKIM, por defecto: DKIM1. Este parámetro siempre debe estar presente y configurado para indicar que se trata de un registro DKIM.
• h. Algoritmos de hash permitidos. Generalmente, no lo especificamos y los sistemas asumen los más comunes como sha256.
• k. Tipo de clave, DKIM utiliza rsa por defecto, y es el tipo de clave más comúnmente utilizamos para firmar los correos electrónicos.
• p. Clave pública, este campo debe contener la clave pública que corresponde a nuestra clave privada utilizada para firmar los correos electrónicos.
• s. Ámbito de los correos que la firma pretende cubrir, generalmente, no se especifica y se asume *, lo que significa que la firma es válida para todos los correos del dominio.
• t .Marca de tiempo de la firma, no se usa comúnmente en los registros DKIM, la gestión de la validez temporal la realiza el software que verifica la firma.
• g. Granularidad de la firma. Define a qué usuarios específicos le aplicamos la firma. Por defecto, suele estar configurado para coincidir con cualquier usuario ().
• n. Notas, campo de texto libre para incluir comentarios que el administrador estime convenientes.
• o. Política de firma, indica si todos los correos deben estar firmados (-) o si algunos correos pueden no estarlo (~).
• i. Identidad del usuario que firma el mensaje. Esta permite especificar una dirección de correo electrónico particular en el campo “From:” que la clave se supone que firma.

Qué es y cómo se configura DMARC.

DMARC utiliza las protocolos SPF y DKIM antes mencionadas para verificar que los mensajes de correo electrónico procedentes de un dominio sean auténticos y no hayan sido alterados en tránsito.

Además, nos permite establecer políticas en las que estableceremos cómo deben manejar los servidores receptores los correos que no pasan estas verificaciones. También nos va a proporcionar un sistema de informes que permite al administrador de nuestro dominio recibir retroalimentación sobre el rendimiento de los correos enviados desde nuestro dominio y cómo están siendo procesados bajo las políticas de DMARC.

Ejemplo de DMARC

Seguimos con el ejemplo de nuestra entidad “acme.com” y deseamos implementar DMARC para mejorar la seguridad de nuestro correo electrónico. El rol implicado de la organización de “acme.com” añadirá un registro DMARC al DNS del dominio, que podría verse así:

• v=DMARC1; p=none; rua=mailto:reportes@proveedordmarc.com; ruf=mailto:fallos@proveedordmarc.com; fo=1; adkim=r; aspf=r

Donde:

• v=DMARC1. Versión de DMARC.
• p=none. Es la política de DMARC que pide no realizar ninguna acción en los correos que no pasen las pruebas de SPF y/o DKIM, pero sí generar los reportes.
• rua=mailto:reportes@proveedordmarc.com. Es la dirección de correo electrónico para recibir reportes agregados de autenticación.
• ruf=mailto:fallos@proveedordmarc.com. Es la dirección de correo electrónico para recibir reportes forenses detallados de fallos de autenticación.
• fo=1. Genera reportes de fallo si falla cualquier verificación (SPF o DKIM).
• adkim=r; aspf=r. Configuración relajada para DKIM y SPF respectivamente, indicando que la parte del dominio debe coincidir con el dominio en el mensaje, pero permite ciertas discrepancias.

Al utilizar este registro DMARC, “acme.com” no protegemos la marca de usos indebidos en el correo electrónico por la política seleccionada, pero nos permite recibir información valiosa sobre el rendimiento y la seguridad de nuestras comunicaciones por correo electrónico, lo que nos va a permitir realizar ajustes y mejoras continuas en nuestros protocolos de seguridad para planificar un cambio de política.

En el ejemplo solo hemos tratado los parámetros básicos: versión, política, rua, ruf y fo. Esto es lo mínimo que debemos configurar para que DKIM nos funcione de forma satisfactoria, asumimos que el resto de los parámetros valores por defecto son adecuados para nuestra política de seguridad, pero estos son:

• v. Versión del protocolo DMARC, actualmente DMARC1.
• p. Política para aplicar al correo electrónico que no supere la verificación de DMARC. Puede ser:
  • none: Esta política permite que todos los correos electrónicos alcancen su destino, incluso si fallan en la verificación de DMARC. Se utiliza como una política de monitorización para analizar los reportes de fallo y determinar el nivel de configuración con DMARC.
  • quarantine: Esta política determina que los correos que fallen en la verificación sean marcados como correo no deseado o spam.
  • reject: Esta es la política más estricta, los correos que fallen en la verificación son rechazados impidiendo que lleguen a su destino.
• sp. Política para aplicar al correo electrónico, correspondiente a subdominios, que no superen la verificación de DMARC. Si omitimos este parámetro, se aplicará la política definida en la etiqueta “p” a los subdominios.
• aspf, Este parámetro controla la precisión con la que se comparan los registros del remitente con las firmas SPF, con dos posibles valores:
  • r (relajado) permite coincidencias parciales, como subdominios de un dominio dado.
  • s (estricto) requiere una coincidencia exacta.
• adkim. Este parámetro se refiere a la precisión con la que se comparan los registros del remitente con las firmas DKIM, con dos posibles valores:
  • r (relajado) permite coincidencias parciales, como subdominios de un dominio dado.
  • s (estricto) requiere una coincidencia exacta.
• pct .Este parámetro de porcentaje indica que solo se aplique la política de DMARC a un porcentaje de los correos electrónicos fallidos. “pct=50” indicará a los receptores que apliquen sólo la política al 50% de los correos electrónicos que no superen la verificación DMARC. Si se omite esta parametro, se aplicará al 100% de los correos electrónicos fallidos. La etiqueta pct se diseñó como una forma de aplicar de forma gradual las políticas DMARC para acortar el período de implementación.
• rua. Lista de URL para enviar reportes XML de comentarios agregados. Los reportes RUA son resúmenes agregados que los servidores receptores nos envían para informar sobre el volumen y los resultados de la autenticación de correos electrónicos enviados en su nombre. DMARC requiere una URL o lista de URL y no solo un correo, quedando: “mailto:analizador-dmarc@acme.com”.
• ruf. Lista de URL para enviar reportes forenses. Los reportes RUF son mensajes que los servidores receptores de correo electrónico nos envían para proporcionar información detallada sobre incidentes individuales de fallos en la autenticación de mensajes. Actualmente es un parámetro en desuso por la mayoría de proveedores de correo ya que hay problemas de privacidad en las comunicaciones. DMARC requiere una URL o lista de URL y no solo un correo, quedando: “mailto:analizador-dmarc-forense@aceme.com”.
• rf. Formato para el reporte de fallo. Esto puede ser:
  • afrf (Authentication Failure Reporting Formats)
  • iodef (Incident Object Description Exchange Format).
  • Por defecto, su valor es “afrf”.
• fo. Es el parámetro usado dentro del registro DMARC para especificar las condiciones bajo las cuales los receptores deben generar y enviar reportes de fallos. Este parámetro puede tener múltiples opciones combinadas y los valores permitidos son:
  • 0 para generar informes si tanto DKIM como SPF fallan
  • 1 para generar informes si DKIM o SPF falla
  • d para generar un informe si DKIM falla
  • s para generar un informe si SPF falla
• ri. Es el intervalo entre informes expresado en segundos. Es la frecuencia con la que deseamos recibir informes XML. Se trata de una preferencia, los proveedores deben tener la capacidad de ofrecer un informe diario, pero si el intervalo es menor, se aplica la base del mejor esfuerzo. Por defecto, su valor es “86400”.

Configuración de DMARC

Los mecanismos de seguridad implementados en los protocolos SPF y DKIM son, por si mismos, suficientes para validar que un correo es enviado desde un servidor autorizado, pero no garantizan, en ningún caso, que no estén realizando suplantaciones de identidad. Para evitar esta casuística, el protocolo DMARC, incorpora un nuevo concepto de seguridad llamado Alineamiento del DMARC.

Para poder entender este concepto, es fundamental que comprendamos las diferencias entre las cabeceras Mail From y Header From y la importancia que posee en el proceso de alineación DMARC. El Mail From se utiliza durante el proceso de autenticación (se le aplica el DKIM y SPF) y el Header From se utiliza durante la visualización del correo.

Es decir, un servidor puede autenticarse de forma correcta, pero puede utilizar como remitente una identidad suplantada que será la que aparecerá ante el usuario durante la visualización. Por ello, la alineación de DMARC, es la que evitará que un servidor, autenticado legítimamente, pueda enviar correos utilizando como remitente dominios no autorizados.

En el proceso de alineación DMARC, vamos a examinar tanto el Mail From como el Header From y vamos a tener en cuenta los resultados de las verificaciones de SPF y DKIM. Por lo tanto, realizaremos dos verificaciones de la alineación distintas:

• SPF alineado. Para que se dé una alineación del SPF es necesario que el correo cumpla con la verificación SPF y que el Mail From y el Header From pertenezcan al mismo dominio.
• DKIM alineado. Para que se dé una alineación del DKIM es necesario que el correo cumpla con la verificación DKIM y que el dominio utilizado durante la firma de integridad de DKIM pertenezca al mismo dominio que el usuario de Header From.

Si se cumple uno de ellos consideraremos que un correo electrónico está parcialmente alineado y si cumple los dos consideraremos que está completamente alineado. Únicamente es necesario que se cumpla uno de ellos para que cumpla el DMARC correctamente

Alineamiento relajado y estricto

En el protocolo DMARC, la alineación SPF y DKIM puede ser relajada o estricta. En el modo relajado, se permite una coincidencia aceptando subdominios entre el encabezado Header From y los dominios analizados por SPF y DKIM mientras que, en el modo estricto, se requiere una coincidencia exacta.

En la siguiente tabla podemos observar cuando se cumplen cada tipo de alineamiento dependiendo de los dominios del Header From y Mail From:

Header From	Mail From	Relajado	Estricto
acme.com	acme.com	Ok	Ok
tnt.acme.com	tnt.acme.com	Ok	Ok
acme.com	tnt.acme.com	Ok	No OK
tnt.acme.com	acme.com	Ok	No Ok
tnt.acme.com	usuario.acme.com	Ok	No Ok
acme.com	otrodominio.com	Ok	No Ok

Cómo crear un registro TXT de SPF, DKIM y DMARC

Para crear un registro DNS, incluido un registro DMARC, podemos seguir estos pasos generales que se aplican a la mayoría de los proveedores de servicios de DNS. Aquí detallamos los pasos sin incluir ejemplos específicos:

• Accedemos al administrador de DNS
  • Iniciamos sesión en el panel de control de nuestro proveedor de hosting o registrador de dominios donde se aloja nuestra DNS.
  • Localizamos la sección de administración de DNS o Dominios en nuestro panel de control.
• Navegamos a la gestión de registros DNS
  • Entramos en la sección específica donde podemos ver y modificar los registros DNS. Esto podría estar etiquetado como “Zona DNS”, “Gestor DNS”, “Configuración de DNS”, o algo similar.
• Agregamos un nuevo registro
  • Seleccionamos la opción para añadir un nuevo registro. Esto puede ser un botón o enlace que nos diga “Agregar Registro”, “Nuevo Registro”, o “Crear Registro”.
• Especificamos el tipo de registro y detalles
  • Escogemos el tipo de registro adecuado y seleccionaremos “TXT” como tipo de registro.
    • Para un registro SPF. Generalmente, el nombre del host para un registro SPF es simplemente “@” si queremos que se aplique al dominio principal. El valor del registro SPF debe empezar con v=spf1 seguido de las directivas en las que especificamos qué servidores están autorizados para enviar correo en nuestro nombre.
    • Para un registro DKIM. El nombre del host es usualmente algo como selector._domainkey. Aquí, “selector” es un prefijo que podemos definir (es una etiqueta que ayuda a identificar la clave específica usada para firmar correos). Por ejemplo, si elige mail como selector, el nombre completo del registro sería mail._domainkey.tudominio.com. El valor para un registro DKIM incluye la versión de DKIM (v=DKIM1), el tipo de clave, y la clave pública en sí.
    • Para un registro DMARC. Usualmente escribiremos “_dmarc”. Esto hará que el nombre completo del registro sea “_dmarc.entidad.com”.
      • Introduciremos el valor del registro. Aquí es donde colocaremos los detalles del registro DMARC, como la política, las direcciones de correo para reportes, etc.
    • Guardaremos el registro
      • Revisaremos la información que hemos introducido para asegurarnos que es correcta.
      • Guardaremos o aplicaremos los cambios. Puede haber un botón que diga “Guardar”, “Aplicar”, o “Actualizar”.
    • Verificación
      • Verificaremos que el registro se haya creado correctamente usando herramientas locales como el comando “dig” o mediante herramientas online de terceros como MXToolbox o similares para asegurarse de que el registro se está propagando y es accesible públicamente.
    • Esperaremos la propagación
      • Debemos de tener en cuenta que los cambios en los registros DNS pueden tardar en propagarse. Este tiempo puede variar desde unos pocos minutos hasta 48 horas, dependiendo del TTL (tiempo de vida) configurado para los registros y del proveedor de DNS.

Uso adecuado de selectores DKIM

Un selector en DKIM es una cadena de caracteres con la que identificamos de manera única un conjunto específico de claves públicas utilizadas para firmar los mensajes de correo electrónico mediante DKIM. Cada dominio que implementa DKIM puede tener múltiples selectores, cada uno asociado con un par de claves pública/privada único. El selector se incluye en la cabecera DKIM del correo electrónico firmado, lo que permite al servidor receptor identificar qué conjunto de claves debe utilizar para verificar la firma DKIM.

Una buena práctica en el uso de selectores DKIM es que utilicemos múltiples selectores para diferentes conjuntos de claves, lo que nos va a facilitar la gestión y la revocación en caso necesario. Esto nos va a implicar asignar un selector específico para los servidores de correo internos y crear selectores independientes para cada tercero o servicio externo que envíe correo en nombre de nuestra organización. Al hacerlo de esta manera, podemos revocar selectivamente un conjunto de claves comprometido sin afectar la autenticación de otros servicios. Además, proporcionamos una mayor granularidad en la gestión de claves y mejora la seguridad global del sistema DKIM.

Medidas adicionales durante la aplicación de políticas de DMARC

Durante la implementación de políticas de DMARC, es fundamental que consideremos tomar medidas adicionales para fortalecer la seguridad del correo electrónico y mitigar los riesgos de suplantación de identidad y phishing. Además de las políticas de reject o quarantine, para los correos electrónicos que no cumplen con SPF, DKIM o DMARC, existen otras acciones que podemos tomar para proteger a sus usuarios:

• Sustitución del Header From por el Envelope From cuando no se cumple DMARC, permitiendo visualizar el remitente real en lugar del Header From que podría ser suplantado.
• Agregar un banner informativo que alerte al usuario sobre la posibilidad de suplantación de identidad y recomiende precaución al abrir el correo.

Estos controles los vamos a aplicar durante la recepción de los correos de los usuarios del dominio protegido. Son medidas que consideramos poco intrusivas pero que resultan eficaces para alertar a los usuarios de correos sospechosos. Es importante que destaquemos que estos controles en ningún caso previenen la suplantación de usuarios del dominio hacia un tercero (esto se realiza gracias a SPF, DKIM y DMARC) ya que operan en la infraestructura del dominio que estamos protegiendo.

En la segunda parte del post entraremos en detalle de la Planificación y preparación, Implantación inicial desde cero, Implementación progresiva y Configuración, Implantación, consideración por volumen de proveedores y tamaño de la organización, e Implicaciones de la implementación.

Accede desde aquí a la Parte II

Nos vemos en las redes!!