Cómo configurar un sistema de correo seguro para proteger la entregabilidad y evitar la suplantación de identidad

Configurar correctamente un sistema de correo es esencial para garantizar la entregabilidad de los emails, prevenir la suplantación de identidad y protegerse de los cibercriminales. A principios de año, Google y Yahoo han reforzado sus controles técnicos sobre los correos electrónicos, mientras que Microsoft, por su parte, continúa perfeccionando sus sistemas EOP y Defender, ofreciendo un análisis aún más profundo del contenido de los mensajes. Entonces, ¿cuáles son los puntos clave a vigilar para asegurar sus comunicaciones por email?

La historia del email y la evolución de las amenazas en línea

Si el concepto de intercambio de mensajes electrónicos surge en 1961, es en 1982 cuando aparece el email basado en el protocolo SMTP tal como lo conocemos hoy. En esa época, se trataba de enviar mensajes a través de la red ARPANET que conectaba a investigadores universitarios, institutos de investigación y laboratorios militares estadounidenses entre sí. El protocolo SMTP, diseñado con cierta ingenuidad, no incorporaba las preocupaciones actuales en materia de seguridad, ya que estaba destinado a una red restringida, utilizada principalmente para el intercambio de datos científicos. Así, el remitente era responsable de declarar quién era y ninguna autoridad tenía la misión de certificar su identidad. En otras palabras, el remitente podía hacerse pasar libremente por bill.gates@microsoft.com o bill.clinton@whitehouse.com y no existía ningún mecanismo que permitiera al destinatario verificar esa información.

Con la aparición de Internet en la década de 1990 y su adopción masiva por el público y las empresas, la situación cambió radicalmente. Al ser una red mundial accesible para todos, Internet se convirtió rápidamente en un terreno fértil para las actividades delictivas en línea. Mientras que la ciberdelincuencia, que antes era inexistente, experimentó una explosión exponencial, el protocolo SMTP no siguió esa evolución. Al momento de publicación de este artículo, el remitente sigue siendo el único responsable de declarar su identidad, y no se ha establecido ninguna autoridad centralizada para ayudar a los destinatarios a verificar la autenticidad de los remitentes.

Para responder a este problema, ingenieros y empresas privadas han inventado mecanismos adicionales que refuerzan la seguridad de los correos electrónicos. Entre ellos, los estándares SPF, DKIM y DMARC se han impuesto como protocolos imprescindibles para asegurar la protección y la integridad de los sistemas de mensajería.

¿Qué es el SPF y cómo configurarlo para su dominio?

El Sender Policy Framework (SPF) es un mecanismo que permite al servidor receptor verificar que el servidor SMTP remitente ha sido autorizado por el propietario del dominio para enviar correos electrónicos. En otras palabras, un propietario de dominio como microsoft.com debe declarar las IP de los servidores SMTP autorizados para enviar correos electrónicos.

Explicación técnica del mecanismo: cuando un servidor SMTP recibe un correo, este consulta los DNS del dominio del remitente para encontrar la línea SPF. De esta manera, verifica que la IP del servidor SMTP que le ha transmitido el correo esté listada en dicho registro.

¿Cómo configurar el SPF de mi dominio? Inicie sesión en su registrador o en su servidor DNS y edite las zonas DNS. Si existe una línea TXT que comience por v=spf1, edítela; de lo contrario, créela. Asegúrese de que solo haya una línea SPF para el dominio.

Si desea autorizar un servidor dedicado para enviar correos electrónicos, añada su IP de la siguiente manera:

v=spf1 ip4:211.85.89.12 ~all

Si desea autorizar un rango de IP:

v=spf1 ip4:211.85.89.0/24 ~all

Para autorizar varias IP, basta con escribirlas seguidas:

v=spf1 ip4:211.85.89.12 ip4:197.53.25.16 ip4:88.85.15.251 ~all

Autorizar una IPv6:

