Directrices de AUTENTICACIÓN de correo electrónico

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

Pautas

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

La Agencia Nacional Italiana de Ciberseguridad ha publicado las Directrices para la configuración del servicio de correo electrónico para la 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 representa hoy en día uno de los servicios más críticos en el contexto digital, ya que se encuentra entre los principales canales utilizados por organizaciones y usuarios para la comunicación y el intercambio de información¹.

El funcionamiento del servicio de correo electrónico, y en particular la transmisión de mensajes, se basa en el protocolo SMTP, que, 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 ataques como la suplantación de identidad, el phishing, la manipulación y la interceptación de mensajes durante su transmisión.

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

Estas directrices ilustran estos mecanismos con el objetivo de reforzar la fiabilidad del servicio de correo electrónico y aumentar su nivel general de seguridad, con especial referencia a las amenazas descritas en el Capítulo 4.

Las contramedidas 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. Reglamento de Referencia

1.3. Documentos de referencia

» Volver arriba

2. Contexto regulatorio

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

El máximo nivel de protección para los servicios más críticos del país, vinculados a la protección de la seguridad nacional, está garantizado por el Perímetro Nacional de Ciberseguridad, establecido por el Decreto Ley n.º 105, de 21 de septiembre de 2019, modificado por la Ley n.º 133, de 18 de noviembre de 2019. Este perímetro proporciona medidas de seguridad con niveles de protección particularmente altos, detallados en el Anexo B del Decreto del Primer Ministro n.º 81, de 14 de abril de 2021, que se aplican a las redes, sistemas de información y servicios de TI de 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 las actividades civiles, sociales o económicas fundamentales para los intereses del Estado, cuyo compromiso podría resultar en perjuicio de 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 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. Conforme a dicho Reglamento, todas las administraciones públicas deben clasificar sus datos y servicios digitales como ordinarios, críticos o estratégicos, según el modelo elaborado por la ACN. Esta actividad tiene como objetivo garantizar que los datos y servicios digitales de la administración pública se procesen y presten a través de infraestructuras digitales y servicios en la nube que cumplan con los requisitos, incluidos los de seguridad, adecuados a los riesgos asociados al nivel de clasificación correspondiente, tal como se detalla en el Reglamento.

El Decreto Legislativo n.º 138 de 4 de septiembre de 2024 (el denominado Decreto NIS), que transpone la Directiva (UE) 2022/2555, también estableció, mediante los Anexos 1 y 2 de la Determinación ACN 379907/2025, las medidas básicas de seguridad que las entidades esenciales e importantes deben adoptar a efectos de las obligaciones establecidas 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 arriba

3. Arquitectura del servicio de correo electrónico

