Directrices para la AUTENTIFICACIÓN por correo electrónico

!! ATENCIÓN !! Este documento ha sido traducido automáticamente del italiano

Directrices

Configuración del servicio de correo electrónico para la autenticación

La Agencia Nacional de Ciberseguridad de Italia ha publicado las Directrices para la configuración del servicio de correo electrónico con fines de autenticación, con el objetivo de reforzar la fiabilidad del servicio de correo electrónico para todas las organizaciones interesadas y aumentar su nivel general de seguridad.

Control de versiones

ÍNDICE

1. Introducción

1.1. Premisa

El correo electrónico constituye hoy en día uno de los servicios más importantes en el contexto digital, ya que es uno de los principales canales que utilizan las organizaciones y los usuarios para comunicarse e intercambiar información¹.

El funcionamiento del servicio de correo electrónico y, en particular, la transmisión de mensajes se basa en el protocolo SMTP, el cual, sin embargo, no incorpora de forma nativa mecanismos adecuados para la autenticación del remitente ni para la protección de la confidencialidad e integridad de los mensajes. Estas vulnerabilidades lo exponen al riesgo de sufrir ataques como la suplantación de identidad, el phishing, la manipulación y la interceptación de mensajes durante su tránsito.

Para paliar las deficiencias del protocolo SMTP y, por lo tanto, reducir el riesgo derivado de los ataques mencionados, se han desarrollado a lo largo del tiempo mecanismos de autenticación del remitente y de protección de la integridad de los mensajes, como SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting and Conformance).

Estas directrices ilustran dichos mecanismos con el objetivo de reforzar la fiabilidad del servicio de correo electrónico y aumentar su nivel general de seguridad, haciendo especial hincapié en las amenazas descritas en el capítulo 4.

Las medidas y los protocolos necesarios para proteger la confidencialidad de los mensajes de correo electrónico (como S/MIME y OpenPGP, que se refieren al cifrado de mensajes) no son objeto de estas directrices.

1.2. Normativa de referencia

1.3. Documentos de referencia

» Volver al inicio

2. Marco normativo

Para proteger los activos digitales del país, incluidos los servicios de correo electrónico y las infraestructuras que los alojan, se ha establecido un amplio conjunto de medidas de seguridad derivadas de la legislación vigente, que se actualizan constantemente.

El Perímetro Nacional de Ciberseguridad, establecido por el Decreto-Ley n.º 105, de 21 de septiembre de 2019, y convertido con modificaciones por la Ley n.º 133, de 18 de noviembre de 2019, garantiza el máximo nivel de protección para los servicios más críticos del país, relacionados con la protección de la seguridad nacional. Este establece medidas de seguridad con niveles de protección especialmente elevados, detalladas en el anexo B del Decreto del Primer Ministro de 14 de abril de 2021, n.º 81, que se aplican a las redes, los sistemas de información y los servicios informáticos de las entidades públicas y privadas de las que depende el ejercicio de una función esencial del Estado o la prestación de un servicio esencial para el mantenimiento de actividades civiles, sociales o económicas fundamentales para los intereses del Estado, cuyo compromiso podría dar lugar a un perjuicio para la seguridad nacional.

Además, los servicios de correo electrónico, al igual que todos los servicios digitales de la administración pública, están sujetos a las disposiciones del denominado «Reglamento sobre la nube», adoptado en virtud del artículo 33-septies del Decreto-Ley n.º 179, de 18 de octubre de 2012, y actualizado por la Agencia Nacional de Ciberseguridad (ACN) mediante el Decreto Directorial n.º 21007, de 27 de junio de 2024. En virtud del citado Reglamento, todas las administraciones públicas están obligadas a clasificar sus datos y servicios digitales como ordinarios, críticos o estratégicos, de acuerdo con el modelo elaborado por la ACN. Esta actividad tiene por objeto garantizar que los datos y servicios digitales de la administración pública se traten y presten a través de infraestructuras digitales y servicios en la nube que cumplan los requisitos, incluidos los de seguridad, adecuados a los riesgos asociados al nivel de clasificación correspondiente, tal y como se detalla en el Reglamento.

El Decreto Legislativo n.º 138, de 4 de septiembre de 2024 (el denominado «Decreto NIS»), por el que se transpone la Directiva (UE) 2022/2555, estableció asimismo —a través de los anexos 1 y 2 de la resolución ACN n.º 379907/2025— las medidas de seguridad básicas que deben adoptar las entidades esenciales e importantes a efectos de las obligaciones previstas en los artículos 23 y 24 del decreto NIS, definiendo un marco de seguridad para reforzar la protección de las redes y los sistemas de información, incluidos los servicios de correo electrónico.

» Volver al inicio

3. Arquitectura del servicio de correo electrónico

Como se ha señalado en la introducción, el funcionamiento del servicio de correo electrónico se basa en el protocolo SMTP, que regula la transmisión de mensajes de correo electrónico del remitente al destinatario.

El protocolo SMTP se definió originalmente en 1982² como un protocolo de almacenamiento y reenvío, en el que el remitente genera un mensaje a través de su cliente de correo, en la jerga Mail User Agent (MUA), que lo envía al servidor de correo del remitente. Este, a través de un componente denominado Mail Transfer Agent (MTA), reenvía el mensaje, posiblemente también a través de uno o más MTA intermedios, entregándolo al MTA del servidor de correo de destino. El usuario destinatario accede al mensaje a través de su cliente de correo (MUA)[1].