v=spf1 ip6:3ffe:8007:0000:2201:0200:f8df:fe75:50df ~all

Si utiliza Google, Microsoft u otro producto para enviar sus correos, generalmente se incluyen registros SPF que contienen todas las IP a autorizar. Así es como se agregan:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Consulte la Lista de servidores SPF de los servicios en línea más populares.

Para autorizar las IP de sus registros A y MX para enviar correos, puede añadir los siguientes argumentos:

v=spf1 ip4:211.85.89.12 a mx ~all

Un SPF puede combinar múltiples productos y servidores autorizados para enviar correos para su dominio:

v=spf1 ip4:211.85.89.0/24 ip4:88.45.85.67 include:_spf.google.com a mx ~all

Atención: para no dañar la reputación online de su dominio, se recomienda no exceder de 10 IP/rango/SPF diferentes. De hecho, un dominio que multiplique los medios de envío de correo podría ser asimilado a una organización dedicada al SPAM.

Notemos que este mecanismo presenta una debilidad no despreciable. De hecho, cuando autoriza a los servidores de una herramienta de mensajería como Google o a una herramienta de email marketing como Mailjet a enviar correos para su dominio, las organizaciones cibercriminales solo tendrán que usar los mismos sistemas para suplantar su identidad y llevar a cabo operaciones de phishing y spoofing. Esa debilidad es la que justifica la creación del DKIM.

¿Qué es el DKIM y cómo protege sus correos?

El DomainKeys Identified Mail (DKIM) es un mecanismo que permite al servidor receptor asegurarse de que el correo que acaba de recibir está realmente autorizado por el propietario del dominio. Concretamente, el servidor que emite el correo inserta una firma criptográfica generada con una clave privada. El servidor que recibe el correo verifica que un registro DNS contiene la clave pública correspondiente y la utiliza para descifrar la firma. Si la clave logra verificar esa firma, significa que el sistema remitente ha sido configurado correctamente por el propietario del dominio. Recordemos que no es posible deducir la clave privada a partir de la clave pública.

¿Cómo configurar el DKIM de mi dominio? Comience generando una clave privada desde el sistema que desea autorizar para enviar correos electrónicos.

Si se trata de un servidor de correo en Linux, utilice openssl para generar las claves privadas y públicas con los siguientes comandos.

openssl genrsa -out private.key 1024
openssl rsa -in private.key -pubout -out public.key

Para obtener más información, puede consultar la documentación oficial de OpenSSL

Luego, instale la clave privada que se encuentra en el archivo private.key en el producto encargado de enviar los correos electrónicos.

Si se trata de un producto como Google Workspace o Microsoft Office365, genere la clave a partir de la herramienta.

En cualquier caso, inicie sesión en su registrador o en su servidor DNS y agregue un registro de tipo TXT con el selector asociado a la herramienta.

google._domainkey.yourdomain.com

Consulte la Lista de servidores DKIM de los servicios en línea más populares.

Luego, copie el valor de la clave pública contenida en el archivo public.key o proporcionada por el producto utilizado.

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB4QUAA4GNADCBiQKBgQDL6joZwa33IP8oFEQW3d1oAZxKFYXlyoXWUbSExWH8L1J
soGIhwmR30M6WM+F7U8QeYZ9PwikvccjNDtBIZK/XjfIznmOVEKFlygm/33fVpTSMI7n2P8laUcxu4G93i1J9IO0Ekmx8lhPFXJ0e
O24amjN6jlSlRsAf0/SNMJZeSwIDAQAB

A diferencia del SPF, es necesario agregar un registro DKIM por cada sistema autorizado para enviar correos electrónicos.

Atención: algunos registradores no aceptan claves superiores a 1024 bits y, al mismo tiempo, algunos proveedores de correo como Yahoo penalizan las claves de menos de 1024 bits. Por lo tanto, parecería que 1024 bits es la configuración más adecuada.

