Tracking pixel nelle email: ora anche un logo diventa un problema privacy?

Un’immagine trasparente grande un pixel, inserito in un messaggio di posta elettronica, può rappresentare uno strumento di tracciamento; un normalissimo logo aziendale può generare richieste HTTP che trasportano informazioni sostanzialmente identiche. E se il server che distribuisce quel logo registra indirizzi IP, orari di accesso e altri dettagli tecnici, dove passa il confine tra il normale funzionamento del Web e il monitoraggio dei destinatari di un’email?

La domanda interessa direttamente editori, amministratori di siti Web, aziende e fornitori di servizi di email marketing. Il 29 ottobre 2026 scade infatti il termine di adeguamento alle Linee guida del Garante Privacy sull’utilizzo dei tracking pixel nelle comunicazioni elettroniche, approvate il 17 aprile e pubblicate sulla Gazzetta Ufficiale del 29 aprile.

La scadenza sta provocando reazioni differenti: c’è chi elimina completamente i tracking pixel dalle email inviate agli utenti, chi modifica le piattaforme di mailing per permettere la revoca selettiva del consenso e chi scopre soltanto adesso di non aver descritto adeguatamente il monitoraggio nelle proprie informative privacy.

Il rischio è che un problema reale di protezione dei dati personali si trasformi in un susseguirsi di interventi affrettati, senza distinguere ciò che la normativa richiede effettivamente dalle interpretazioni eccessivamente prudenziali.

Cos’è un tracking pixel e le novità dal 29 ottobre 2026

Sempre secondo le Linee guida del Garante Privacy, i tracking pixel sono generalmente piccole immagini trasparenti, incorporate nelle email e caricate da server remoti, che consentono di raccogliere informazioni sull’apertura dei messaggi e sulle interazioni dei destinatari. Non esiste però una sintassi universale per identificarli: la loro funzione non dipende necessariamente dal formato, dalle dimensioni o dal nome del file.

Dal 29 ottobre 2026, termine ultimo per l’adeguamento, chi utilizza questi strumenti deve rispettare precise condizioni.

Informativa e consenso dell’interessato

Il Garante richiede che i destinatari siano informati in modo chiaro sull’utilizzo dei tracking pixel e sulle finalità perseguite. L’informativa è necessaria anche quando il tracciamento rientra tra i casi per i quali non occorre richiedere il consenso preventivo (ad esempio, statistiche aggregate e anonime, esigenze di sicurezza e autenticazione, comunicazioni istituzionali o di servizio, alle condizioni previste dal Garante).

Per il monitoraggio individuale a fini promozionali o di profilazione, invece, è generalmente necessario acquisire anche il consenso dell’interessato.

L’informazione può comparire già nel modulo di iscrizione per la ricezione delle email (ad esempio, newsletter), accompagnata da un collegamento all’informativa privacy completa. Per i trattamenti già in corso, le Linee guida consentono di integrare le informazioni al primo messaggio utile o in un altro momento appropriato di discontinuità nel rapporto con l’interessato.

Non esiste invece una prescrizione generalizzata volta all’inserimento di una specifica dicitura nel footer di ogni email, purché le modalità informative adottate soddisfino i requisiti indicati dall’Autorità.

Conseguenze per editori, amministratori di siti Web e utenti

Per editori e amministratori Web, quindi, non esiste un obbligo indiscriminato di rimuovere tutti i tracking pixel dalle mail che inviano: occorre verificare il funzionamento della piattaforma di invio, aggiornare le informative, controllare la validità dei consensi e predisporre i meccanismi di revoca necessari. La scadenza riguarda l’adeguamento delle attività di trattamento, non l’introduzione di un divieto generale della tecnologia.

Le conseguenze per gli utenti e le ragioni per cui molte aziende stanno inviando comunicazioni dedicate sono approfondite nell’articolo Perché stai ricevendo tante email sui tracking pixel? Cosa cambia. Qui ci concentriamo invece sulle implicazioni tecniche e sulle responsabilità di chi gestisce siti Web e newsletter.