Por lo tanto, el MTA es un componente del servicio de correo electrónico que se encarga de la transmisión de los mensajes de correo electrónico desde el remitente hasta el destinatario. Los componentes del MTA se encuentran en los servidores de correo del remitente y del destinatario, y también se pueden configurar MTA intermedios, por ejemplo, para gestionar listas de distribución.

Aunque el término MTA hace referencia a un componente específico de los servidores de correo electrónico³, dado que a efectos del presente documento se hace referencia a estos últimos principalmente en su función de MTA, y siempre que no haya ambigüedad, para simplificar la exposición se utilizará a menudo el término «servidor de correo electrónico» en lugar del más específico «MTA».

En esta guía nos centramos en la configuración de los protocolos SPF, DKIM y DMARC para que los servidores de correo puedan verificar la autenticidad y la integridad de los mensajes de correo electrónico.

» Volver al inicio

4. Amenazas

El protocolo SMTP, presentado en el capítulo anterior, se diseñó inicialmente para funcionar en una red académica relativamente pequeña y no tenía en cuenta aspectos relacionados con la seguridad de los mensajes transmitidos ni con la autenticación del remitente [1].

La creciente difusión del correo electrónico y las debilidades intrínsecas del protocolo SMTP han propiciado, con el paso del tiempo, la aparición de ataques cuyos principales tipos se describen brevemente en los párrafos siguientes.

4.1. Suplantación de remitente

La suplantación de identidad es una técnica de ciberataque que se utiliza para falsificar la dirección del remitente de un mensaje y hacer que este parezca proceder de una dirección fiable (como, por ejemplo, la de un compañero de trabajo, un conocido o la propia entidad bancaria), con el fin de inducir al destinatario a realizar acciones potencialmente peligrosas, como, por ejemplo, abrir un archivo adjunto de un correo electrónico o hacer clic en los enlaces que contiene el mensaje.

Este tipo de ataque es relativamente fácil de llevar a cabo, ya que el protocolo SMTP no incluye mecanismos de autenticación del remitente y, por lo tanto, a través del cliente de correo electrónico es posible configurar cualquier dirección de remitente al enviar el mensaje.

Dirección de correo electrónico del remitente: «envelope-from» y «message-from»

El formato del mensaje de correo electrónico prevé dos campos distintos para indicar la dirección de correo electrónico del remitente. Estos campos se denominan «envelope-from» y «message-from»: el primero (también conocido como «return-path», ya que especifica la dirección de correo electrónico a la que deben enviarse los mensajes de error generados cuando un correo electrónico no llega al destinatario) es la dirección utilizada para enrutar correctamente el mensaje, mientras que el segundo es la dirección que el destinatario ve en el encabezado del mensaje recibido.

Si lo comparamos con el envío de una carta en un sobre por correo tradicional, el campo «envelope-from» representa la dirección del remitente que figura en el sobre de la carta, mientras que el campo «message-from» se corresponde con el encabezado de la carta que indica quién se ha dirigido al destinatario.

Es importante tener en cuenta que ambas direcciones pueden no coincidir. Esta distinción permite gestionar situaciones como, por ejemplo, el reenvío de mensajes desde servicios de terceros, la distribución a través de listas de correo o las respuestas automáticas por correo electrónico.

De hecho, es posible indicar cualquier remitente tanto en el campo «Message-From» (la dirección de correo electrónico del remitente que el destinatario ve en el encabezado del mensaje recibido) como en el campo «Envelope-From» (la dirección de correo electrónico del remitente utilizada para la transmisión del mensaje).

Para hacer frente a estas amenazas, resulta, por lo tanto, esencial establecer mecanismos que permitan autenticar de forma fiable al remitente y verificar que la persona que envió el mensaje está realmente autorizada para hacerlo.

4.2. Suplantación de identidad

El phishing es una técnica de ciberataque destinada a la obtención fraudulenta de información (como, por ejemplo, credenciales de inicio de sesión, números de tarjetas de crédito u otros datos confidenciales), generalmente mediante el envío de mensajes engañosos que simulan proceder de remitentes fiables³.

El spoofing, analizado en el párrafo anterior, es una de las principales técnicas que utilizan los atacantes para falsificar la identidad del remitente y hacer que el mensaje parezca proceder de un usuario o dominio legítimo.

Como alternativa, se puede utilizar una dirección o un dominio de remitente similar a uno que el destinatario pueda reconocer, modificando, por ejemplo, el denominado «nombre de visualización»⁴ con el fin de reforzar la aparente autenticidad del mensaje.

Para enviar mensajes de phishing, también se pueden utilizar cuentas legítimas que hayan sido comprometidas previamente por el atacante.

Un mensaje de phishing suele tener un contenido diseñado para generar en el destinatario una sensación de urgencia, alarma o interés económico, creando situaciones que le incitan a reaccionar de forma impulsiva y a realizar acciones concretas, como abrir archivos adjuntos maliciosos o hacer clic en enlaces que redirigen a sitios web aparentemente legítimos, pero que en realidad han sido creados por el atacante con el objetivo de robar información o instalar malware.

Por lo general, los ataques de phishing se llevan a cabo enviando el mismo mensaje de correo electrónico a un gran número de víctimas, sin adaptar el texto al perfil específico de cada una de ellas.