Este mecanismo parece más robusto que el SPF, pero no puede reemplazarlo. De hecho, si un hacker llegara a robar su clave privada, sin el mecanismo SPF podría utilizarla desde cualquier servidor para sus actividades delictivas. La solidez de un sistema de correo radica, por tanto, en la combinación de estos dos mecanismos y en la dificultad para que un cibercriminal pueda corromper ambos.

¿Qué es el DMARC?

El Domain-based Message Authentication, Reporting & Conformance (DMARC) podría definirse como la política de correo deseada por el propietario del dominio. Este mecanismo tiene un doble propósito:

El primero es monitorizar los correos recibidos por todos los sistemas de correo y cuyo remitente se ha presentado como parte de su dominio. De esta manera, recibirá, cada día, informes de cada sistema que haya recibido sus correos.

El segundo es poder dar directrices a los sistemas que reciben correos con un remitente de su dominio pero con una configuración incorrecta. Por ejemplo, es posible recomendar el rechazo de los correos de su dominio si estos no cumplen con los DKIM o los SPF.

Explicación técnica del mecanismo: cuando un servidor SMTP recibe un correo, verifica su conformidad con SPF y DKIM como se describió anteriormente, luego consulta nuevamente los servidores DNS para recuperar el DMARC y conocer la política de correo del propietario del dominio. Por un lado, el servidor receptor enviará un informe sobre el correo recibido a la dirección que usted haya especificado en este registro. Por otro, aplicará las reglas del dominio si el correo no cumple perfectamente con los requisitos.

Ejemplo de configuración:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=r

Aquí, p designa la acción aplicada al correo si no cumple con las restricciones definidas con adkim y aspf. Los valores posibles son reject, quarantine, none

rua permite especificar el correo que recibirá los informes. Estos se recibirán de forma agrupada cada 24 horas. Dichos informes pueden leerse con herramientas de análisis específicas.

adkim especifica el nivel de conformidad esperado para DKIM. Los valores posibles son "r" (relaxed) y "s" (strict). En modo relaxed, una firma DKIM es válida si el subdominio del remitente coincide con el dominio DKIM firmado. En modo strict, solo se acepta una coincidencia exacta del dominio.

aspf especifica el nivel de conformidad esperado para SPF. Los valores posibles son "r" (relaxed) y "s" (strict). En modo relaxed, un correo se considera conforme si el remitente pertenece al mismo dominio principal. En modo strict, solo se acepta un registro SPF con una coincidencia exacta del dominio.

Atención: si bien los DMARC son directrices deseadas por los propietarios de los dominios, en ningún caso son una obligación de ejecución. El servidor receptor puede decidir aplicar reglas más estrictas o más indulgentes que las definidas en los DNS.

¿El contenido del correo juega un papel en la seguridad?

Con el fin de combatir activamente la ciberdelincuencia, están surgiendo nuevos mecanismos. Es el caso, por ejemplo, de Microsoft, que desarrolla las herramientas Exchange Online Protection (EOP) y Defender, que realizan una segunda serie de controles centrados en el contenido del correo. Así, los enlaces contenidos en los correos y los archivos adjuntos se escanean para detectar contenido malicioso.

En esta misma línea, los análisis semánticos se están generalizando para detectar el SPAM y los intentos de estafa. Por ello, se recomienda evitar el campo léxico que utilizaría una organización malintencionada como: «Gratis», «Ganar dinero», «Urgente», «Haga clic aquí», «Oferta especial» y símbolos excesivos como series de signos de exclamación o mayúsculas para llamar la atención, por ejemplo, «¡GRATIS!!!».

En conclusión

En conclusión, el protocolo de correo nació en una época de despreocupación y, por lo tanto, no fue dotado de mecanismos eficientes para la identificación del remitente. Estos mecanismos se han añadido en varias capas a lo largo del tiempo con SPF, DKIM y DMARC, que buscan garantizar la autenticidad de los mensajes y reducir el phishing y el spam.

