Crittografia email: TLS, end-to-end e GDPR

Le email vengono spesso paragonate a una cartolina: chi legge lungo il percorso vede tutto. La crittografia email decide se è davvero così. Questo articolo descrive che cosa offrono la crittografia del trasporto e la crittografia end-to-end, che cosa hanno detto al riguardo tribunali e autorità di controllo e quale tecnologia fa la differenza nella pratica.

L'articolo tiene conto di sentenze, tecnica e requisiti dei grandi provider di posta fino alla fine di ottobre 2026.

La struttura dell'articolo segue il percorso di una email. Si parte dal criterio di valutazione e dai concetti, poi si passa alla giurisprudenza e al punto di vista delle autorità di controllo. Segue la tecnica: crittografia del trasporto, verifica dell'header, protezione dai mittenti falsificati e metodi end-to-end come S/MIME e OpenPGP. In chiusura c'è una guida alla scelta su quale crittografia si adatti a quale tipo di email.

Crittografia email e GDPR: qual è il criterio di valutazione

I dati personali devono essere trattati in modo da essere protetti dall'accesso non autorizzato. Lo stabilisce l'art. 5, par. 1, lett. f GDPR. Ai sensi del paragrafo 2, il titolare deve anche essere in grado di dimostrarlo. Come debba concretamente essere la protezione lo disciplina l'art. 32 GDPR: occorre adottare misure conformi allo stato dell'arte e adeguate al rischio. La norma non prescrive un metodo specifico. La crittografia vi è citata soltanto come possibile misura.

Le categorie particolari di dati, come i dati sanitari, rientrano nell'art. 9 GDPR. Qui l'esigenza di protezione è più elevata fin dall'inizio. Ma anche email apparentemente innocue contengono dati personali: basta l'indirizzo del mittente con il nome e cognome.

Nel 2026 il quadro giuridico si può riassumere così: non esiste un obbligo generalizzato di crittografia end-to-end per ogni email. Non esiste neppure un via libera generalizzato per le email non cifrate. Contano il rischio per gli interessati e la questione di che cosa sia ragionevole secondo lo stato dell'arte. Chi invia dati personali via email ha quindi bisogno di una decisione motivata, che nel dubbio sia possibile esibire.

Crittografia del trasporto, end-to-end e firma: tre cose da tenere distinte

Nella vita quotidiana si confondono tre cose che svolgono funzioni diverse.

La crittografia del trasporto protegge la connessione tra due stazioni. Funziona con TLS (Transport Layer Security), il successore di SSL. Su ogni tratta il contenuto viene trasmesso in forma cifrata. Sul server di posta stesso, invece, è in chiaro, perché il server deve elaborare e archiviare l'email.

La crittografia end-to-end (E2E) cifra il contenuto già nel programma di posta del mittente. Solo il destinatario può decifrarlo. I server intermedi vedono solo dati inutilizzabili. Per questo si sono affermati S/MIME e OpenPGP.

La firma è un'altra cosa: non cifra nulla, ma attesta da chi proviene un'email e che non è stata modificata lungo il percorso. Nello scambio delle chiavi svolge un ruolo importante, perché le chiavi pubbliche vengono per lo più trasmesse tramite email firmate.

Entrambi i metodi hanno un limite in comune: oggetto, mittente e destinatario restano di norma leggibili. La guida della Conferenza tedesca per la protezione dei dati (DSK) sottolinea che anche queste circostanze della comunicazione possono meritare protezione.

Giurisprudenza sulla crittografia email: quando basta la crittografia del trasporto

Negli ultimi anni i tribunali tedeschi hanno deciso più volte la questione, con esiti apparentemente contraddittori. A un esame attento le sentenze seguono una linea comune: quanto maggiore è il possibile danno, tanto più elevati sono i requisiti.

Il caso più antico della serie risale al 2020. Il Tribunale amministrativo di Magonza ha deciso il 17 dicembre 2020 (n. 1 K 778/19.MZ) se un avvocato possa inviare email ai clienti con la sola crittografia del trasporto. La decisione viene inquadrata nell'art. 32 e nell'art. 5 GDPR. Secondo la massima, nella comunicazione via email degli avvocati la crittografia del trasporto è sufficiente. La crittografia end-to-end è quindi necessaria solo in singoli casi con rischio elevato.

Spesso citata, ma solo in parte pertinente, è anche l'ordinanza della Corte federale di giustizia del 22 marzo 2021 (AnwZ (Brfg) 2/20). Riguarda la casella elettronica speciale degli avvocati (beA). La sua architettura di sicurezza si basa su moduli di sicurezza hardware dedicati. Lì non esiste alcun diritto alla crittografia end-to-end. Difficilmente la decisione si può trasferire alle normali email.