Una variante del phishing es el denominado «spear phishing», en el que el atacante conoce el perfil de la víctima y se dirige específicamente a ella.

A diferencia de un correo electrónico de phishing genérico, un mensaje de spear phishing utiliza información contextual más precisa para convencer al usuario de que está interactuando con un remitente fiable [2].

4.3. Manipulación de mensajes

El contenido de un mensaje de correo electrónico, al igual que cualquier otra comunicación que circule por la red de Internet y que no utilice técnicas de cifrado de extremo a extremo (E2EE), puede ser interceptado y modificado durante su tránsito entre el remitente y el destinatario (un tipo de amenaza conocida comúnmente como «ataque de intermediario»).

Por lo tanto, además de la pérdida de confidencialidad, es posible que el mensaje recibido no se corresponda con el que redactó originalmente el remitente.

Un atacante podría, por ejemplo, manipular el contenido del mensaje para que parezca provenir de un remitente fiable, modificar el texto o cualquier enlace y/o archivo adjunto presente en el mensaje, o insertar código malicioso.

De este modo, el destinatario, al confiar en la aparente autenticidad del mensaje, puede verse inducido a realizar acciones potencialmente perjudiciales, como facilitar sus credenciales de acceso, autorizar pagos o abrir archivos maliciosos.

Para hacer frente a estas amenazas, resulta, por lo tanto, esencial adoptar mecanismos que garanticen la integridad y la autenticidad del mensaje, asegurando que el contenido recibido no ha sido modificado y que el remitente es realmente quien dice ser.

» Volver al inicio

5. Medidas correctivas

En el capítulo 2 se recordaron las normas que establecen medidas de seguridad también para la protección de los servicios de correo electrónico. El presente documento tiene como objetivo principal servir de guía para la aplicación de las medidas de seguridad previstas en dicha normativa y recogidas en el Apéndice A, que también son pertinentes para la configuración de los servicios de correo electrónico, con el fin de mitigar los riesgos asociados a las amenazas analizadas en el capítulo 4. Cabe señalar, no obstante, que las indicaciones contenidas en estas directrices también se recomiendan a aquellos sujetos que no estén sujetos a la normativa antes mencionada.

Las medidas de seguridad en cuestión no se refieren explícitamente a la configuración del servicio de correo electrónico, sino —dependiendo de la normativa en cuestión— a la configuración de los sistemas de tecnología de la información y los sistemas de control industrial (PSNC y Reglamento sobre la nube) o de los sistemas de información y redes (NIS2). Los servicios de correo electrónico, objeto de estas directrices, se incluyen en ambos tipos de sistemas.

A continuación se describen, en particular, los protocolos SPF, DKIM y DMARC, que proporcionan mecanismos de seguridad diseñados con el objetivo de reforzar la seguridad general del servicio de correo electrónico y, en concreto, la autenticación del remitente y el control de la integridad de los mensajes.

5.1. SPF

SPF (Sender Policy Framework) es un protocolo de autenticación, formalizado en el RFC 7208, que permite al propietario de un dominio especificar qué direcciones IP están autorizadas a enviar mensajes de correo electrónico en su nombre y establecer las políticas que el destinatario debe aplicar si la dirección IP asociada al dominio⁵ de la dirección de correo electrónico del remitente no se encuentra entre las autorizadas explícitamente.

Las direcciones IP autorizadas figuran en un registro TXT del DNS asociado al dominio del remitente, denominado registro SPF, y se ilustran en la sección siguiente de este párrafo.

De este modo, el servidor de correo electrónico del destinatario⁶ , al recibir un mensaje de un dominio determinado, puede consultar el registro SPF correspondiente y autenticar su origen verificando que la dirección IP desde la que se recibió el mensaje se encuentra entre las autorizadas para enviar mensajes en nombre del dominio.

Es importante señalar que el dominio que se verifica a nivel de SPF es el relacionado con el campo «envelope-from»; por lo tanto, la mera adopción del protocolo SPF no basta para contrarrestar la suplantación de identidad, ya que este tipo de ataque podría llevarse a cabo a nivel del campo «message-from»⁷.

En caso de que una organización externalice, total o parcialmente, su servicio de correo electrónico a un tercero, como, por ejemplo, un proveedor de servicios en la nube, deberá asegurarse de que los mensajes enviados por dichos proveedores superen las comprobaciones SPF. Para ello, la organización deberá incluir en su registro SPF las direcciones IP desde las que los proveedores envían correos electrónicos en nombre del dominio de la organización.

En el caso del reenvío automático de correo electrónico, dado que los mensajes suelen ser redirigidos por un servidor intermedio, la dirección IP que realiza la entrega final ya no coincide con la autorizada originalmente por el dominio del remitente. En estos casos, para que la verificación SPF no falle, es necesario autorizar también a los servidores de reenvío intermedios, o recurrir a mecanismos como SRS (Sender Rewriting Scheme) o ARC (Authenticated Received Chain), que pueden resultar más eficaces, especialmente cuando hay numerosos servidores de reenvío intermedios.

Cabe destacar que, para que el SPF sea realmente eficaz, debe estar correctamente configurado no solo por parte del remitente, sino también por parte del destinatario. En concreto:

• el remitente debe publicar el registro SPF en el servidor DNS correspondiente, indicando las direcciones autorizadas para enviar correos electrónicos en su nombre;
• El destinatario debe configurar su propio servidor de correo para que realice la verificación SPF de los mensajes recibidos y aplique de forma coherente las políticas resultantes.

5.1.1. Registro SPF

Un registro SPF es un registro DNS de tipo TXT cuyo nombre corresponde al dominio del remitente y cuyo contenido está formado⁸ por la sección que indica la versión⁹ y una serie de directivas que indican el comportamiento del servidor de correo del destinatario cuando hay una coincidencia entre la dirección IP del dominio del remitente y una directiva.

Las directivas están formadas por un mecanismo precedido de un calificador. Los principales mecanismos utilizados en los registros SPF son [2]:

• ip4, muestra una lista de direcciones IPv4 autorizadas;
• ip6, muestra una lista de direcciones IPv6 autorizadas;
• a) autoriza las direcciones IP que figuran en el registro A del dominio;
• mx, autoriza las direcciones IP relacionadas con los registros MX del dominio;
• incluye, autoriza las direcciones IP presentes en el registro SPF de otro dominio;
• en definitiva, representa todas las direcciones IP que no han sido autorizadas explícitamente a través de los demás mecanismos.

En concreto, el todos Este mecanismo permite establecer políticas para los mensajes procedentes de direcciones IP que no hayan sido declaradas por mecanismos anteriores.

Además, SPF ofrece los siguientes calificadores para asociar a los mecanismos:

• + (pasar) indica que las direcciones IP que coinciden con el mecanismo asociado están autorizadas. Es el calificador predeterminado si no se especifica otro;
• - (fallo) indica que las direcciones IP que coinciden con el mecanismo asociado no están autorizadas;
• ~ (softfail) indica que las direcciones IP que coinciden con el mecanismo asociado probablemente no estén autorizadas. Se trata de una indicación menos categórica que la anterior. En estos casos, el mensaje debe aceptarse, pero marcarse para un análisis más detallado; se utiliza, por ejemplo, en casos de depuración o cuando se prevé que la verificación SPF podría no completarse con éxito;
• ? (neutro) indica que no se proporciona ninguna indicación para las direcciones IP que coincidan con el mecanismo asociado. El comportamiento predeterminado es aceptar el mensaje.

Cabe destacar que, en la práctica, el registro SPF se configura para especificar las direcciones IP autorizadas, recurriendo luego a la directiva -todo para indicar que el resto de direcciones no están autorizadas (a este respecto, consulte los ejemplos que figuran a continuación). Esta es la configuración recomendada, ya que permite indicar explícitamente las direcciones IP autorizadas y excluir todas las demás.

En cualquier caso, se recomienda no utilizar nunca la directiva +todo (o su equivalente todos), ya que equivaldría a autorizar todas las direcciones IP.

Ejemplos de registros SPF

Autorizar una dirección IP concreta

v=spf1 ip4:203.0.113.0 -all

El registro SPF que se muestra arriba utiliza la versión 1 de SPF y autoriza a través del ip4 mecanismo de la dirección IP 203.0.113.0 (de hecho, dado que no se ha especificado ningún calificativo para el ip4 mecanismo, el valor predeterminado + se utiliza de forma implícita). El -todo directiva formada por la todos mecanismo y el - El calificador «(fail)» indica que el resto de direcciones no están autorizadas.

Autorizar un rango de direcciones IP específico

v=spf1 ip4:203.0.113.0/24 -all

El registro SPF que se muestra arriba es similar al anterior, pero autoriza todas las direcciones IP de la 203.0.113.0/24 espacio de direcciones.

Autorizar varias direcciones IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

El registro SPF que se muestra arriba autoriza exclusivamente las direcciones IPv4 203.0.113.22 y 203.0.113.44.

Autorizar las direcciones de los registros MX y un dominio específico

v=spf1 mx include:spf.emailprovider.it -all

El registro SPF que se muestra arriba autoriza exclusivamente las direcciones IP de los registros MX del mismo dominio que el registro SPF y las direcciones IP autorizadas del dominio. spf.emailprovider.it (por ejemplo, el dominio de un proveedor de servicios de correo electrónico).

5.1.2. Proceso de autenticación

Si está correctamente configurado para realizar la verificación SPF, el servidor de correo del destinatario, al recibir un nuevo mensaje de correo electrónico, recupera el registro SPF del dominio del remitente consultando el servidor DNS que contiene los registros de dicho dominio, tal y como se desprende de la dirección indicada en el campo «envelope-from». Por ejemplo, si la dirección indicada en el campo «envelope-from» es alice@example.com, el servidor de correo del destinatario recupera el registro SPF del dominio ejemplo.com.

A continuación, el servidor de correo del destinatario lleva a cabo la verificación SPF, analizando el registro SPF para determinar si la dirección IP desde la que recibió el mensaje está autorizada para enviar correos electrónicos en nombre del ejemplo.com dominio. Si el mensaje de correo electrónico supera la verificación SPF, se entrega al destinatario.

Por ejemplo, si el registro SPF del ejemplo.com dominio eran v=spf1 ip4:203.0.113.22 -all la verificación solo se superaría si la dirección IP del servidor del remitente fuera 203.0.113.22, mientras que fallaría con cualquier otra dirección.