Se uso logo.png al posto di un tracking pixel, cosa cambia?

Consideriamo un’email HTML spedita ai suoi clienti da un provider di telecomunicazioni o da una banca:

<img src="https://www.example.com/logo.png" alt="Logo">

Quando il destinatario visualizza il messaggio e il suo programma di posta decide di scaricare l’immagine, viene generata una richiesta HTTP al server che la ospita.

Il server può registrare l’indirizzo IP di origine, l’orario della richiesta, lo User-Agent e altri metadati. Un comportamento ordinario, che riguarda non soltanto le newsletter ma anche immagini, fogli di stile e altri contenuti distribuiti dai siti Web.

Il Garante descrive i tracking pixel come immagini generalmente molto piccole, spesso invisibili, ospitate su server remoti e richiamate dal messaggio di posta elettronica.

La dimensione, tuttavia, non determina da sola la funzione dello strumento: un’immagine perfettamente visibile può assolvere anche una funzione di tracciamento, se il suo caricamento permette di raccogliere e utilizzare informazioni sulle interazioni dei destinatari. In altre parole, chiamare una risorsa logo.png invece di tracking.gif non modifica la natura del trattamento eventualmente effettuato.

Tracciare l’apertura delle email con un ID nell’URL dell’immagine

Il sistema più semplice e diffuso per monitorare l’apertura di una newsletter consiste nell’associare un identificatore univoco a ciascun destinatario e inserirlo nell’indirizzo di un’immagine remota. Per esempio, il codice HTML del messaggio potrebbe contenere qualcosa di molto simile:

<img src="https://www.example.com/logo.png?id=12345" alt="Logo">

Il parametro id=12345 permette al server di associare la richiesta HTTP a uno specifico utente. Quando il programma di posta scarica l’immagine, un’applicazione lato server può registrare l’identificatore, la data e l’ora del caricamento e altri dati tecnici eventualmente disponibili.

Non è quindi necessario che l’immagine sia invisibile o misuri un solo pixel: può trattarsi del normale logo aziendale, di un banner pubblicitario o di qualsiasi altra risorsa grafica. Ciò che conta è la possibilità di collegare il caricamento a uno specifico destinatario.

Il server può utilizzare uno script PHP, Python o un’altra tecnologia per intercettare la richiesta, registrare le informazioni e restituire il contenuto PNG originale. L’utente continuerà a vedere il logo, mentre il sistema potrà memorizzare l’evento associato all’identificatore.

Una simile tecnica può consentire il monitoraggio individuale delle aperture, pur con i limiti legati ai proxy, alla cache e al caricamento preventivo delle immagini da parte dei servizi di posta.

Le Linee guida del Garante Privacy, al paragrafo 2, prendono in considerazione proprio l’impiego di identificativi che consentono di collegare le richieste alle comunicazioni inviate e ai rispettivi destinatari.

Ma l’identificatore nella query string non è indispensabile: un server può ricavare informazioni utili al riconoscimento anche attraverso altre caratteristiche della richiesta HTTP o dati già raccolti in precedenza.

Come tracciare l’apertura delle email con logo.png senza inserire alcun ID nella query string

Il caso più interessante è proprio quello in cui l’URL non contiene alcun parametro identificativo: non è infatti indispensabile che una risorsa abbia un indirizzo come logo.png?id=12345 per poter contribuire al monitoraggio.

1. Identificazione attraverso indirizzo IP, User-Agent e log HTTP

Supponiamo che il server riceva la seguente richiesta, rappresentata in forma semplificata:

GET /logo.png HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...

Il Web server può registrare un evento come questo:

203.0.113.42 - - [29/Oct/2026:10:32:14 +0100]
"GET /logo.png HTTP/1.1" 200 18452
"Mozilla/5.0 ..."

La registrazione indica che una richiesta ha raggiunto il server, ma non prova che una determinata persona abbia effettivamente letto l’email.

Se l’operatore possiede altre informazioni, può tentare una correlazione: per esempio, potrebbe conoscere un indirizzo IP già utilizzato da un utente autenticato sul proprio sito e confrontarlo con quello registrato durante il caricamento del logo.