Il caso dell'Oberlandesgericht di Karlsruhe mostra la linea seguita nel traffico commerciale. Un hacker aveva preso il controllo dell'account di posta di un concessionario e aveva inviato all'acquirente una fattura manipolata con un altro numero di conto. L'acquirente pagò sul conto sbagliato. Il tribunale decise il 27 luglio 2023 (n. 19 U 83/22) che le misure di protezione necessarie dipendono dalle legittime aspettative di sicurezza dei partner commerciali. Il pagamento al truffatore non liberò l'acquirente, che dovette pagare una seconda volta. Il Landgericht di Mosbach, in primo grado, aveva ancora deciso diversamente.

L'Oberlandesgericht di Schleswig è giunto a dicembre 2024 a un risultato diverso. Anche qui si trattava di una fattura manipolata, questa volta nei confronti di un consumatore e per circa 15.000 euro. Secondo il comunicato stampa del tribunale la fattura avrebbe dovuto essere inviata con crittografia end-to-end, perché un attacco hacker è un rischio prevedibile. Il cliente poté opporre alla pretesa di pagamento un diritto al risarcimento e non dovette pagare di nuovo. Il tribunale aveva ammesso il ricorso, ma secondo il suo comunicato stampa la sentenza è comunque passata in giudicato. Un inquadramento di queste decisioni, compresa una sentenza del Tribunale amministrativo di Düsseldorf del 02.04.2026 (29 K 7351/23), si trova nell'articolo Sicherheitsvorkehrungen beim Versand von E-Mails.

Come stanno insieme le cose? Evidentemente contano l'esigenza di protezione e il potenziale di danno. Tra imprese i tribunali hanno finora accettato piuttosto misure standard. Dove un consumatore trasferisce una somma elevata su un conto che gli viene comunicato solo da un'email non protetta, si richiede di più. Il nome del metodo è secondario. Conta che la misura riduca effettivamente il rischio concreto. Resta aperto, ad esempio, se basti il consenso del destinatario a una crittografia più debole. Al riguardo non esiste finora alcuna decisione affidabile.

Guida DSK e BSI: il criterio delle autorità di controllo

La Conferenza delle autorità indipendenti di controllo della protezione dei dati (DSK) ha adottato il 27.05.2021 la guida «Misure per la protezione dei dati personali nella trasmissione via email», aggiornata al 16.06.2021. La Baviera ha votato contro. Il documento è consultabile pubblicamente e opera una distinzione chiara.

In caso di rischio normale la guida richiede una crittografia del trasporto obbligatoria, basata sulla direttiva tecnica TR-03108-1 del BSI. In caso di rischio elevato i titolari dovrebbero di regola usare la crittografia end-to-end e una crittografia del trasporto qualificata, ad esempio con DANE o DNSSEC. Un segreto professionale vale come indizio di un rischio elevato, da verificare nel singolo caso.

Le sanzioni per email non cifrate sono rare: le autorità di controllo agiscono meno attraverso le sanzioni che attraverso documenti come questo. Come criterio la guida ha comunque peso: nelle controversie sulle fatture manipolate si è discusso se si possano utilizzare le indicazioni delle autorità di controllo. L'Oberlandesgericht di Karlsruhe le ha ritenute non pertinenti nel caso in esame. La guida non è vincolante. Chi se ne discosta dovrebbe però saperlo motivare.

Il BSI descrive nella TR-03108 il trasporto sicuro delle email per i provider, compresa la certificazione. Per i gestori di server di posta è il parametro tecnico di riferimento. A completamento esiste, con la TR-03182, una raccomandazione sull'autenticazione delle email.

Attuare correttamente la crittografia del trasporto: TLS 1.3, porta 465, MTA-STS e DANE

I programmi di posta e i server parlano più protocolli. SMTP (Simple Mail Transfer Protocol) è in uso dal 1982 e trasmette le email. ESMTP è la variante estesa. Le sigle nell'header mostrano che cosa è avvenuto sulla singola tratta: ESMTPS significa che è stato negoziato TLS. ESMTPSA significa inoltre che il mittente si è autenticato con nome utente e password.

Nella negoziazione ci sono due strade. Con il TLS implicito la connessione è cifrata fin dall'inizio. Per l'invio dal programma di posta, secondo l'RFC 8314 è prevista la porta 465, per il prelievo IMAP sulla porta 993 o POP3 sulla porta 995. Con STARTTLS la connessione parte in chiaro e solo dopo le due parti negoziano il passaggio alla cifratura. Questo passaggio può essere disturbato dagli aggressori. Lo studio «Why TLS is better without STARTTLS» (USENIX Security 2021) descrive attacchi di downgrade e di injection. Per questo il TLS implicito è considerato la scelta migliore, anche se in molti posti la porta 587 con STARTTLS continua a essere offerta in parallelo.