Como se indica en la premisa, 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 desde el 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 Agente de Usuario de Correo (MUA), que lo envía al servidor de correo del remitente. Este, a través de un componente llamado Agente de Transferencia de Correo (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 receptor 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 gestiona la transmisión de mensajes desde el remitente al destinatario. Los componentes del MTA están presentes 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 identifica un componente específico de los servidores de correo electrónico³, dado que para los fines de este documento se hace referencia a estos últimos principalmente en su función como MTA, donde no hay 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 permitir que los servidores de correo verifiquen la autenticidad e integridad de los mensajes de correo electrónico.

» Volver arriba

4. Amenazas

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

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

4.1. Suplantación de identidad del remitente

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

Este tipo de ataque es relativamente sencillo 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 originar 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 que se utiliza para enrutar correctamente el mensaje; el segundo es la dirección que el destinatario ve en el encabezado del mensaje recibido.

Haciendo una analogía con el envío de una carta dentro de un sobre por correo tradicional, el campo "sobre-de" representa la dirección del remitente que aparece en el sobre de la carta, mientras que el campo "mensaje-de" corresponde al encabezado presente en la carta que indica quién escribió al destinatario.

Es importante tener en cuenta que las dos direcciones pueden no coincidir. Esta distinción permite gestionar situaciones como, por ejemplo, el reenvío de mensajes de 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 a nivel del remitente del mensaje (la dirección de correo electrónico del remitente que muestra el destinatario en el encabezado del mensaje recibido) como del remitente del sobre (la dirección de correo electrónico del remitente utilizada para la transmisión del mensaje).

Para contrarrestar estas amenazas, resulta esencial proporcionar 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 (Phishing)

El phishing es una técnica de ataque cibernético destinada a la adquisició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 provenir de remitentes confiables³.

La suplantación de identidad, analizada en el párrafo anterior, es una de las principales técnicas que utiliza un atacante para falsificar la identidad del remitente y hacer que el mensaje parezca provenir de un usuario o dominio legítimo.

Como alternativa, se puede utilizar una dirección/dominio del remitente similar a uno reconocible por el destinatario, modificando, por ejemplo, el llamado nombre para mostrar⁴ para reforzar la autenticidad aparente del mensaje.

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

Un mensaje de phishing suele tener un contenido diseñado para generar urgencia, alarma o interés económico en el destinatario, creando situaciones que lo inducen a reaccionar impulsivamente y realizar acciones específicas, 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 software malicioso.

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 llamado spear phishing, en el que el atacante conoce el perfil de la víctima y lo ataca específicamente.

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 confiable [2].

4.3. Manipulación de mensajes

El contenido de un mensaje de correo electrónico, al igual que cualquier otra comunicación que viaje a través de la red de Internet y que no utilice técnicas de cifrado de extremo a extremo (E2EE), puede ser interceptado y modificado durante la transmisión entre el remitente y el destinatario (un tipo de amenaza comúnmente denominada ataque de intermediario).

En consecuencia, además de la pérdida de confidencialidad, el mensaje recibido podría no corresponderse con el que fue redactado originalmente por 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 o archivo adjunto presente en el mensaje, o insertar código malicioso.

El destinatario, confiando en la aparente autenticidad del mensaje, puede ser inducido a realizar acciones potencialmente dañinas, como comunicar credenciales de inicio de sesión, autorizar pagos o abrir archivos maliciosos.

Para contrarrestar estas amenazas, resulta fundamental adoptar mecanismos que garanticen la integridad y autenticidad del mensaje, asegurando que el contenido recibido no haya sido modificado y que el remitente sea realmente quien dice ser.

» Volver arriba

5. Contramedidas

El capítulo 2 repasó la normativa que establece medidas de seguridad para la protección de los servicios de correo electrónico. Este documento tiene como objetivo principal servir de guía para la implementación de las medidas de seguridad previstas en dicha normativa y recogidas en el Anexo A, las cuales también son relevantes 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 quienes no estén sujetos a la normativa mencionada.

Las medidas de seguridad en cuestión no se refieren explícitamente a la configuración del servicio de correo electrónico, sino —según la normativa aplicable— a la configuración de los sistemas informáticos y de control industrial (PSNC y Cloud Regulation) o de los sistemas de información y redes (NIS2). Los servicios de correo electrónico a los que se refieren estas directrices pertenecen a ambos tipos de sistemas.

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

5.1. FPS

SPF – Sender Policy Framework es un protocolo de autenticación, formalizado por RFC 7208, que permite al propietario de un dominio especificar qué direcciones IP están autorizadas para 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 DNS TXT relacionado con el dominio del remitente, denominado registro SPF, y se ilustran en la siguiente sección de este párrafo.

De esta forma, el servidor de correo electrónico del destinatario^6, al recibir un mensaje de un dominio determinado, puede consultar el registro SPF relacionado 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 observar que el dominio que se verifica a nivel SPF es el relacionado con el remitente del sobre; por consiguiente, la adopción del protocolo SPF por sí sola no es suficiente para contrarrestar la suplantación de identidad, ya que este tipo de ataque podría llevarse a cabo a nivel del remitente del mensaje⁷.

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, debe asegurarse de que los mensajes enviados por dicho proveedor superen las comprobaciones SPF. Para ello, la organización debe 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 evitar que falle la verificación SPF, es necesario autorizar también los servidores de reenvío intermedios o recurrir a mecanismos como SRS (Sender Rewriting Scheme) o ARC (Authenticated Received Chain), que pueden ser más eficaces, especialmente en presencia de numerosos servidores de reenvío intermedios.

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

• El remitente debe publicar el registro SPF en el servidor DNS correspondiente, declarando las direcciones que están autorizadas para enviar correos electrónicos en su nombre;
• El destinatario debe configurar su propio servidor de correo para que ejecute la verificación SPF en 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á constituido^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 se forman mediante un mecanismo precedido por un calificador. Los principales mecanismos utilizados en los registros SPF son: [2]:

• ip4, enumera las direcciones IPv4 autorizadas;
• ip6, enumera las direcciones IPv6 autorizadas;
• a, autoriza las direcciones IP presentes en el registro A del dominio;
• mx, autoriza las direcciones IP relacionadas con los registros MX del dominio;
• incluye, autoriza las IP presentes en el registro SPF de otro dominio;
• "all"representa todas las direcciones IP que no han sido autorizadas explícitamente a través de los otros mecanismos.

En particular, el "all" permite establecer políticas para los mensajes provenientes de direcciones IP que no hayan sido declaradas por mecanismos anteriores.

Además, SPF proporciona los siguientes calificadores para asociarlos con los mecanismos:

• + (pass) indica que las direcciones IP que coinciden con el mecanismo asociado están autorizadas. Es el calificador predeterminado si no se especifica otro;
• - (fail) 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. Esta es una declaración más incierta que la anterior. En estos casos, el mensaje debe aceptarse pero marcarse para un análisis más profundo; se utiliza, por ejemplo, en casos de depuración o cuando se prevé que la verificación SPF podría no ser exitosa;
• ? (neutral) 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.

Es importante destacar que, en la práctica, el registro SPF se compone para especificar las direcciones IP autorizadas, y luego se utiliza la directiva -all para indicar que todas las demás direcciones no están autorizadas (para más detalles, consulte los ejemplos 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 +all (o su equivalente all), ya que correspondería a la autorización de todas las direcciones IP.

Ejemplos de registros SPF

Autorizar una dirección IP específica

v=spf1 ip4:203.0.113.0 -todos

El registro SPF que se muestra arriba utiliza la versión 1 de SPF y autoriza, mediante el mecanismo ip4 , la dirección IP 203.0.113.0 (de hecho, como no se especifica ningún calificador para el mecanismo ip4 , se utiliza implícitamente el valor predeterminado + ). La directiva -all, formada por el mecanismo all y el calificador - (fail), especifica que todas las demás direcciones no están autorizadas.

Autorizar un espacio de direcciones IP específico

v=spf1 ip4:203.0.113.0/24 -todos

El registro SPF que se muestra arriba es análogo al anterior, pero autoriza todas las direcciones IP del 203.0.113.0/24 .

Autorizar múltiples direcciones IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -todos

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

Autorizar direcciones de registro MX y un dominio específico

v=spf1 mx incluir:spf.emailprovider.it -todo

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 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á configurado correctamente para realizar la verificación SPF, el servidor de correo del destinatario, al recibir un nuevo mensaje, recupera el registro SPF del dominio del remitente consultando el servidor DNS que contiene los registros de dicho dominio, según la dirección indicada en el campo "de" del sobre. Por ejemplo, si la dirección indicada en el campo "de" del sobre es alice@example.com, el servidor de correo del destinatario recupera el registro SPF del dominio example.com.

El servidor de correo del destinatario realiza entonces 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 para el example.com . Si el correo electrónico supera la verificación SPF, se entrega al destinatario.

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

» Volver arriba

5.2. DKIM

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

Para que el destinatario pueda verificar que el mensaje no ha sido modificado durante la transmisión, la clave pública asociada a la firma DKIM se guarda 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 ilustran en las secciones siguientes de este párrafo.

Al igual que con SPF, DKIM también debe ser configurado correctamente por el remitente y 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 designados del cuerpo y las cabeceras del mensaje y consta de una serie de pares clave-valor que especifican elementos entre los cuales:

• v: versión del protocolo¹⁰;
• a: algoritmo de cifrado utilizado¹¹;
• d: dominio de firma que declara la autenticidad del mensaje¹²;
• s: selector que indica qué clave pública DKIM 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 canonización.

La canonicalización es el proceso de normalizar los elementos de un mensaje antes de firmarlo digitalmente, con el fin de reducir el impacto de pequeñas modificaciones que puedan ocurrir durante la transmisión, como espacios repetidos o saltos de línea. Existen dos tipos de canonicalización: la simple, que requiere una coincidencia exacta entre el mensaje original y el recibido, y la relajada, 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 conserva en un registro DNS de tipo TXT cuyo nombre tiene la estructura selector._domainkey.domain, donde _domainkey es una etiqueta que indica que el registro DNS es efectivamente un registro DKIM. El contenido del registro DKIM consta de una serie de pares clave-valor que especifican elementos entre los cuales:

• 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 con el selector s1 del example.com , 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á configurado correctamente en los servidores de correo del remitente y del destinatario, el funcionamiento del proceso de autenticación y verificación DKIM garantiza que el servidor de correo del remitente cree la firma DKIM del mensaje, tal como se describe en el párrafo 5.2.1, la cual se agrega al propio mensaje. En concreto, la firma DKIM contiene en el d el dominio de firma¹⁷ y en el b la firma digital del mensaje generada con la clave privada del dominio de firma.

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

5.2.4. Aspectos criptográficos

En el ámbito criptográfico, DKIM ha utilizado históricamente el RSA , en particular la 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.

A nivel 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 al de RSA 2048. A pesar de estas ventajas, su uso en entornos reales es limitado: en 2026, Ed25519 solo está verificado por unos pocos proveedores, mientras que algunos operadores importantes no ofrecen soporte fiable ni para la firma ni para la verificación, lo que lo hace inadecuado como única solución en producción.

Por este motivo, a pesar de su superioridad técnica, 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 completamente su verificación, RSA sigue siendo esencial para garantizar la máxima seguridad en la entrega de mensajes.

En cuanto a la seguridad a largo plazo, es importante recordar que ni RSA ni Ed25519 son resistentes a los ataques de futuras computadoras cuánticas [3], y la transición hacia algoritmos post-cuánticos requerirá nuevos estándares DKIM que actualmente no existen, lo que hace esencial monitorear los desarrollos de criptografía de próxima generación y las futuras recomendaciones de ACN en esta área.

En lo que respecta a la gestión de claves criptográficas, la clave privada DKIM debe protegerse con rigurosas medidas de seguridad, manteniéndola en sistemas aislados accesibles únicamente a servicios autorizados, adoptando permisos restrictivos, rotación periódica y monitorización constante para evitar accesos no autorizados o vulneraciones de seguridad.

» Volver arriba

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance es un protocolo de autenticación, formalizado por RFC 7489, que integra^los mecanismos SPF y DKIM, permitiendo 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 superen 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 correspondiente al "message-from " del mensaje recibido. Cabe destacar que la comprobación de alineación entre el "message-from " y el dominio SPF/DKIM falla en cualquier caso si la verificación SPF/DKIM correspondiente también falla (véase la figura 4).

La alineación se puede verificar en estricto , donde se requiere una coincidencia exacta entre los dominios autenticados por SPF/DKIM y el correspondiente al message-from , o en modo relajado, donde basta con que los dominios principales coincidan, aunque los subdominios sean diferentes.

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

Mediante la verificación de alineación, incluso si un atacante lograra pasar las comprobaciones SPF y/o DKIM utilizando un mensaje-from diferente del sobre-from autenticado por SPF y/o del dominio de firma autenticado, DMARC seguiría detectando la discrepancia, asegurando una verificación coherente y fiable de la identidad del remitente [2].

Las políticas para gestionar los mensajes que no superan¹⁹ se especifican en un registro TXT del servidor DNS relativo del dominio del remitente, denominado registro DMARC, y se ilustran en la siguiente sección 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 provenir de dicho dominio. De esta forma, el propietario del dominio puede verificar si su dominio se está utilizando de forma no autorizada y en qué medida, analizando, por ejemplo, cuántos mensajes son realmente rastreables hasta él del total de mensajes que afirman provenir de ese dominio.

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

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

5.3.1. Registro DMARC

El nombre del registro DMARC tiene la 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 elementos entre los cuales:

• v: Protocolo DMARC versión²⁰;
• p: política que se aplicará a los mensajes que fallen la verificación DMARC, puede asumir uno de los valores none, quarantine, reject;
• 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 verificació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 superaron 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 con el dominio example.com , utiliza la versión 1 y especifica la política de rechazo para los mensajes que no superan la verificación DMARC, solicitando el modo estricto ( s ) para la verificación de la alineación de los dominios SPF y DKIM y para transmitir informes agregados a la dirección de correo electrónico dmarc-reports@example.com e informes de fallos a la dirección dmarc-fail@example.com .

5.3.2. Políticas DMARC

Como se describe 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 superan la verificación DMARC. Las políticas posibles son las siguientes:

• Ninguno: el dominio del remitente no proporciona ninguna indicación sobre la entrega de mensajes que no superen 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, sometidos a un examen más exhaustivo, tratados como spam o etiquetados como sospechosos);
• rechazar: el dominio del remitente indica que los mensajes que no superen la verificación DMARC deben ser rechazados.

5.3.3. Proceso de verificación y aplicación de la póliza

Si el protocolo DMARC está configurado correctamente 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 inicio del párrafo 5.2.4). En caso de que el mensaje no supere la verificación DMARC, se aplica la política indicada en el registro DMARC (ninguna, cuarentena o rechazo).

