Correo electrónico cifrado: claves para elegir el mejor

La diferencia está en quién controla las claves y en qué momento se aplican.

Para seleccionar un correo electrónico seguro no basta con comprobar si aparece HTTPS en el navegador o si el proveedor anuncia «privacidad». Hay que auditar cinco capas: arquitectura de cifrado, jurisdicción, autenticación, código y tratamiento de metadatos. El resultado depende de la combinación. Un sistema con cifrado de extremo a extremo puede ofrecer una protección limitada si el asunto, los destinatarios o las copias de seguridad quedan expuestos.

Arquitectura de cifrado: TLS no equivale a privacidad completa

El protocolo TLS protege el transporte. Cifra la comunicación entre el cliente y el servidor de correo. Evita que un tercero conectado a la misma red pueda capturar directamente el contenido durante el tránsito. También dificulta la manipulación de la conexión.

TLS es necesario. No es suficiente.

En el correo convencional, el mensaje atraviesa varios servidores. La conexión entre el usuario y su proveedor puede estar cifrada, pero el proveedor recibe el contenido antes de almacenarlo y debe procesarlo para entregarlo. Además, la comunicación con el servidor del destinatario puede depender de otra sesión TLS. Si el dominio receptor no utiliza cifrado de transporte, la protección termina en el primer servidor.

El cifrado de extremo a extremo modifica esta arquitectura. El mensaje se cifra en el dispositivo del remitente y se descifra en el dispositivo del destinatario. El proveedor transporta datos cifrados, pero no debería disponer de la clave privada necesaria para leer el contenido.

La condición «no debería» exige precisión. El proveedor puede aplicar cifrado de extremo a extremo de varias formas:

• Cifrado controlado por el proveedor. El servicio genera o administra las claves. Protege frente a accesos externos a la infraestructura, pero mantiene una relación de confianza con la empresa.
• Cifrado basado en las credenciales del usuario. La clave se deriva de una contraseña o se protege con ella. Si el proveedor no conoce esa contraseña, su capacidad de descifrado es menor.
• Cifrado OpenPGP. El usuario controla las claves y puede comunicarse con otros clientes compatibles. A cambio, la configuración es más compleja y la gestión de claves recae en el usuario.
• Cifrado interno entre usuarios del mismo servicio. Puede funcionar de forma automática, pero no garantiza el mismo nivel de protección cuando el destinatario utiliza otro proveedor.
• Mensajes protegidos mediante enlace o contraseña. El contenido se almacena en una página segura y el destinatario recibe un enlace. Es útil para comunicaciones puntuales, pero no equivale siempre a un sistema completo de cifrado de extremo a extremo.

Una comparativa técnica debe separar estas capas:

La expresión «mejor correo seguro para privacidad» solo tiene sentido después de fijar el modelo de amenaza. Quien quiere evitar el rastreo comercial necesita controlar analítica, publicidad y reutilización de datos. Quien protege comunicaciones profesionales necesita además separar identidades, gestionar claves, preservar registros y definir una política de recuperación. Son problemas distintos.

El cifrado de la conexión impide que alguien observe el trayecto. El cifrado de extremo a extremo limita quién puede leer el contenido. Confundir ambas funciones produce una falsa sensación de seguridad.

Qué debe comprobarse en la práctica

La documentación técnica del proveedor debe responder a preguntas concretas:

1. ¿El contenido se cifra antes de abandonar el dispositivo?

2. ¿El proveedor puede restablecer la contraseña y recuperar los mensajes?

3. ¿La clave privada permanece bajo control del usuario?

4. ¿Los adjuntos reciben la misma protección que el cuerpo del mensaje?

5. ¿El asunto se cifra o queda visible para enrutar y clasificar el mensaje?

6. ¿Las búsquedas se ejecutan localmente o en los servidores?

7. ¿El sistema funciona con destinatarios externos?

8. ¿Qué ocurre si se pierde la contraseña o la clave privada?

La respuesta «utilizamos cifrado de 256 bits» no resuelve ninguna de estas cuestiones por sí sola. El algoritmo y la longitud de la clave describen una propiedad criptográfica. No describen quién tiene acceso a la clave, cómo se gestiona la recuperación ni qué datos se almacenan.

Jurisdicción y soberanía de datos: el país no lo explica todo

La localización de los servidores es relevante, pero no determina por sí sola la exposición legal. Hay que distinguir tres elementos:

• El país donde está constituida la empresa.
• El territorio donde se encuentran los centros de datos.
• La ley aplicable al servicio y a sus subcontratistas.