Quanto alle versioni: TLS 1.0 e 1.1 sono ufficialmente deprecati dall'RFC 8996 (marzo 2021). TLS 1.2 è il limite minimo, TLS 1.3 l'obiettivo, anche secondo la direttiva tecnica BSI TR-02102-2.

Un problema resta tra i server. Qui la crittografia passa per lo più attraverso STARTTLS ed è spesso solo opportunistica: se non funziona, la connessione ripiega sul non cifrato. Molti server di posta offrono una modalità che rifiuta la consegna se non si stabilisce TLS. Anche questa di regola passa per STARTTLS e non è TLS implicito.

Due procedure colmano la lacuna:

• MTA-STS (RFC 8461): il dominio del destinatario pubblica una policy che rende obbligatorio TLS con certificato valido. I server mittenti vi si attengono. Non serve DNSSEC. Esistono le modalità testing ed enforce. I rapporti sui problemi li fornisce TLS-RPT.
• DANE: nel DNS un record TLSA stabilisce quale certificato usa il server del destinatario. Presuppone DNSSEC. DANE protegge l'autenticità del server del destinatario da downgrade e man-in-the-middle.

Per Exchange Online, secondo Microsoft, l'SMTP in entrata con DANE è disponibile in generale dal 22.10.2024, ma per impostazione predefinita è disattivato. MTA-STS è supportato secondo la documentazione di Microsoft. Se il proprio dominio pubblica queste policy si può verificare con strumenti online, ne parliamo nella prossima sezione.

Verificare la crittografia: leggere l'header e testare il server del destinatario

Se un'email è arrivata davvero cifrata lo si legge nell'header. Nelle versioni classiche di Outlook basta fare doppio clic sull'email, poi File, Proprietà, campo Intestazioni Internet. Nel nuovo Outlook e nel webmail il percorso è diverso. La navigazione dei menu cambia con le versioni, perciò conviene consultare la guida del programma in uso.

Nelle intestazioni interessano le righe Received. Ogni server che inoltra l'email ne aggiunge una. I server moderni vi riportano versione del protocollo e procedura, ad esempio TLSv1.3 e TLS_AES_256_GCM_SHA384. L'estratto qui sotto è ricostruito, con segnaposto al posto di indirizzi reali.

L'header non è tuttavia una prova completa ai sensi dell'art. 5, par. 2. Documenta soltanto le tratte su cui un server ha aggiunto la riga. Dove entrano in gioco inoltri o gateway, resta una lacuna. Come elemento di una documentazione è comunque utile.

Prima dell'invio si può testare che cosa sa fare un server destinatario. CheckTLS ne interroga le capacità senza inviare un'email e mostra tra l'altro se TLS viene offerto e se esiste un record TLSA per DANE. Il risultato «no TLSA» è comune per molti domini. Il servizio internet.nl verifica STARTTLS, DANE nonché SPF, DKIM e DMARC. Secondo la documentazione MTA-STS non fa parte della valutazione.

In caso di esito TLS negativo aiuta una segnalazione al destinatario. In alternativa si può ricorrere a un portale o a un allegato cifrato, ne parliamo più avanti. Per il proprio sito web e le sue misure di protezione il controllo del sito web GDPR offre un primo orientamento. Verifiche di sicurezza per i domini, compresa l'autenticazione delle email, si trovano nei Web Security Checks.

SPF, DKIM e DMARC: protezione dai mittenti falsificati

La crittografia protegge dalla lettura, non dalla falsificazione. È proprio questo il tema dei casi sulle fatture: un aggressore invia un'email che sembra provenire dal vero mittente, oppure usa una casella di posta violata. Contro i mittenti falsificati aiutano tre procedure che agiscono insieme.

La spinta all'adozione è venuta di recente dai grandi provider. Google e Yahoo richiedono dal 01.02.2024 a tutti i mittenti, tra l'altro, SPF o DKIM, TLS e un basso tasso di spam. Chi invia più di 5.000 email al giorno a indirizzi Gmail ha bisogno di SPF, DKIM e almeno una policy DMARC. Microsoft ha introdotto requisiti simili per i mittenti ad alto volume verso Outlook.com, Hotmail e Live dal 05.05.2025. Le regole nel dettaglio sono nella documentazione di Google.