Una corrispondenza può fornire un indizio, non necessariamente una prova dell’identità del destinatario: indirizzi condivisi, NAT, VPN, proxy e cambiamenti della connessione rendono questa tecnica piuttosto debole. Va inoltre ricordato che gli indirizzi IP possono costituire dati personali e che la loro raccolta e conservazione rientrano negli obblighi applicabili del GDPR.

2. Cookie già presenti nel browser

Un secondo meccanismo riguarda i cookie. Se l’applicazione di posta visualizza direttamente le immagini attraverso un browser che possiede già un cookie del dominio interessato, la richiesta potrebbe includerlo automaticamente, in funzione delle impostazioni del browser e degli attributi del cookie.

GET /logo.png HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123

Il server potrebbe così associare la richiesta a una sessione già conosciuta, anche se il percorso dell’immagine è identico per tutti i destinatari.

Come spiega la documentazione MDN sui cookie di terze parti, la trasmissione di queste informazioni dipende da restrizioni e attributi come SameSite, oltre che dalle politiche adottate dal browser.

Non è però una tecnica universalmente funzionante nel caso dei messaggi di posta: Gmail Web utilizza i proxy di Google per il caricamento delle immagini, impedendo ai mittenti di leggere o impostare cookie tramite tali risorse. Google lo chiarisce nella propria documentazione ufficiale. Anche altri client e servizi applicano meccanismi di protezione che rendono il tracciamento basato sui cookie inaffidabile o impossibile.

3. Identificatori nel percorso o nel sottodominio

Non bisogna confondere l’assenza di parametri nella query string con l’assenza di identificatori nell’URL. Si considerino queste due risorse:

https://www.example.com/utenti/a8f2/logo.png
https://www.example.com/utenti/b7e9/logo.png

Oppure:

https://a8f2.example.com/logo.png
https://b7e9.example.com/logo.png

Il nome del file rimane invariato, ma ogni destinatario della mail potrebbe ricevere un percorso o un sottodominio diverso: il server può quindi riconoscere l’identificatore direttamente dalla richiesta, senza ricorrere ad alcuna query string. Si tratta, a tutti gli effetti, di un possibile sistema di tracciamento individuale.

4. Correlazione con altri eventi registrati dal server

Esiste poi un caso meno immediato: il logo ha esattamente lo stesso URL per tutti, ma il server registra ogni richiesta e la confronta con altri eventi: un soggetto potrebbe disporre dei log degli accessi al proprio sito, dei dati relativi alle sessioni autenticate e delle informazioni sull’invio delle newsletter.

Incrociando orari, indirizzi IP e altri elementi, potrebbe tentare di collegare il download dell’immagine a un destinatario conosciuto.

Ma attenzione: una correlazione statistica non equivale a un’identificazione certa. Quando più utenti condividono lo stesso IP, oppure il servizio di posta utilizza un proxy, attribuire una richiesta a uno specifico iscritto può diventare impossibile.

Il punto giuridicamente rilevante è che l’eventuale analisi e correlazione di dati personali costituisce a sua volta un trattamento da valutare secondo le regole applicabili.

I normali log del server sono quindi vietati?

Assolutamente no. Il provvedimento del Garante non introduce un divieto generale di registrare gli accessi HTTP legati alla gestione e al caricamento lato client delle immagini.

La conservazione di registrazioni tecniche (“log“) può rispondere a esigenze di sicurezza informatica, diagnostica, prevenzione degli abusi e amministrazione dei sistemi.

Il GDPR, all’articolo 6, contempla diverse basi giuridiche per il trattamento dei dati personali, mentre l’articolo 5 impone principi come limitazione delle finalità, minimizzazione e limitazione della conservazione.

Occorre tuttavia distinguere due operazioni: registrare richieste HTTP per gestire il server e analizzare sistematicamente quegli stessi dati per ricostruire il comportamento dei destinatari delle email. La seconda attività non diventa automaticamente lecita soltanto perché utilizza informazioni già disponibili nei log.