» Volver al inicio

5.2. DKIM

DKIM (DomainKeys Identified Mail) es un protocolo de autenticación, formalizado en el RFC 6376, que permite al propietario de un dominio garantizar la autenticidad de los mensajes de correo electrónico enviados mediante la incorporación de una firma digital (firma DKIM) generada por el servidor de correo a través de algoritmos de criptografía pública e insertada en los encabezados del mensaje que se va a transmitir.

Para que el destinatario pueda comprobar que el mensaje no ha sido modificado durante la transmisión, la clave pública asociada a la firma DKIM se almacena en un registro TXT del DNS público del dominio del remitente, denominado «registro DKIM», que el servidor de correo del destinatario consulta al recibir el mensaje.

La firma y el registro DKIM se describen en los apartados siguientes de este párrafo.

Al igual que con el SPF, el DKIM también debe estar correctamente configurado tanto por el remitente como por el destinatario y, en particular:

• el remitente debe configurar su servidor de correo para generar firmas DKIM y publicar el registro DKIM en el servidor DNS correspondiente;
• El destinatario debe configurar su servidor de correo para que realice la verificación DKIM en los mensajes recibidos.

5.2.1. Firma DKIM

La firma DKIM se genera a partir de elementos específicos del cuerpo y los encabezados del mensaje, y consiste en una serie de pares clave-valor que especifican elementos, entre los que se incluyen:

• v: versión del protocolo¹⁰;
• a: algoritmo de cifrado utilizado¹¹;
• d: firma de dominio que certifica la autenticidad del mensaje¹²;
• s: selector que indica qué clave pública DKIM se debe buscar en el registro DNS¹³;
• h: lista de encabezados de correo electrónico incluidos en la firma¹⁴;
• bh: hash del cuerpo del mensaje codificado en formato Base64¹⁵;
• b: firma digital real generada con la clave privada y codificada en formato base64¹⁶;
• x: fecha de validez de la firma;
• c: tipo de canonicalización.

La canonicización es el proceso de normalización de los elementos de un mensaje antes de su firma digital, con el fin de reducir el impacto de pequeñas modificaciones que pueden producirse durante la transmisión, como espacios repetidos o saltos de línea. Existen dos tipos de canonicización: la simple, que exige una coincidencia exacta entre el mensaje original y el recibido, y la flexible, que aplica normalizaciones como la eliminación de espacios, la conversión de mayúsculas a minúsculas en los encabezados y la reducción de líneas vacías consecutivas en el cuerpo del mensaje.

5.2.2. Registro DKIM

El registro DKIM se almacena en un registro DNS de tipo TXT cuyo nombre tiene la estructura selector._domainkey.domain, donde _domainkey es una etiqueta que se utiliza para indicar que el registro DNS es, efectivamente, un registro DKIM. El contenido del registro DKIM consiste en una serie de pares clave-valor que especifican diversos elementos, entre los que se incluyen:

• v: versión del protocolo;
• k: tipo de clave, que por defecto es RSA;
• p: clave pública codificada en formato Base64.

Ejemplo de registro DKIM

Nombre: s1._domainkey.example.com
Valor: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

El registro DKIM de ejemplo está asociado al selector s1 de la ejemplo.com dominio, utiliza la versión 1 y contiene la clave pública RSA codificada en formato base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Proceso de autenticación

Si el protocolo DKIM está correctamente configurado tanto en el servidor de correo del remitente como en el del destinatario, el funcionamiento del proceso de autenticación y verificación DKIM establece que el servidor de correo del remitente genere la firma DKIM del mensaje tal y como se describe en el apartado 5.2.1, la cual se añade al propio mensaje. En concreto, la firma DKIM contiene en el d campo del dominio de firma¹⁷ y en el b introduzca la firma digital del mensaje generada con la clave privada del dominio firmante.

Al recibir un mensaje, el servidor de correo del destinatario recupera el registro DKIM del dominio firmante (d campo de la firma DKIM) del servidor DNS que contiene los registros de ese dominio. A continuación, utiliza la clave pública contenida en el registro DKIM para verificar la firma digital (b (campo) que figura en la firma DKIM. Si la verificación se realiza correctamente, el mensaje se entrega al destinatario.

5.2.4. Aspectos criptográficos

En el ámbito de la criptografía, DKIM ha utilizado tradicionalmente el algoritmo RSA, concretamente en su variante rsa-sha256, considerada el estándar desde 2007. La nueva alternativa, introducida por el RFC 8463, es Ed25519-SHA256, una forma moderna de firma digital basada en curvas elípticas que garantiza una mayor eficiencia y claves mucho más compactas.

Desde el punto de vista técnico, RSA, con una longitud de clave de 2048 bits, sigue siendo el estándar universal, pero las claves son largas y las firmas relativamente grandes, mientras que Ed25519 ofrece claves nueve veces más cortas y firmas cuatro veces más pequeñas, con un rendimiento de firma hasta treinta veces superior en comparación con RSA 2048. A pesar de estas ventajas, la compatibilidad en la práctica es limitada: en 2026, Ed25519 solo es verificado por unos pocos proveedores, mientras que algunos de los principales operadores no admiten de forma fiable ni la firma ni la verificación, lo que lo hace inadecuado como única solución en producción.

Por este motivo, a pesar de ser técnicamente superior, en el momento de redactar este documento no se recomienda el uso de Ed25519, salvo en combinación con RSA, mediante firma dual, desde una perspectiva experimental y como medida de compatibilidad futura. Hasta que los principales proveedores implementen plenamente su verificación, RSA sigue siendo esencial para garantizar la máxima seguridad en la entrega de mensajes.

En lo que respecta a la seguridad a largo plazo, es importante recordar que ni RSA ni Ed25519 son resistentes a los ataques de los futuros ordenadores cuánticos [3], y que la transición hacia algoritmos poscuánticos requerirá nuevos estándares DKIM que aún no existen, por lo que resulta esencial estar al tanto de los avances en criptografía de última generación y de las futuras recomendaciones de la ACN en este ámbito.

En lo que respecta a la gestión de claves criptográficas, la clave privada DKIM debe protegerse con medidas de seguridad rigurosas, manteniéndola en sistemas aislados a los que solo tengan acceso los servicios autorizados, aplicando permisos restrictivos, rotándola periódicamente y supervisándola constantemente para evitar accesos no autorizados o vulneraciones de seguridad.

» Volver al inicio

5.3. DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) es un protocolo de autenticación, formalizado en el RFC 7489, que integra¹⁸ los mecanismos SPF y DKIM, lo que permite al propietario de un dominio especificar, a los destinatarios de los mensajes transmitidos desde ese dominio, las políticas para gestionar aquellos mensajes que no superan las verificaciones SPF y DKIM.