Una compañía registrada en un país puede utilizar infraestructura de otra jurisdicción. También puede conservar claves, copias de seguridad o sistemas de soporte en territorios diferentes. La política de privacidad debe indicar, con el nivel de detalle disponible, qué entidades procesan los datos y para qué finalidad.

En la Unión Europea, el Reglamento General de Protección de Datos establece obligaciones sobre tratamiento, transparencia, base jurídica, derechos de los interesados y transferencias internacionales. No convierte automáticamente un servicio en anónimo ni impide todos los accesos legales. Tampoco sustituye al cifrado de extremo a extremo. El cumplimiento normativo y la confidencialidad criptográfica son controles distintos.

La jurisdicción afecta a la posibilidad de recibir órdenes de entrega de datos, al alcance de las obligaciones de conservación y al procedimiento para impugnar una solicitud. El cifrado reduce la utilidad de una entrega si el proveedor no posee las claves. Pero los metadatos pueden seguir disponibles aunque el cuerpo del mensaje sea ilegible.

Conviene leer cuatro documentos, no solo la página comercial:

Política de privacidad

Debe describir las categorías de datos tratadas. Busque referencias a:

• Dirección IP y registros de acceso.
• Identificadores de dispositivo.
• Datos de recuperación de la cuenta.
• Direcciones de remitentes y destinatarios.
• Asuntos y marcas temporales.
• Registros de errores y actividad.
• Proveedores de analítica, soporte y almacenamiento.
• Plazos de conservación y procedimientos de eliminación.

Una política que utiliza la fórmula «podemos recopilar información adicional» sin concretar qué información, en qué circunstancias y durante cuánto tiempo no permite una auditoría razonable.

Informe de transparencia

Este documento puede indicar cuántas solicitudes de información recibe el proveedor, qué solicitudes atiende y qué datos puede entregar. No demuestra que el servicio sea técnicamente incapaz de descifrar mensajes, pero ayuda a evaluar su comportamiento operativo.

Política de registros

«Sin registros» no es una descripción técnica suficiente. Puede significar que no se conserva la IP después de una sesión, que no se almacenan registros de lectura o que no se construye un perfil publicitario. Son afirmaciones diferentes.

Condiciones de recuperación y eliminación

El usuario debe saber si una contraseña olvidada puede ser restablecida por el proveedor. Si la respuesta es afirmativa, hay que determinar si ese proceso permite recuperar también el contenido cifrado. En los diseños de conocimiento cero, la recuperación suele tener un coste: se puede recuperar el acceso a la cuenta, pero no necesariamente los mensajes protegidos con una clave que ya no existe.

La soberanía de datos tampoco consiste en elegir un servidor cercano. Un centro de datos situado en el mismo país puede estar administrado por una empresa extranjera y conectado a servicios externos. La evaluación debe seguir la cadena de control, no la geografía aislada.

El registro sin número de teléfono tiene ventajas y límites

Un correo electrónico seguro sin número de teléfono reduce la vinculación directa entre la cuenta y una identidad telefónica. También evita que el número se convierta en un identificador permanente para recuperación, prevención del fraude o correlación entre servicios.

No elimina el riesgo de identificación.

El proveedor puede utilizar otros controles: dirección IP, cookies, huella del navegador, dirección de recuperación, método de pago, dispositivo utilizado o patrones de actividad. Además, la identidad puede quedar expuesta por el propio contenido de los mensajes, la firma, los documentos adjuntos o los destinatarios.

La ausencia de número de teléfono debe analizarse junto con el proceso de alta. Hay tres escenarios frecuentes:

1. Registro sin verificación adicional. Permite crear la cuenta con un nombre de usuario y una contraseña. Puede existir un sistema antifraude basado en señales técnicas.

2. Verificación condicional. El servicio no exige siempre un teléfono, pero puede solicitar una dirección alternativa, un CAPTCHA o una comprobación adicional cuando detecta actividad automatizada.

3. Número obligatorio. El teléfono se utiliza para validar la cuenta, recuperarla o aplicar controles contra el abuso.

La segunda opción no equivale a anonimato. Solo indica que el número no es un requisito universal.

Recuperación frente a confidencialidad

La recuperación de cuenta introduce una tensión técnica. Cuantos más mecanismos tenga el proveedor para devolver el acceso, mayor puede ser su capacidad para intervenir en la arquitectura de claves. Un correo electrónico con cifrado fuerte puede perder parte de ese diseño si la empresa conserva una vía centralizada para reconstruir la clave privada.

El usuario debe decidir qué riesgo prioriza:

• Perder el acceso de forma irreversible.
• Permitir una recuperación administrada por el proveedor.
• Guardar una clave de recuperación fuera del servicio.
• Utilizar un gestor de contraseñas y un mecanismo de emergencia separado.

La opción más robusta para comunicaciones sensibles suele exigir disciplina operativa. La contraseña debe ser única y extensa. La autenticación multifactor debe utilizar una aplicación de códigos o una llave física cuando sea posible. Los códigos de recuperación deben almacenarse fuera del buzón. El correo alternativo no debe convertirse en un punto único de fallo.

La autenticación en dos pasos no cifra los mensajes. Protege el acceso a la cuenta. Si un atacante obtiene la contraseña pero no el segundo factor, el acceso resulta más difícil. Si el dispositivo ya está desbloqueado o la sesión permanece abierta, el segundo factor no protege el contenido visible en pantalla.

Código abierto y auditorías: transparencia verificable

El código abierto permite inspeccionar determinadas partes del sistema. No garantiza que toda la infraestructura sea reproducible ni que el código publicado coincida con el que ejecuta el servidor. La afirmación correcta debe especificar qué componentes están disponibles:

• Aplicaciones móviles.
• Cliente web.
• Aplicaciones de escritorio.
• Bibliotecas criptográficas.
• Servidores de correo.
• Herramientas de importación y exportación.
• Sistemas de generación y almacenamiento de claves.

Un cliente abierto facilita el análisis de cómo se cifran los mensajes en el dispositivo. No demuestra por sí mismo que el proveedor no pueda acceder a los datos del servidor. Para ello hay que revisar la arquitectura completa y los controles de claves.

Las auditorías externas añaden una capa de verificación. Su valor depende del alcance, la fecha y la independencia del auditor. Una revisión limitada de la aplicación web no permite concluir que toda la plataforma sea segura. Un informe sobre controles organizativos tampoco equivale a una auditoría criptográfica.

Al leer un informe, conviene localizar:

• Alcance exacto del trabajo.
• Sistemas incluidos y excluidos.
• Periodo de revisión.
• Metodología aplicada.
• Vulnerabilidades encontradas.
• Estado de las correcciones.
• Limitaciones expresas.
• Revisión de terceros y gestión de proveedores.

No es correcto interpretar «auditado» como «sin vulnerabilidades». Una auditoría es una fotografía acotada. Sirve para identificar fallos y comprobar controles, pero no elimina el riesgo de nuevas vulnerabilidades, errores de configuración o compromisos de la cadena de suministro.

Criptografía propia frente a estándares

Un proveedor puede desarrollar una interfaz sencilla sobre protocolos conocidos, como TLS, S/MIME u OpenPGP. También puede utilizar un diseño propietario para automatizar el cifrado entre usuarios de su plataforma. La comodidad puede aumentar, pero la interoperabilidad disminuye.

El correo cifrado debe evaluarse en dos direcciones:

• Confidencialidad entre usuarios del mismo servicio. Normalmente es más sencilla de activar.
• Confidencialidad frente a usuarios externos. Puede requerir OpenPGP, un portal seguro o una contraseña compartida por un canal independiente.

La clave compartida nunca debe enviarse en el mismo mensaje que el enlace protegido. Si ambos elementos viajan juntos, el atacante que intercepte la cuenta o el buzón puede obtener el contenido.

OpenPGP ofrece control directo de las claves y evita depender completamente de un único proveedor. Sus problemas son operativos: pérdida de claves, errores al verificar huellas, rotación insuficiente y dificultad para utilizar varios dispositivos. La seguridad real cae cuando el usuario no puede distinguir una clave auténtica de otra manipulada.

Metadatos y anonimato: el contenido no es todo

El cuerpo del mensaje puede estar cifrado y seguir existiendo un registro detallado de la comunicación. Los metadatos incluyen información necesaria para operar el sistema:

• Dirección del remitente.
• Dirección del destinatario.
• Fecha y hora de envío.
• Tamaño del mensaje.
• Dominio de origen y destino.
• Dirección IP en determinados escenarios.
• Estado de entrega.
• Asunto, según el diseño.
• Dispositivos y sesiones de acceso.

El proveedor necesita conocer parte de estos datos para enrutar el correo. El cifrado no puede ocultar por completo al servidor que debe entregar un mensaje a una dirección concreta. La cuestión es cuánto conserva, durante cuánto tiempo y para qué lo utiliza.

El asunto merece una revisión específica. Muchos sistemas cifran el cuerpo y los adjuntos, pero mantienen visible el asunto para facilitar búsquedas, clasificación o compatibilidad. Un asunto como «informe médico», «negociación laboral» o «reunión con el abogado» puede revelar información sensible aunque el contenido esté protegido.