Qualsiasi log tecnico non è affatto considerato sempre e comunque estraneo all’articolo 122 del Codice Privacy: la qualificazione richiede di esaminare il funzionamento concreto della risorsa, le informazioni acquisite e le finalità perseguite.

Chi deve dimostrare che logo.png serve effettivamente a tracciare?

La presenza di un’immagine remota in una mail ricevuta da un soggetto terzo non basta, da sola, a dimostrare l’esistenza di un sistema di profilazione.

Un accertamento tecnico dovrebbe valutare gli URL delle risorse, gli eventuali identificatori, gli header HTTP, i log, la configurazione dei server e l’utilizzo successivo delle informazioni raccolte.

Esiste però un elemento giuridico importante: il principio di accountability, previsto dall’articolo 5, paragrafo 2 del GDPR: il titolare del trattamento deve essere in grado di dimostrare il rispetto delle disposizioni applicabili. Non può quindi limitarsi a sostenere che nessuno abbia provato l’esistenza del tracciamento.

Allo stesso tempo, non è corretto presumere un trattamento illecito soltanto perché un’email contiene immagini scaricate da un server remoto: l’eventuale valutazione deve fondarsi su elementi tecnici e sulle effettive modalità di trattamento.

Il ruolo dei DPO e il rischio di interpretazioni eccessivamente restrittive

La scadenza del 29 ottobre 2026 ha costretto molti fornitori a introdurre nuove funzionalità per disattivare il tracciamento attraverso l’uso dei tracking pixel nelle email, gestire le revoche e separare le preferenze degli iscritti.

Il risultato è una situazione disomogenea: alcune aziende preferiscono rimuovere completamente i tracking pixel, altre aggiornano soltanto le informative, altre ancora devono verificare se i consensi precedentemente raccolti siano effettivamente idonei. Per tante realtà d’impresa, soprattutto di piccole e medie dimensioni, una parte del problema ha a che vedere – ancora una volta, purtroppo – con la difficoltà di tradurre prescrizioni giuridiche in configurazioni tecniche proporzionate.

Il Data Protection Officer (DPO) ha il (gravoso) compito di valutare rischi e conformità, ma una raccomandazione prudenziale non dovrebbe essere presentata come un divieto imposto dalla legge. In generale, è importante controllare attentamente quali informazioni siano raccolte, chi possa accedervi, se il monitoraggio sia individuale o aggregato e quali possibilità di scelta siano effettivamente disponibili per gli utenti.

Le nuove regole possono anche rappresentare un’occasione per correggere prassi poco trasparenti, senza tuttavia trasformarsi in un obbligo di rinunciare a qualsiasi statistica sulle comunicazioni inviate.

Il vero problema non è il tracking pixel, ma l’utilizzo dei dati

Un’immagine chiamata tracking.gif non è necessariamente più invasiva di un file chiamato logo.png: entrambe le risorse possono generare richieste HTTP e, in determinate condizioni, consentire la raccolta di informazioni sui destinatari.

La differenza viene a galla quando si esaminano gli identificatori disponibili, i trattamenti effettuati e le finalità perseguite.

Il provvedimento n. 284/2026 affronta quindi un problema reale, ma la sua applicazione richiede valutazioni tecniche puntuali: eliminare un pixel trasparente e continuare a monitorare gli utenti attraverso un’immagine visibile non risolve il problema. Allo stesso modo, considerare sospetta qualsiasi immagine remota significa confondere il normale funzionamento del Web con un trattamento specificamente finalizzato al monitoraggio (anche se, e non è un caso, molti client di posta particolarmente attenti alla privacy bloccano di default la visualizzazione di tutte le immagini remote presenti nel codice HTML di ogni mail ricevuta…).

Per chi pubblica siti Web e invia newsletter, la questione dovrebbe essere capire quali dati raccoglie davvero, perché li conserva e come li utilizza. Su questi elementi dovrebbe concentrarsi il confronto fra amministratori di sistema, sviluppatori e consulenti privacy. Non sul nome o sulle dimensioni di un file PNG.