Cabe destacar que cada servidor de correo puede adoptar 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 SPF, DKIM y DMARC. Por lo tanto, generalmente existe un proceso de toma de decisiones adicional («Filtro estándar» en la Figura 5) posterior a las verificaciones mencionadas, que puede incluir comprobaciones adicionales (como, por ejemplo, filtros antispam y antimalware).

Además, el servidor de correo receptor puede transmitir:

• a las direcciones indicadas en el rua 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 del registro DMARC, se enviarán informes detallados sobre los mensajes individuales recibidos del dominio remitente que no superaron la verificación DMARC.

» Volver arriba

6. Conclusiones

Como se analizó en el capítulo anterior, para contrarrestar mejor las amenazas vinculadas a la suplantación de dominio del remitente es necesario que los tres protocolos examinados se implementen conjuntamente y, en particular, que [3]:

• El dominio remitente publica 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.

Con respecto a la implementación del protocolo, también se formulan las siguientes recomendaciones [2]:

• Configure SPF especificando qué direcciones IP están autorizadas a enviar correos electrónicos en nombre del dominio; para los dominios que no se utilizan para la transmisión de correo electrónico, por ejemplo, aquellos destinados exclusivamente a sitios web, se debe crear un registro SPF para indicar explícitamente que no hay remitentes de correo electrónico válidos para ese dominio;
• Utilice protocolos y algoritmos de cifrado de última generación considerados seguros para las claves DKIM; a la fecha de redacción de este documento, se recomienda RSA de 2048 bits;
• Proteger adecuadamente la clave privada DKIM almacenada en el servidor de correo, adoptando permisos de acceso restrictivos, y garantizar que solo el software del servidor de correo tenga privilegios de lectura sobre la clave;
• Configure cada servidor de correo con un par de claves y un selector únicos, con el fin de reducir el impacto de una posible vulneración de la clave privada;
• proteger la clave privada tanto de la divulgación accidental como de los intentos de acceso o modificación por parte de un atacante;
• estipule que el software relacionado con cualquier lista de correo verifique las firmas DKIM en los mensajes entrantes y adjunte nuevas firmas DKIM en los salientes;
• Utilice pares de claves DKIM únicos para cada tercero que envíe correos electrónicos en nombre de la organización;
• Rote periódicamente los pares de claves DKIM (al menos cada seis meses) para mitigar el impacto de una posible vulneración de seguridad;
• Revocar inmediatamente las claves en caso de sospecha de vulneración de seguridad;
• Supervise los informes de DMARC para identificar cualquier error de configuración o intento de abuso.

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