En concreto, DMARC introduce un mecanismo de autenticación —denominado «alineación»— que verifica la correspondencia entre los dominios autenticados por SPF y DKIM y el dominio relacionado con el mensaje de campo del mensaje recibido. Ten en cuenta que la comprobación de alineación entre el mensaje de y el dominio SPF/DKIM falla en cualquier caso si falla la verificación SPF/DKIM correspondiente (véase la figura 4).

La alineación se puede comprobar en estricto modo, en el que se requiere una coincidencia exacta entre los dominios autenticados por SPF/DKIM y el relacionado con el mensaje de campo, o relajado, donde basta con que coincidan los dominios principales, aunque los subdominios puedan ser diferentes.

Por ejemplo, en relajado modo para dominios sub1.ejemplo.com y sub2.ejemplo.com se encontraría una coincidencia a efectos de la verificación DMARC (dado que el dominio principal, ejemplo.com, es lo mismo). En estricto Sin embargo, en este modo, la comprobación de alineación de DMARC fallaría debido a la falta de una coincidencia exacta entre los dominios.

Mediante la verificación de la coincidencia, incluso si un atacante lograra superar las comprobaciones de SPF y/o DKIM utilizando un mensaje de diferente del remitente del sobre Aunque el correo haya sido autenticado mediante SPF o proceda del dominio de firma autenticado, DMARC seguiría detectando la discrepancia, lo que garantiza una verificación coherente y fiable de la identidad del remitente [2].

Políticas para la gestión de los mensajes fallidos¹⁹ La verificación DMARC se especifica en un registro TXT del servidor DNS relativo del dominio del remitente, denominado registro DMARC, y se ilustra en la sección siguiente de este párrafo.

DMARC también permite indicar a los destinatarios que envíen informes a los propietarios del dominio remitente sobre los mensajes que afirman proceder de dicho dominio. De este modo, el propietario del dominio puede verificar si su dominio está siendo utilizado de forma no autorizada y en qué medida, analizando, por ejemplo, cuántos mensajes de los que afirman proceder de su dominio son realmente atribuibles a él.

Al igual que con SPF y DKIM, DMARC también debe estar correctamente configurado tanto por el remitente como por el destinatario y, en particular:

• el remitente debe publicar el registro DMARC en su DNS especificando las políticas que se aplicarán a los mensajes que no superen la verificación DMARC;
• El destinatario debe configurar su servidor de correo para que realice la verificación DMARC en los mensajes recibidos.

5.3.1. Registro DMARC

El nombre del registro DMARC tiene la siguiente estructura _dmarc.dominio, donde _dmarc es una etiqueta que se utiliza para indicar que el registro DNS es un registro DMARC y dominio es el dominio al que se refiere la política.

El registro DMARC consta de una serie de pares clave-valor que especifican diversos elementos, entre los que se incluyen:

• v: Versión del protocolo DMARC²⁰;
• p: política que se aplicará a los mensajes que no superen la verificación DMARC; puede adoptar uno de los siguientes valores ninguno, cuarentena, rechazar;
• aspf: modo de alineación que se aplicará a la comprobación SPF (puede ser relajado, valor predeterminado, o estricto);
• adkim: modo de alineación que se aplicará a la comprobación DKIM (puede ser relajado, valor predeterminado, o estricto);
• rua: direcciones de correo electrónico a las que enviar informes agregados con información estadística y resumida sobre los mensajes recibidos del dominio del remitente;
• ruf: direcciones de correo electrónico a las que enviar informes detallados sobre los mensajes individuales recibidos del dominio del remitente que no han superado la verificación DMARC.

Ejemplo de registro DMARC

Nombre:
_dmarc.example.com
Valor:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

El registro DMARC de ejemplo está asociado al ejemplo.com dominio, utiliza la versión 1 y especifica el rechazar política para los mensajes que no superan la verificación DMARC, solicitando estricto modo (s) para verificar la coincidencia de los dominios SPF y DKIM y para enviar informes agregados a la dirección de correo electrónico dmarc-reports@example.com y los informes de fallos a la dirección dmarc-fail@example.com.