La guida DSK prevede che in ricezione vengano verificati DKIM e DMARC. Si delinea qui uno sviluppo che i titolari farebbero meglio a non ignorare. Ulteriori approfondimenti sui messaggi falsificati sono nell'articolo E-Mails, Phishing und die Echtheit elektronischer Nachrichten. Per la gestione di mittenti e allegati sconosciuti esiste un articolo a parte.

End-to-end con S/MIME e OpenPGP: la situazione nel 2026

Chi vuole o deve andare oltre la crittografia del trasporto ha a disposizione due procedure consolidate. Entrambe cifrano il contenuto nel programma di posta. Entrambe richiedono chiavi scambiate in precedenza. La guida DSK definisce l'end-to-end la «protezione più incisiva», perché tutela anche i dati a riposo.

S/MIME

S/MIME lavora con certificati rilasciati da un'autorità di certificazione. Sono utilizzabili direttamente in Outlook, Apple Mail e in molti altri programmi. La chiave pubblica del destinatario il mittente la ottiene per lo più tramite un'email firmata, dalla quale si può importare il certificato.

Per i certificati molto è cambiato dal 2021. Le classi da 1 a 4, un tempo diffuse, sono superate. Dal 01.09.2023 valgono i Baseline Requirements del CA/Browser Forum con quattro tipi, che si distinguono per l'ampiezza della verifica: Mailbox-, Organization-, Sponsor- e Individual-validated. Lo stato aggiornato dei requisiti lo pubblica il forum stesso.

OpenPGP

OpenPGP funziona senza un'autorità di certificazione centrale. Ognuno genera una propria coppia di chiavi. L'autenticità si verifica tramite fingerprint o attestazione di terzi. La DSK avverte espressamente che la semplice pubblicazione di una chiave su un key server non è un indizio della sua autenticità. Pratico è il Web Key Directory, con cui un dominio mette a disposizione da sé le proprie chiavi. Un'introduzione alla firma la offre l'articolo E-Mails mit PGP signieren und verschicken.

Lo standard è cambiato: l'RFC 9580 (luglio 2024) sostituisce l'RFC 4880. Porta nuovi formati di chiave, procedure moderne come X25519 ed Ed25519 e la cifratura autenticata. Accanto a ciò il progetto GnuPG porta avanti con LibrePGP una linea divergente. Questo complica il quadro. Thunderbird usa una propria libreria chiamata RNP invece di GnuPG, e Mozilla documenta problemi con chiavi dotate di caratteristiche che RNP non supporta. Le chiavi non passano quindi sempre senza attriti da un programma all'altro.

In pratica con Outlook e Thunderbird

Nella pratica emerge spesso una differenza tra uso con un solo account e con più account. Il plugin GpgOL del pacchetto Gpg4win si configura in Outlook e funziona con un account. Con più account, invece, a ogni invio compare una richiesta e l'assegnazione delle chiavi può confondersi. Per gli ambienti con molti account è un ostacolo.

Attualmente Gpg4win è disponibile nella versione 5.1.1 (pubblicata il 23.09.2026), come mostra il sito del progetto. GpgOL funziona nell'Outlook classico. Se e quando supporterà il nuovo Outlook è, secondo un intervento nel forum di GnuPG, ancora aperto. In Thunderbird OpenPGP è integrato dalla versione 78, non serve alcun programma aggiuntivo. La configurazione avviene nelle impostazioni dell'account alla voce crittografia end-to-end. Chi usa un solo account arriva rapidamente al risultato.

Il BSI ha esaminato nel dicembre 2025 dodici programmi di posta gratuiti. Secondo il comunicato stampa i programmi si differenziano per il supporto alla crittografia end-to-end. Le funzioni di sicurezza spesso non sono attive di default.

Un aspetto collaterale è l'attacco Efail del 2018. Sfruttava contenuti HTML attivi nelle email per far uscire testi decifrati verso l'esterno. Come contromisura valgono programmi aggiornati e la visualizzazione HTML disattivata per le email cifrate. Una spiegazione la offre il sito efail.de. Il panico non è giustificato, ma l'esempio mostra che anche una buona crittografia può fallire nell'implementazione.

Portali, gateway e crittografia Microsoft come alternative

Il maggiore ostacolo per l'end-to-end è lo scambio delle chiavi con ogni interlocutore. Per questo molte organizzazioni puntano su soluzioni in cui l'onere ricade sul mittente.