También existen metadatos en los adjuntos. Un documento de imagen puede incorporar datos EXIF. Un archivo ofimático puede contener el nombre del autor, historial de edición o información del dispositivo. El proveedor puede cifrar el archivo sin eliminar esos datos. La protección del correo no sustituye a la limpieza documental.

Rastreo comercial y píxeles de seguimiento

El rastreo no depende únicamente del acceso al contenido. Los mensajes HTML pueden incluir imágenes remotas, enlaces identificables y elementos que notifican la apertura o el acceso. El proveedor de correo puede bloquear la carga automática de imágenes, aislarlas mediante proxy o advertir de enlaces sospechosos.

Estas funciones tienen efectos distintos:

• Bloqueo local. El cliente no descarga el recurso hasta que el usuario lo permite.
• Proxy del proveedor. El servidor descarga la imagen y la entrega desde una dirección intermedia. Oculta parte de la información del destinatario, pero el proveedor puede conocer la carga.
• Desactivación de HTML. Reduce el rastreo, aunque afecta al formato de algunos mensajes.
• Protección de enlaces. Analiza o reescribe la dirección. Puede mejorar la detección de amenazas, pero introduce procesamiento adicional.

Para reducir el rastreo, el usuario debe configurar la carga de imágenes y revisar los enlaces antes de abrirlos. El cifrado protege el canal y el contenido; no convierte en fiable una campaña comercial ni elimina las técnicas de identificación incluidas en el mensaje.

La privacidad del correo se pierde por acumulación: asunto visible, IP conservada, dirección de recuperación, imágenes remotas y una contraseña reutilizada pueden revelar más que una debilidad del algoritmo.

Cómo comparar proveedores sin convertir la decisión en una clasificación

Una comparativa de proveedores de email cifrado debe medir capacidades concretas. No conviene asignar una posición global a servicios que resuelven problemas diferentes. Un proveedor puede destacar por la interoperabilidad con OpenPGP y otro por la simplicidad del cifrado automático. La elección depende del uso.

Esta matriz permite ordenar la revisión:

La exportación es un criterio infravalorado. Un servicio puede ofrecer buen cifrado y, al mismo tiempo, dificultar la migración. El usuario debe saber si puede descargar mensajes mediante IMAP, exportar contactos, guardar claves y revocar sesiones. La portabilidad reduce la dependencia tecnológica y permite cambiar de proveedor sin perder el archivo de comunicaciones.

Compatibilidad con otros sistemas

La seguridad puede degradarse al enviar mensajes a un buzón convencional. El proveedor debe explicar qué ocurre en ese caso. Las opciones habituales son:

• Envío mediante TLS si el servidor receptor lo admite.
• Cifrado OpenPGP cuando existe una clave pública verificada.
• Portal protegido con contraseña.
• Envío convencional con una advertencia de pérdida de protección.

La última opción no es un fallo si está claramente indicada. El problema aparece cuando la interfaz presenta todos los envíos como igualmente privados.

Para comunicaciones sensibles, la clave del destinatario debe verificarse por un canal independiente. No basta con descargar automáticamente una clave asociada a una dirección. Hay que comprobar su huella, confirmar el cambio de clave y revisar las alertas de suplantación.

Errores técnicos que reducen el nivel de protección

La mayoría de incidentes no requieren romper la criptografía. Se producen por configuración, reutilización de credenciales o exposición del extremo.

Los errores más frecuentes son estos:

1. Confundir el candado del navegador con cifrado de extremo a extremo. El candado certifica una conexión protegida. No prueba que el proveedor sea incapaz de leer el contenido.

2. Reutilizar la contraseña del correo. Una filtración en otro servicio puede abrir el buzón. La contraseña debe ser exclusiva y almacenarse en un gestor fiable.

3. Guardar la clave privada en un dispositivo sin protección. El cifrado deja de ser eficaz si el móvil o el ordenador está desbloqueado, infectado o configurado para sincronizar el contenido sin control.

4. Enviar la contraseña junto al mensaje protegido. El canal de entrega debe ser distinto. Una llamada o una aplicación de mensajería con autenticación independiente puede cumplir esa función.

5. No conservar una copia de recuperación. En un sistema de conocimiento cero, la pérdida de la clave puede impedir recuperar los mensajes.

6. Usar una dirección de recuperación identificable. La cuenta puede quedar vinculada a la identidad que se pretendía separar.

7. Mantener imágenes remotas activadas. La carga puede confirmar la apertura de un mensaje y revelar información de red.

8. Ignorar el asunto y los destinatarios. El cuerpo cifrado no oculta necesariamente la estructura de la comunicación.