5.3.2. Políticas DMARC

Tal y como se ha descrito en el párrafo anterior, el registro DMARC indica la política que el servidor de correo receptor debe aplicar a los mensajes que no superen la verificación DMARC. Las políticas posibles son las siguientes:

• ninguna: el dominio del remitente no proporciona ninguna indicación sobre la entrega de los mensajes que no superan la verificación DMARC;
• cuarentena: el dominio del remitente indica que los mensajes que no superen la verificación DMARC deben considerarse sospechosos (por ejemplo, someterse a un examen más detallado, tratarse como spam o marcarse como sospechosos);
• rechazar: el dominio del remitente indica que los mensajes que no superen la verificación DMARC deben rechazarse.

5.3.3. Proceso de verificación y aplicación de la política

Si el protocolo DMARC está correctamente configurado tanto en el servidor de correo del remitente como en el del destinatario, al recibir el mensaje, el servidor de correo del destinatario recupera los registros SPF y DKIM para realizar las verificaciones correspondientes, así como la verificación DMARC (detallada al principio del apartado 5.2.4). En caso de que el mensaje no supere la verificación DMARC, la política indicada en el registro DMARC (ninguno, cuarentena o rechazar) se aplica.

Cabe señalar que cada servidor de correo puede aplicar heurísticas y políticas locales para determinar si se entrega o no un mensaje, teniendo en cuenta también el resultado de las verificaciones de SPF, DKIM y DMARC. Por lo tanto, por lo general, existe un proceso de toma de decisiones adicional («Filtro estándar» en la figura 5) posterior a las verificaciones mencionadas, que también puede incluir comprobaciones adicionales (como, por ejemplo, filtros antispam y antimalware).

Además, el servidor de correo del destinatario puede enviar:

• a las direcciones indicadas en el rua campo del registro DMARC, informes agregados con información estadística y resumida sobre los mensajes recibidos del dominio del remitente;
• a las direcciones indicadas en el ruf campo del registro DMARC, informes detallados sobre los mensajes individuales recibidos del dominio del remitente que no superaron la verificación DMARC.

» Volver al inicio

6. Conclusiones

Como se ha comentado en el capítulo anterior, para contrarrestar de la mejor manera posible las amenazas relacionadas con la suplantación de identidad del dominio del remitente, es necesario que los tres protocolos analizados se implementen conjuntamente y, en particular, que [3]:

• el dominio del remitente publique correctamente los registros SPF, DKIM y DMARC en el DNS;
• el servidor de correo del remitente está configurado para firmar los mensajes con DKIM;
• El servidor de correo del destinatario está configurado para realizar verificaciones SPF y DKIM y aplicar políticas DMARC.

En lo que respecta a la aplicación del protocolo, se formulan también las siguientes recomendaciones [2]:

• configurar el SPF especificando qué direcciones IP están autorizadas a enviar correos electrónicos en nombre del dominio; en el caso de los dominios que no se utilizan para el envío de correo electrónico, por ejemplo, aquellos destinados exclusivamente a sitios web, se debe crear igualmente un registro SPF para indicar explícitamente que no hay remitentes de correo electrónico válidos para ese dominio;
• utilizar protocolos y algoritmos de cifrado de última generación considerados seguros para las claves DKIM; en el momento de redactar este documento, se recomienda el RSA de 2048 bits;
• proteger adecuadamente la clave privada DKIM almacenada en el servidor de correo, estableciendo permisos de acceso restrictivos, y asegurarse de que solo el software del servidor de correo tenga privilegios de lectura sobre la clave;
• configurar cada servidor de correo con un par de claves y un selector únicos, con el fin de reducir el impacto de una posible filtración de la clave privada;
• proteger la clave privada tanto de una divulgación accidental como de los intentos de acceso o modificación por parte de un atacante;
• establecer que el software relacionado con cualquier lista de correo verifique las firmas DKIM de los mensajes entrantes y añada nuevas firmas DKIM a los mensajes salientes;
• utilizar pares de claves DKIM únicos para cada tercero que envíe correos electrónicos en nombre de la organización;
• renovar periódicamente los pares de claves DKIM (al menos cada seis meses) para mitigar el impacto de una posible violación de la seguridad;
• revocar inmediatamente las claves en caso de que se sospeche que han sido comprometidas;
• Supervise los informes DMARC para detectar posibles errores de configuración o intentos de uso indebido.

Para obtener más información, consulte los recursos que figuran en la sección «Documentos de referencia».

Cabe señalar que, para garantizar adecuadamente la seguridad del correo electrónico, además de los protocolos de autenticación analizados aquí, existen otros protocolos —que no son objeto de estas directrices—, como, por ejemplo, TLS (Transport Layer Security), que garantiza el cifrado del canal de transmisión, y S/MIME y OpenPGP, que se refieren al cifrado de extremo a extremo y a la autenticación de mensajes.