El SPF permite definir los servidores autorizados para enviar correos para un dominio, el DKIM asegura la integridad del mensaje mediante una firma criptográfica, y el DMARC orquesta estos dos protocolos proporcionando reglas de validación e informes de conformidad.

Sin embargo, su implementación y gestión requieren una configuración rigurosa para evitar falsos positivos o fallos en la entrega legítima. En un contexto donde los ciberataques son cada vez más sofisticados, estas tecnologías se han vuelto esenciales para cualquier organización preocupada por la seguridad y la fiabilidad de sus comunicaciones electrónicas.

Más información

SPF (Sender Policy Framework)
Iniciativa: Meng Weng Wong es el responsable del desarrollo de SPF en 2000. Wong es un empresario y experto en seguridad informática que creó SPF para combatir la suplantación de identidad por email (phishing) y el spam.
Organización: SPF fue inicialmente desarrollado por Pobox.com, un proveedor de servicios de email fundado por Meng Weng Wong. Posteriormente, fue asumido por una comunidad de desarrolladores y normalizado mediante la RFC4408 en 2006. En 2014 se publicó una actualización bajo la RFC7208

DKIM (DomainKeys Identified Mail)
Iniciativa: DKIM surge de la fusión de dos tecnologías anteriores:
DomainKeys, desarrollado por Yahoo! en 2004.
Identified Internet Mail, desarrollado por Cisco Systems.
Organización: DKIM fue diseñado para firmar digitalmente los correos, asegurando que el email provenga del dominio declarado y que no haya sido modificado en tránsito. En 2007, la norma DKIM fue publicada bajo la RFC 4871 y adoptada por el Internet Engineering Task Force (IETF). Una primera actualización fue publicada en 2009 bajo la RFC5672 y luego en 2011, se publicó la RFC6376.

DMARC (Domain-based Message Authentication, Reporting & Conformance)
Iniciativa: DMARC fue desarrollado por un consorcio de empresas que incluye:
> Google
> Yahoo!
> AOL
> Microsoft
> Facebook
> PayPal (en particular, Brett McDowell, un experto en seguridad de PayPal, que jugó un papel clave en el desarrollo inicial).
Organización: El desarrollo de DMARC comenzó en 2011, y fue publicado oficialmente en enero de 2012. El objetivo era mejorar la compatibilidad de SPF y DKIM y ofrecer un mecanismo de reporte que permitiera a los propietarios de dominios indicar a los servidores receptores cómo gestionar los correos que fallan las verificaciones de autenticidad. DMARC es un estándar publicado en la RFC7489 y en el sitio oficial DMARC.org

Esta situación desestabilizadora puede ocurrir a cualquier organización honesta. En primer lugar, es necesario mantener la calma y analizar progresivamente las causas de estos rechazos. A continuación, la estrategia a seguir:
> Google
> Yahoo!
> AOL
> Microsoft

Para verificar la configuración de SPF, DKIM y DMARC existen 2 métodos simples.


Método 1: envíe un correo desde el sistema a probar a una dirección de Google (una cuenta gratuita de Gmail es suficiente).
Desde el correo recibido, haga clic en los 3 puntos en la esquina superior derecha y luego en "Mostrar original"

Luego, verifique que las 3 líneas SPF, DKIM y DMARC estén correctamente calificadas como "PASS"


Método 2: El sitio Mail Tester permite probar su configuración enviando un correo a un alias creado al instante. Visite el siguiente enlace y siga las instrucciones: Mail Tester

Nuestros expertos analizarán su sistema y le proporcionarán el soporte necesario para ponerlo en conformidad y sacar a su organización de una situación de crisis.

¿Necesita ayuda para configurar su sistema de correo?

Equipo de Syskeo

El equipo de Syskeo está compuesto por profesionales apasionados y experimentados. Nuestro equipo multidisciplinario trabaja en sinergia para ofrecer soluciones de alta calidad, basadas en los últimos avances tecnológicos y las mejores prácticas de la industria.