Los correos electrónicos suelen compararse con una postal: quien lee por el camino, lo ve todo. El cifrado de correo electrónico decide si eso es cierto. Este artículo describe qué logran el cifrado de transporte y el cifrado de extremo a extremo, qué han dicho al respecto los tribunales y las autoridades de control y qué tecnología marca la diferencia en la práctica.
El artículo tiene en cuenta sentencias, tecnología y obligaciones de los grandes proveedores de correo hasta finales de octubre de 2026.
La estructura del artículo sigue el recorrido de un correo. Primero vienen el criterio y los conceptos, después la jurisprudencia y la visión de las autoridades de control. A continuación se trata la técnica: cifrado de transporte, comprobación en la cabecera del correo, protección frente a remitentes falsificados y procedimientos de extremo a extremo como S/MIME y OpenPGP. Al final hay una guía de decisión sobre qué cifrado conviene a cada tipo de correo.
Cifrado de correo electrónico y RGPD: cuál es el criterio
Los datos personales deben tratarse de modo que estén protegidos frente a accesos no autorizados. Así lo establece el art. 5, apdo. 1, letra f del RGPD. Según el apartado 2, el responsable debe poder demostrarlo. Cómo se concreta esa protección lo regula el art. 32 del RGPD: hay que adoptar medidas conforme al estado de la técnica y adecuadas al riesgo. La norma no prescribe un procedimiento determinado. El cifrado solo se menciona allí como medida posible.
Las categorías especiales de datos, como los datos de salud, están comprendidas en el art. 9 del RGPD. Allí la necesidad de protección es mayor desde el principio. Pero también los correos aparentemente inofensivos contienen datos personales: basta con la dirección del remitente con nombre y apellidos.
En 2026 la situación jurídica puede resumirse así: no existe una obligación general de cifrado de extremo a extremo para todos los correos. Tampoco existe una autorización general para enviar correos sin cifrar. Lo decisivo son el riesgo para los afectados y lo que resulta exigible según el estado de la técnica. Quien envía datos personales por correo electrónico necesita, por tanto, una decisión motivada que pueda presentarse en caso de duda.
Cifrado de transporte, extremo a extremo y firma: tres cosas distintas
En el día a día se mezclan tres cosas que hacen cosas distintas.
El cifrado de transporte protege la conexión entre dos estaciones. Funciona con TLS (Transport Layer Security), el sucesor de SSL. En cada tramo el contenido se transmite cifrado. En el propio servidor de correo, en cambio, está en texto claro, porque el servidor tiene que procesar y almacenar el correo.
El cifrado de extremo a extremo (E2E) cifra el contenido ya en el programa de correo del remitente. Solo el destinatario puede descifrarlo. Los servidores intermedios solo ven datos con los que no pueden hacer nada. Para ello se han consolidado S/MIME y OpenPGP.
La firma es otra cosa: no cifra nada, sino que acredita de quién procede un correo y que no se ha modificado por el camino. En el intercambio de claves desempeña un papel importante, porque las claves públicas suelen transmitirse mediante correos firmados.
Ambos procedimientos tienen un límite en común: el asunto, el remitente y el destinatario suelen seguir siendo legibles. La guía de la Conferencia de Protección de Datos (DSK) señala que también estas circunstancias de la comunicación pueden necesitar protección.
Jurisprudencia sobre el cifrado de correo electrónico: cuándo basta el cifrado de transporte
En los últimos años los tribunales han resuelto la cuestión varias veces, con resultados aparentemente contradictorios. Si se observa con detenimiento, las sentencias siguen una misma línea: cuanto mayor es el posible daño, mayores son las exigencias.
El caso más antiguo de la serie es de 2020. El Tribunal Administrativo de Maguncia (Verwaltungsgericht Mainz) decidió el 17 de diciembre de 2020 (Az. 1 K 778/19.MZ) si un abogado puede enviar correos a sus clientes solo con cifrado de transporte. La resolución se enmarca en los arts. 32 y 5 del RGPD. El principio rector establece que en la comunicación por correo electrónico de los abogados basta el cifrado de transporte. El cifrado de extremo a extremo solo es necesario, según esto, en caso de riesgo elevado en el caso concreto.
También se cita a menudo, pero solo es aplicable de forma limitada, el auto del Tribunal Federal de Justicia (Bundesgerichtshof) de 22 de marzo de 2021 (AnwZ (Brfg) 2/20). Se refiere al buzón electrónico especial del abogado. Su arquitectura de seguridad se basa en módulos de seguridad de hardware propios. Allí no existe un derecho al cifrado de extremo a extremo. Difícilmente puede trasladarse a los correos ordinarios.
| Tribunal, fecha | Hechos | Resultado |
|---|---|---|
| VG Mainz, 17.12.2020, 1 K 778/19.MZ | Un abogado envía correos a sus clientes solo con cifrado de transporte | Cifrado de transporte suficiente con riesgo normal |
| OLG Karlsruhe, 27.07.2023, 19 U 83/22 | Correo con la factura de un concesionario de automóviles, unos estafadores cambian los datos bancarios | El criterio es la expectativa de seguridad de los socios comerciales, el comprador tiene que pagar de nuevo |
| OLG Schleswig, 18.12.2024, 12 U 9/24 | Factura final enviada por correo a un consumidor, datos bancarios manipulados | Solo TLS es insuficiente con un importe elevado, indemnización como excepción |
El caso del Tribunal Superior Regional de Karlsruhe (Oberlandesgericht Karlsruhe) muestra la línea del tráfico mercantil. Un hacker había tomado el control de la cuenta de correo de un concesionario de automóviles y envió al comprador una factura manipulada con otro número de cuenta. El comprador pagó en la cuenta equivocada. El tribunal decidió el 27 de julio de 2023 (Az. 19 U 83/22) que las medidas de protección necesarias dependen de las expectativas legítimas de seguridad de los socios comerciales. El pago al estafador no liberó al comprador, que tuvo que pagar por segunda vez. El Tribunal Regional de Mosbach (Landgericht Mosbach), en primera instancia, había resuelto de otro modo.
El Tribunal Superior Regional de Schleswig llegó en diciembre de 2024 a un resultado diferente. También aquí se trataba de una factura manipulada, esta vez frente a un consumidor y por unos 15.000 euros. Según la nota de prensa del tribunal, la factura debería haberse enviado con cifrado de extremo a extremo, porque un ataque de hackers es un riesgo previsible. El cliente pudo oponer al crédito de pago una pretensión de indemnización y no tuvo que pagar de nuevo. El tribunal había admitido el recurso de casación; según su nota de prensa, la sentencia es no obstante firme. Una valoración de estas resoluciones, incluida una sentencia del Tribunal Administrativo de Düsseldorf de 2 de abril de 2026 (29 K 7351/23), se encuentra en el artículo Sicherheitsvorkehrungen beim Versand von E-Mails.
¿Cómo encaja todo esto? Al parecer, lo decisivo son la necesidad de protección y el potencial de daño. Entre empresas, los tribunales han aceptado hasta ahora más bien medidas estándar. Cuando un consumidor transfiere una suma elevada a una cuenta que solo le indica un correo sin proteger, se exige más. El nombre del procedimiento es secundario. Lo importante es que la medida reduzca realmente el riesgo concreto. Queda abierto, por ejemplo, si basta el consentimiento del destinatario a un cifrado más débil. Hasta ahora no hay una resolución sólida al respecto.
Guía de la DSK y BSI: el criterio de las autoridades de control
La Conferencia de las autoridades independientes de protección de datos (DSK) aprobó el 27 de mayo de 2021 la guía «Medidas para la protección de datos personales en la transmisión por correo electrónico», con fecha de 16 de junio de 2021. Baviera votó en contra. El documento está disponible públicamente y establece una distinción clara.
En situaciones de tratamiento con riesgos normales, el cifrado de transporte por sí solo ya logra una reducción suficiente del riesgo.
Guía de la DSK sobre cifrado de correo electrónico, a 16.06.2021 (traducido)
Con riesgo normal, la guía exige un cifrado de transporte obligatorio, orientado a la Directriz Técnica TR-03108-1 de la BSI. Con riesgo elevado, los responsables deben emplear con regularidad cifrado de extremo a extremo y un cifrado de transporte cualificado, es decir, por ejemplo con DANE o DNSSEC. El secreto profesional se considera aquí un indicio de riesgo elevado, que debe examinarse en cada caso.
Las multas por correos sin cifrar son raras; las autoridades de control actúan menos mediante sanciones que mediante documentos como este. Como criterio, la guía tiene sin embargo peso: en los litigios sobre facturas manipuladas se discutió si pueden tenerse en cuenta las indicaciones de las autoridades de control. El Tribunal Superior Regional de Karlsruhe las consideró no aplicables en aquel caso. La guía no es vinculante. Quien se aparte de ella debería, no obstante, poder justificarlo.
La BSI describe en la TR-03108 el transporte seguro de correo electrónico para proveedores, incluida la certificación. Para los operadores de servidores de correo es la vara de medir técnica. Como complemento existe, con la TR-03182, una recomendación sobre la autenticación del correo electrónico.
Aplicar bien el cifrado de transporte: TLS 1.3, puerto 465, MTA-STS y DANE
Los programas de correo y los servidores hablan varios protocolos. SMTP (Simple Mail Transfer Protocol) se utiliza desde 1982 y transmite los correos. ESMTP es la variante ampliada. Las abreviaturas de la cabecera del correo muestran lo que ocurrió en cada tramo: ESMTPS significa que se negoció TLS. ESMTPSA significa además que el remitente se autenticó con nombre de usuario y contraseña.
En la negociación hay dos caminos. Con TLS implícito, la conexión comienza cifrada desde el primer momento. Para el envío de correo desde el programa, según el RFC 8314 está previsto el puerto 465; para la recepción, IMAP por el puerto 993 o POP3 por el 995. Con STARTTLS la conexión empieza sin cifrar y ambas partes negocian después el cambio. Este paso puede ser perturbado por atacantes. El estudio «Why TLS is better without STARTTLS» (USENIX Security 2021) describe ataques de degradación y de inyección. Por eso el TLS implícito se considera la mejor opción, aunque en muchos sitios se siga ofreciendo en paralelo el puerto 587 con STARTTLS.
Sobre las versiones: TLS 1.0 y 1.1 están oficialmente en desuso desde el RFC 8996 (marzo de 2021). TLS 1.2 es el límite inferior y TLS 1.3 el objetivo, también según la Directriz Técnica BSI TR-02102-2.
Entre servidores sigue habiendo un problema. Allí el cifrado se realiza casi siempre mediante STARTTLS y a menudo es solo oportunista: si no funciona, la conexión vuelve a ser sin cifrar. Muchos servidores de correo ofrecen un modo que rechaza la entrega si no se logra establecer TLS. Normalmente esto también se hace mediante STARTTLS y no es TLS implícito.
Dos procedimientos cierran la brecha:
- MTA-STS (RFC 8461): el dominio del destinatario publica una política que establece que TLS con un certificado válido es obligatorio. Los servidores emisores la respetan. No requiere DNSSEC. Existen los modos testing y enforce. Los informes sobre problemas los proporciona TLS-RPT.
- DANE: en el DNS se fija mediante un registro TLSA qué certificado utiliza el servidor del destinatario. Esto requiere DNSSEC. DANE asegura la autenticidad del servidor del destinatario frente a la degradación y los ataques de intermediario (man-in-the-middle).
En Exchange Online, según Microsoft, el SMTP entrante con DANE está disponible con carácter general desde el 22 de octubre de 2024, aunque está desactivado por defecto. MTA-STS es compatible según la documentación de Microsoft. Si el propio dominio publica estas políticas puede comprobarse con herramientas en línea; más sobre ello en el apartado siguiente.
Comprobar el cifrado: leer la cabecera del correo y probar el servidor del destinatario
Si un correo llegó realmente cifrado, consta en la cabecera del correo. En las versiones clásicas de Outlook, se abre el correo con doble clic y después Archivo, Propiedades, el campo Encabezados de Internet. En el nuevo Outlook y en el correo web el camino es distinto. La navegación por los menús cambia con las versiones, por lo que conviene consultar la ayuda del programa correspondiente.
En las cabeceras interesan las líneas Received. Cada servidor que reenvía el correo añade una. Los servidores modernos anotan allí la versión del protocolo y el procedimiento, por ejemplo TLSv1.3 y TLS_AES_256_GCM_SHA384. El extracto de abajo está reconstruido, con marcadores de posición en lugar de direcciones reales.
Sin embargo, la cabecera no es una prueba sin lagunas en el sentido del art. 5, apdo. 2. Solo acredita los tramos en los que un servidor ha añadido la línea. Donde intervienen reenvíos o pasarelas, queda una laguna. Aun así sirve como elemento de una documentación.
Antes del envío puede comprobarse qué es capaz de hacer un servidor de destino. CheckTLS consulta las capacidades sin enviar un correo y muestra, entre otras cosas, si se ofrece TLS y si existe un registro TLSA para DANE. El resultado «no TLSA» es habitual en muchos dominios. El servicio internet.nl comprueba STARTTLS, DANE, así como SPF, DKIM y DMARC. Según su documentación, MTA-STS no forma parte de la evaluación.
Si el resultado de TLS es negativo, ayuda avisar al destinatario. Como alternativa cabe un portal o un archivo adjunto cifrado, de lo que se habla más abajo. Para el propio sitio web y sus medidas de protección, el DSGVO Webseiten-Check ofrece una primera orientación. Las comprobaciones de seguridad de dominios, incluida la autenticación del correo electrónico, se encuentran en los Web Security Checks.
SPF, DKIM y DMARC: protección frente a remitentes falsificados
El cifrado protege frente a la lectura, no frente a la falsificación. De eso trataban precisamente los casos de las facturas: un atacante envía un correo que parece proceder del remitente auténtico o utiliza un buzón secuestrado. Contra los remitentes falsificados ayudan tres procedimientos que funcionan conjuntamente.
| Procedimiento | Efecto |
|---|---|
| SPF | Establece qué servidores pueden enviar correos de un dominio |
| DKIM | Firma el correo criptográficamente y acredita que procede del dominio |
| DMARC | Vincula SPF y DKIM con el remitente visible y establece qué ocurre si fallan |
La presión para su adopción ha venido últimamente de los grandes proveedores. Google y Yahoo exigen desde el 1 de febrero de 2024 a todos los remitentes, entre otras cosas, SPF o DKIM, TLS y una tasa baja de spam. Quien envía más de 5.000 correos al día a direcciones de Gmail necesita SPF, DKIM y al menos una política DMARC. Microsoft introdujo requisitos similares para los remitentes de gran volumen hacia Outlook.com, Hotmail y Live a partir del 5 de mayo de 2025. Las reglas en detalle figuran en la documentación de Google.
La guía de la DSK prevé que en la recepción se comprueben DKIM y DMARC. Aquí se perfila una evolución que los responsables harían bien en no pasar por alto. Más información sobre mensajes falsificados ofrece el artículo E-Mails, Phishing und die Echtheit elektronischer Nachrichten. Para el trato con remitentes y archivos adjuntos desconocidos hay un artículo propio.
Extremo a extremo con S/MIME y OpenPGP: la situación en 2026
Quien quiera o deba ir más allá del cifrado de transporte dispone de dos procedimientos consolidados. Ambos cifran el contenido en el programa de correo. Ambos necesitan claves que se hayan intercambiado previamente. La guía de la DSK califica el extremo a extremo como la «protección más contundente», porque protege también los datos en reposo.
S/MIME
S/MIME trabaja con certificados emitidos por una autoridad de certificación. Se pueden usar directamente en Outlook, Apple Mail y muchos otros programas. El remitente suele obtener la clave pública del destinatario mediante un correo firmado, del que puede extraerse el certificado.
En los certificados ha cambiado mucho desde 2021. Las antiguas clases 1 a 4 han quedado obsoletas. Desde el 1 de septiembre de 2023 rigen los Baseline Requirements del CA/Browser Forum con cuatro tipos que se distinguen por el alcance de la verificación: Mailbox-, Organization-, Sponsor- e Individual-validated. El estado actual de los requisitos lo publica el propio foro.
OpenPGP
OpenPGP funciona sin una autoridad de certificación central. Cada persona genera su propio par de claves. La autenticidad se comprueba mediante huellas digitales (fingerprints) o la certificación de terceros. La DSK señala expresamente que la mera publicación de una clave en un servidor de claves no es un indicio de su autenticidad. Resulta práctico el Web Key Directory, mediante el cual un dominio pone a disposición por sí mismo sus claves. Una introducción a la firma ofrece el artículo E-Mails mit PGP signieren und verschicken.
El estándar ha cambiado: el RFC 9580 (julio de 2024) sustituye al RFC 4880. Aporta nuevos formatos de clave, procedimientos modernos como X25519 y Ed25519 y cifrado autenticado. Además, el proyecto GnuPG mantiene con LibrePGP una línea divergente. Esto complica la situación. Thunderbird utiliza una biblioteca propia llamada RNP en lugar de GnuPG, y Mozilla documenta problemas con claves que tienen características que RNP no admite. Las claves no siempre se trasladan sin fricciones entre programas.
La práctica con Outlook y Thunderbird
En la práctica suele notarse una diferencia entre el uso con una cuenta y con varias. El complemento GpgOL del paquete Gpg4win puede configurarse en Outlook y funciona con una cuenta. Con varias cuentas, en cambio, aparece una consulta en cada envío y la asignación de claves puede desordenarse. Para entornos con muchas cuentas esto es un obstáculo.
Actualmente Gpg4win está disponible en la versión 5.1.1 (publicada el 23 de septiembre de 2026), como muestra la página del proyecto. GpgOL funciona en el Outlook clásico. Si y cuándo será compatible con el nuevo Outlook es una cuestión abierta, según una entrada del foro de GnuPG. En Thunderbird, OpenPGP está integrado desde la versión 78, por lo que no hace falta ningún programa adicional. La configuración se realiza en los ajustes de la cuenta, en Cifrado de extremo a extremo. Quien solo usa una cuenta llega rápido al resultado.
En diciembre de 2025 la BSI examinó doce programas de correo gratuitos. Según la nota de prensa, los programas se diferencian en la compatibilidad con el cifrado de extremo a extremo. Las funciones de seguridad a menudo no están activas de serie.
Un aspecto secundario es el ataque Efail de 2018. Aprovechaba contenidos HTML activos en los correos para enviar textos descifrados hacia el exterior. Como contramedida se consideran los programas actualizados y la visualización HTML desactivada en los correos cifrados. Una explicación ofrece la página efail.de. No hay motivo para el pánico, pero el ejemplo muestra que incluso una buena criptografía puede fracasar por la implementación.
Portales, pasarelas y cifrado de Microsoft como alternativas
El mayor obstáculo del extremo a extremo es el intercambio de claves con cada interlocutor. Por eso muchas organizaciones apuestan por soluciones en las que el esfuerzo recae en el remitente.
- Cifrado mediante pasarela: un servidor de la empresa se encarga de S/MIME o PGP. La protección llega entonces hasta la pasarela del destinatario. En el buzón, el correo queda, según la configuración, descifrado. La cuestión de la confianza se traslada al operador de la pasarela.
- Portal: el correo contiene solo un aviso. El mensaje se recoge en el navegador tras iniciar sesión. También la guía de la DSK menciona un portal web como vía de comunicación con los afectados.
- Microsoft Purview Message Encryption: utilizable en el nuevo Outlook con una licencia adecuada. Los destinatarios fuera de Microsoft reciben instrucciones para abrir el mensaje. No puede combinarse con S/MIME en el mismo mensaje.
- Archivo adjunto protegido con contraseña: un archivo comprimido con AES-256, creado por ejemplo con 7-Zip, sirve de sobre. La contraseña se transmite por otro canal, por ejemplo por teléfono (cambio de medio). El SMS es un canal controvertido y solo debería usarse con reservas.
Quien opera una pasarela o un portal con un proveedor de servicios suele celebrar para ello un contrato de encargo del tratamiento conforme al art. 28 del RGPD. Los riesgos vinculados a Microsoft 365 en la propia cuenta los describe el artículo sobre el Token-Spraying.
La ponderación es sobria: quien rehúye la gestión de claves obtiene con un portal o una pasarela una solución intermedia practicable. Supone concesiones frente al verdadero cifrado de extremo a extremo, pero es claramente mejor que un correo en texto claro con contenido sensible.
Criptografía poscuántica en el correo electrónico: lo que ya cuenta hoy
El extremo a extremo tiene una propiedad que a menudo se pasa por alto: no ofrece de serie Perfect Forward Secrecy. La DSK escribe al respecto que los correos interceptados pueden conservarse y descifrarse más tarde si se revela la clave privada. Con los futuros ordenadores cuánticos, este escenario podría producirse incluso sin pérdida de la clave.
La normalización está en marcha. Con el RFC 9936 (marzo de 2026) existe un estándar para ML-KEM en CMS, la base de S/MIME. Para TLS 1.3, la BSI TR-02102-2 prevé procedimientos híbridos que combinan métodos clásicos y poscuánticos. Para el día a día no se deriva de ello ninguna necesidad de actuar. Quien envía contenidos que deban seguir siendo confidenciales dentro de 15 años debería, sin embargo, tener presente el tema.
Envío erróneo, violación de datos y telefax: los límites del cifrado
Una desventaja del cifrado de transporte sigue vigente hasta hoy: con una dirección de destinatario equivocada no sirve de nada. El correo llega cifrado al servidor equivocado y allí queda en texto claro. Con el extremo a extremo es distinto, siempre que se haya dirigido al destinatario previsto. La DSK menciona expresamente el direccionamiento individual como medida.
Por eso cuenta la parte organizativa. Incluye desactivar el autocompletado para destinatarios sensibles, aplicar el principio de los cuatro ojos en contenidos delicados y comprobar la dirección antes de enviar. Si un envío erróneo debe notificarse como violación de la seguridad de los datos depende del riesgo y corresponde a un procedimiento propio.
También el telefax aparece en este debate. El Comisionado de Protección de Datos y Libertad de Información de Bremen ha comparado el fax con los correos sin cifrar en una página de guías orientativas. El Tribunal Superior Administrativo de Lüneburg (Oberverwaltungsgericht Lüneburg) consideró necesario, en un auto de 2020 (11 LA 104/19), un examen del caso concreto tratándose de datos especialmente sensibles.
Qué cifrado para qué correo: guía de decisión
De las sentencias y las directrices puede deducirse una regla práctica. Cuanto mayores son el potencial de daño y la necesidad de confidencialidad, antes entran en consideración el extremo a extremo o un portal. En el caso de las facturas se aplica además: un cambio de datos bancarios se confirma por un segundo canal, por ejemplo por teléfono.
La tabla sirve de orientación y no es asesoramiento jurídico. La clasificación del riesgo corresponde al responsable y debe documentarse. Ayuda un breve examen: ¿cuál sería el peor daño realista para los afectados? ¿Qué probabilidad tiene? ¿Qué medida lo reduce de forma perceptible?
Conclusión
El cifrado de transporte es el programa mínimo obligatorio y, con riesgo normal, según la DSK y la jurisprudencia suele bastar si se implanta de forma coherente y conforme al estado de la técnica. Ello incluye TLS 1.2 o mejor 1.3, TLS implícito en el programa de correo y MTA-STS o DANE en el lado del servidor. Con riesgo elevado se espera el extremo a extremo o una solución equivalente.
El cifrado de correo electrónico sigue siendo un tema de ponderaciones. La gestión de claves es engorrosa, los portales son una solución intermedia pragmática y contra el fraude ayudan SPF, DKIM, DMARC y un segundo canal para los datos de pago al menos tanto como la criptografía.
Me llamo Klaus Meffert. Soy doctor en informática y llevo más de 30 años dedicándome profesional y prácticamente a las tecnologías de la información. También trabajo como experto en informática y protección de datos. Obtengo mis resultados analizando la tecnología y el Derecho. Esto me parece absolutamente esencial cuando se trata de protección de datos digitales.