Cabe señalar también que, aunque no se trata de un protocolo de seguridad del correo electrónico en sentido estricto, a efectos de la seguridad del servicio de correo electrónico se recomienda implementar DNSSEC (Extensiones de Seguridad del Sistema de Nombres de Dominio), una extensión del protocolo DNS que añade firmas criptográficas a los registros DNS con el fin de garantizar la integridad y la autenticidad de las consultas DNS. Gracias a DNSSEC, por ejemplo, la información relativa a los registros SPF, DKIM y DMARC queda protegida durante la transmisión, lo que reduce el riesgo de alteración y, por lo tanto, aumenta la seguridad del servicio de correo electrónico.

» Volver al inicio

Apéndice A: Medidas de seguridad

Perímetro Nacional de Ciberseguridad (PSNC)

PR.IP-1: Se definen y gestionan prácticas de referencia (las denominadas «líneas de base») para la configuración de los sistemas de TI y los sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).

1. Existe un documento detallado y actualizado en el que se indica, también en relación con la categoría ID.AM, al menos:
   • a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas informáticos y de control industrial, así como la implementación exclusiva de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas informáticos y de control industrial utilizadas, así como la referencia a las prácticas de referencia correspondientes;
   • c) los procesos, metodologías y tecnologías empleados que contribuyen al cumplimiento de las políticas de seguridad.

Regulación de la nube: infraestructuras y servicios digitales para la administración pública

PR.IP-01: Se definen y gestionan prácticas de referencia (las denominadas «líneas de base») para la configuración de sistemas informáticos y sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).

1. Las políticas y los procedimientos se definen en relación con la seguridad de las aplicaciones con el fin de proporcionar el apoyo adecuado para la planificación, la implementación y el mantenimiento de las medidas de seguridad de las aplicaciones, que deben revisarse y actualizarse al menos una vez al año.
2. Existe un documento detallado y actualizado en el que se indica, también en relación con la categoría ID.AM, al menos:
   • a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas informáticos y de control industrial, así como la implementación exclusiva de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas informáticos y de control industrial utilizadas, así como la referencia a las prácticas de referencia correspondientes;
   • c) los procesos, metodologías y tecnologías empleados que contribuyen al cumplimiento de las políticas de seguridad.
3. Se definen y documentan los requisitos básicos para la seguridad de diversas aplicaciones.
4. Se definen y aplican métricas de carácter técnico que resultan útiles para supervisar el grado de cumplimiento de los requisitos de seguridad y las obligaciones de conformidad establecidos.
5. Existe un proceso para la mitigación de vulnerabilidades y la recuperación de aplicaciones con el fin de garantizar su seguridad, que automatiza la corrección siempre que sea posible.
6. Existe un proceso para comprobar la compatibilidad de los dispositivos con los sistemas operativos y las aplicaciones.
7. Existe un sistema de gestión de cambios en lo que respecta al sistema operativo, la aplicación de parches y/o las aplicaciones.

Normativa sobre la nube – Servicios en la nube para la administración pública

PR.IP-01: Se definen y gestionan prácticas de referencia (las denominadas «líneas de base») para la configuración de sistemas informáticos y sistemas de control industrial que incorporan principios de seguridad (por ejemplo, el principio de mínima funcionalidad).

1. Las políticas y los procedimientos se definen en relación con la seguridad de las aplicaciones con el fin de proporcionar el apoyo adecuado para la planificación, la implementación y el mantenimiento de las medidas de seguridad de las aplicaciones, que deben revisarse y actualizarse al menos una vez al año [IaaS, SaaS].
2. Existe un documento detallado y actualizado en el que se indica, también en relación con la categoría ID.AM, al menos:
   • a) las políticas de seguridad adoptadas para el desarrollo de configuraciones de sistemas informáticos y de control industrial, así como la implementación exclusiva de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas informáticos y de control industrial utilizadas, así como la referencia a las prácticas de referencia correspondientes;
   • c) los procesos, metodologías y tecnologías empleados que contribuyen al cumplimiento de las políticas de seguridad [SaaS].
3. Se definen y documentan los requisitos básicos para la seguridad de diversas aplicaciones.
4. Se definen y aplican métricas de carácter técnico que resultan útiles para supervisar el nivel de cumplimiento de los requisitos de seguridad y las obligaciones de conformidad establecidos. 5. Existe un proceso para la mitigación de vulnerabilidades y la recuperación de la seguridad de las aplicaciones, que automatiza la corrección siempre que sea posible.
5. Existe un proceso para validar la compatibilidad de los dispositivos con los sistemas operativos y las aplicaciones [PaaS, SaaS].
6. Existe un sistema de gestión de cambios en lo que respecta al sistema operativo, la aplicación de parches y/o las aplicaciones [PaaS, SaaS].

NIS 2

PR.PS-01: Se han establecido y se aplican prácticas de gestión de la configuración.

1. Al menos en lo que respecta a la información relevante y a los sistemas de red, sus configuraciones básicas seguras (reforzadas) se definen y documentan en una lista actualizada.
2. De conformidad con las políticas a las que se hace referencia en la medida GV.PO-01, se han adoptado y documentado los procedimientos correspondientes al punto 1.

» Volver al inicio

Bibliografía

[1] NIST, «Nota técnica 1945».
[2] NIST, «Publicación especial del NIST 800-177, revisión 1»
[3] Agencia Nacional de Ciberseguridad, «Criptografía cuántica y poscuántica: preparación para la amenaza cuántica».
[4] Agencia Nacional de Ciberseguridad, «Marco de autenticación del correo electrónico».

» Volver al inicio