Se observa que, para proteger adecuadamente la seguridad del correo electrónico, además de los protocolos de autenticación aquí examinados, 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 SMIME y OpenPGP , que se refieren al cifrado de extremo a extremo y la autenticación de mensajes.

Cabe destacar que, si bien no se trata de un protocolo de seguridad de correo electrónico en sentido estricto, para garantizar la seguridad del servicio de correo electrónico se recomienda implementar DNSSEC (Domain Name System Security Extensions), una extensión del protocolo DNS que añade firmas criptográficas a los registros DNS para garantizar la integridad y autenticidad de las consultas DNS. Gracias a DNSSEC, por ejemplo, la información relativa a los registros SPF, DKIM y DMARC se protege 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 arriba

Apéndice A: Medidas de seguridad

Perímetro Nacional de Ciberseguridad (PSNC)

PR.IP-1: Se definen y gestionan prácticas de referencia (denominadas líneas 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. Existe un documento actualizado detallado que 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 de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
   • c) los procesos, metodologías y tecnologías empleadas 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 (denominadas líneas 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. Se definen políticas y procedimientos en relación con la seguridad de las aplicaciones para brindar el apoyo adecuado para la planificación, la implementación y el mantenimiento de las funciones de seguridad de las aplicaciones, las cuales deben revisarse y actualizarse al menos anualmente.
2. Existe un documento actualizado detallado que 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 de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
   • c) los procesos, metodologías y tecnologías empleadas que contribuyen al cumplimiento de las políticas de seguridad.