9. No revocar sesiones antiguas. Un dispositivo perdido puede conservar acceso aunque se cambie la contraseña.

10. Aceptar claves sin verificar. La criptografía protege una comunicación solo si la clave pertenece realmente al destinatario.

El último punto exige una política de ciclo de vida. Las claves deben generarse, almacenarse, verificarse, renovarse y revocarse. En un uso personal ocasional, esta gestión puede resultar excesiva. En una organización, no hacerla produce un riesgo operativo medible.

Un procedimiento de elección y configuración

La selección puede hacerse en un orden concreto. El objetivo no es elegir el servicio con más funciones, sino eliminar los riesgos que afectan al caso de uso.

1. Definir el contenido que se protegerá

No necesita la misma arquitectura quien quiere evitar publicidad basada en el correo que quien gestiona expedientes con datos personales. Clasifique los mensajes por sensibilidad y por obligación de conservación.

2. Determinar el nivel de anonimato

Separe privacidad del contenido y ocultación de identidad. Si necesita desvincular una cuenta de un número de teléfono, compruebe también IP, recuperación, pagos y dispositivos. No utilice la palabra «anónimo» si el modelo solo elimina un identificador.

3. Revisar las claves

Compruebe si el proveedor puede descifrar los mensajes, si permite exportar las claves y qué ocurre al restablecer la contraseña. La respuesta debe estar documentada. Si la arquitectura es ambigua, trate el servicio como un sistema de confianza en el proveedor.

4. Auditar los metadatos

Lea la política de registros y examine el tratamiento del asunto, las direcciones, los tiempos de entrega y las conexiones. La ausencia de anuncios no equivale a ausencia de registros.

5. Comprobar el envío externo

Realice una prueba con un destinatario de otro proveedor. Verifique qué se cifra, qué instrucciones recibe el destinatario y si el sistema permite recuperar el mensaje desde un dispositivo distinto.

6. Activar la autenticación multifactor

Priorice una aplicación de códigos o una llave de seguridad. Guarde los códigos de recuperación fuera del buzón. Revise las sesiones activas y elimine dispositivos que ya no utilice.

7. Configurar el cliente

Desactive la carga automática de imágenes si la prioridad es reducir el rastreo. Revise la visualización de HTML. Configure el bloqueo de enlaces peligrosos sin aceptar que el análisis centralizado se presente como cifrado.

8. Probar la salida

Descargue una copia de los mensajes, compruebe el formato y confirme que puede migrar contactos y claves. Un servicio sin salida documentada crea dependencia incluso cuando su arquitectura criptográfica es correcta.

El resultado debe quedar registrado. En una organización, documente el proveedor, la jurisdicción, las claves admitidas, la política de recuperación y el procedimiento de baja. En una cuenta personal, mantenga al menos la contraseña, los códigos de emergencia y la clave de recuperación en ubicaciones separadas.

Evaluación de impacto a corto y medio plazo

A corto plazo, cambiar a un servicio de correo con cifrado fuerte reduce tres exposiciones: la lectura por intermediarios durante el transporte, el acceso del proveedor al contenido almacenado —si la arquitectura es de extremo a extremo— y el perfilado comercial basado en el correo. También obliga a gestionar mejor las claves y la recuperación.

A medio plazo, el impacto depende de la interoperabilidad. Si la mayoría de los destinatarios utiliza servicios convencionales, parte de la protección termina en el envío externo. Si la organización no controla dispositivos, copias locales y cuentas de recuperación, el cifrado del servidor no cubre el punto final. Si se pierde la clave privada, la disponibilidad puede verse comprometida.

La decisión técnica puede resumirse así:

• Para reducir el rastreo comercial: política de registros limitada, sin publicidad basada en el contenido, bloqueo de imágenes y control de enlaces.
• Para proteger el contenido frente al proveedor: cifrado de extremo a extremo con claves bajo control del usuario.
• Para mantener compatibilidad: OpenPGP, S/MIME o portal seguro con una política clara para destinatarios externos.
• Para reducir la vinculación de identidad: alta sin número de teléfono, recuperación independiente y separación de dispositivos.
• Para preservar la continuidad: exportación de mensajes, copia de claves y procedimiento de migración.

El mejor correo electrónico no es el que utiliza más veces la palabra «cifrado». Es el que permite cuantificar qué protege, quién controla las claves, qué metadatos conserva y cómo se comporta fuera de su propia plataforma. La selección debe basarse en esa arquitectura. El marketing solo describe una intención; la política de claves, los registros y la interoperabilidad muestran el nivel real de privacidad.