• Crittografia tramite gateway: un server aziendale si occupa di S/MIME o PGP. La protezione arriva allora fino al gateway del destinatario. Nella casella di posta l'email, a seconda della configurazione, è decifrata. La questione della fiducia si sposta sul gestore del gateway.
• Portale: l'email contiene solo un avviso. Il messaggio si ritira nel browser dopo un accesso. Anche la guida DSK cita un portale web come canale di comunicazione verso gli interessati.
• Microsoft Purview Message Encryption: utilizzabile nel nuovo Outlook con la licenza adeguata. I destinatari esterni a Microsoft ricevono istruzioni per l'apertura. Sullo stesso messaggio non si può combinare con S/MIME.
• Allegato protetto da password: un archivio con AES-256, creato ad esempio con 7-Zip, fa da busta. La password viaggia su un altro canale, ad esempio per telefono (cambio di mezzo). L'SMS come canale è controverso e andrebbe usato solo con cautela.

Chi gestisce un gateway o un portale presso un fornitore di servizi stipula di regola per questo un contratto di trattamento dei dati ai sensi dell'art. 28 GDPR. I rischi legati a Microsoft 365 per l'account stesso li descrive l'articolo sul token spraying.

La valutazione è sobria: chi teme la gestione delle chiavi ottiene con un portale o un gateway una soluzione intermedia praticabile. Comporta compromessi rispetto alla vera crittografia end-to-end, ma è nettamente meglio di un'email in chiaro con contenuto sensibile.

Crittografia post-quantistica per le email: che cosa conta già oggi

L'end-to-end ha una caratteristica spesso trascurata: la Perfect Forward Secrecy qui non esiste di per sé. La DSK scrive al riguardo che le email intercettate possono essere conservate e decifrate in seguito, se la chiave privata viene divulgata. Con i futuri computer quantistici questo scenario potrebbe verificarsi anche senza perdita della chiave.

La standardizzazione è in corso. Con l'RFC 9936 (marzo 2026) esiste uno standard per ML-KEM in CMS, la base per S/MIME. Per TLS 1.3 la BSI TR-02102-2 prevede procedure ibride che combinano metodi classici e post-quantistici. Per l'uso quotidiano non ne deriva alcuna necessità di agire. Chi invia contenuti che devono restare riservati anche fra 15 anni dovrebbe però tenere d'occhio il tema.

Invio errato, violazione dei dati e fax: i limiti della crittografia

Uno svantaggio della crittografia del trasporto vale ancora oggi: con un indirizzo di destinatario sbagliato non serve a nulla. L'email arriva cifrata sul server sbagliato e lì è in chiaro. Con l'end-to-end è diverso, purché sia stata indirizzata al destinatario previsto. La DSK cita espressamente l'indirizzamento individuale come misura.

Per questo conta la parte organizzativa. Ne fanno parte il completamento automatico disattivato per i destinatari sensibili, il principio dei quattro occhi per i contenuti delicati e la verifica dell'indirizzo prima dell'invio. Se un invio errato debba essere notificato come violazione dei dati dipende dal rischio e rientra in una procedura a parte.

Anche il telefax compare in questo dibattito. Il Garante per la protezione dei dati e la libertà di informazione di Brema ha paragonato il fax alle email non cifrate in una pagina dedicata alle guide. L'Oberverwaltungsgericht di Lüneburg ha ritenuto necessaria, in un'ordinanza del 2020 (11 LA 104/19), una verifica caso per caso per dati particolarmente sensibili.

Quale crittografia per quale email: guida alla scelta

Da sentenze e linee guida si può ricavare una regola pratica. Quanto maggiori sono il potenziale di danno e l'esigenza di riservatezza, tanto più si prendono in considerazione l'end-to-end o un portale. Per le fatture vale inoltre: una modifica delle coordinate bancarie si conferma attraverso un secondo canale, ad esempio per telefono.

La tabella serve da orientamento e non è consulenza legale. La valutazione del rischio spetta al titolare e va documentata. Aiuta una breve verifica: qual è il peggior danno realistico per gli interessati? Quanto è probabile? Quale misura lo riduce in modo percepibile?

Conclusione

La crittografia del trasporto è il programma obbligatorio e, in caso di rischio normale secondo DSK e giurisprudenza, per lo più sufficiente, se è impostata in modo coerente e conforme allo stato dell'arte. Ne fanno parte TLS 1.2 o meglio 1.3, TLS implicito nel programma di posta e MTA-STS o DANE sul lato server. In caso di rischio elevato ci si aspetta l'end-to-end o una soluzione equivalente.

La crittografia email resta un tema di compromessi. La gestione delle chiavi è faticosa, i portali sono una soluzione intermedia pragmatica e contro le frodi SPF, DKIM, DMARC e un secondo canale per i dati di pagamento aiutano almeno quanto la crittografia.