3. Se definen y documentan los requisitos básicos de seguridad para diversas aplicaciones.
4. Se definen e implementan métricas de carácter técnico útiles para supervisar el nivel de cumplimiento de los requisitos de seguridad y las obligaciones de cumplimiento establecidos.
5. Existe un proceso para la mitigación y recuperación de vulnerabilidades de las aplicaciones, con el fin de garantizar la seguridad de las mismas, automatizando la corrección cuando sea posible.
6. Existe un proceso para validar la compatibilidad de los dispositivos con los sistemas operativos y las aplicaciones.
7. Existe un sistema de gestión de variaciones en lo que respecta al sistema operativo, la aplicación de parches y/o las aplicaciones.

Regulación de la nube: servicios en la nube para la administración pública

PR.IP-01: Se definen y gestionan prácticas de referencia (denominadas líneas 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. Se definen políticas y procedimientos con referencia a la seguridad de las aplicaciones para brindar un soporte adecuado para la planificación, realización y mantenimiento de las características de seguridad de las aplicaciones, las cuales deben revisarse y actualizarse al menos anualmente [IaaS, SaaS].
2. Existe un documento actualizado detallado que 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 de control industrial y de TI y el despliegue únicamente de las configuraciones adoptadas;
   • b) la lista de configuraciones de sistemas de control industrial y de TI empleadas y la referencia a las prácticas de referencia relativas;
   • c) los procesos, metodologías y tecnologías empleadas que contribuyen al cumplimiento de las políticas de seguridad [SaaS].
3. Se definen y documentan los requisitos básicos de seguridad para diversas aplicaciones.
4. Se definen e implementan métricas de carácter técnico útiles para supervisar el nivel de cumplimiento de los requisitos de seguridad y las obligaciones de cumplimiento establecidos. 5. Existe un proceso para la mitigación y recuperación de vulnerabilidades de las aplicaciones, con el fin de garantizar la seguridad de las mismas y automatizar la corrección cuando 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 variaciones en términos de sistema operativo, parches y/o aplicaciones [PaaS, SaaS].

NIS 2

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

1. Para los sistemas de información y de red pertinentes, al menos, sus configuraciones básicas de seguridad (reforzadas) están definidas y documentadas en una lista actualizada.
2. En cumplimiento de las políticas a que se refiere la medida GV.PO-01, se adoptan y documentan procedimientos en relación con el punto 1.

» Volver arriba

Bibliografía

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

» Volver arriba