Una dissezione tecnica e normativa del tracciamento invisibile nelle email commerciali: dal MIME al gateway, dalla pseudonimizzazione alla prova del consenso.
1. Il fatto normativo del 29 ottobre 2026
Il 17 aprile 2026 il Garante per la protezione dei dati personali ha adottato le Linee Guida in materia di utilizzo di tracking pixel nelle comunicazioni di posta elettronica, pubblicate nella Gazzetta Ufficiale n. 98 del 29 aprile 2026. Il termine di adeguamento di sei mesi indicato dall'Autorità è scaduto il 29 ottobre 2026. Nel vademecum del 5 ottobre 2026 il Garante ha ricordato che i controlli sull'applicazione delle linee guida rientrano nel piano ispettivo del secondo semestre 2026.
La disciplina non nasce nel 2026: le linee guida chiariscono come applicare l'art. 122 del Codice privacy, derivato dall'art. 5(3) della direttiva ePrivacy, insieme al GDPR. Perciò non è corretto descrivere la scadenza come l'entrata in vigore di un nuovo divieto generale di tutte le immagini remote: è una scadenza di adeguamento ai criteri esplicitati dall'Autorità.
Fonti: Provvedimento 17 aprile 2026, doc. 10241943; Vademecum 5 ottobre 2026; Scheda tematica Garante.
2. Threat model: che cosa può sapere realmente un mittente?
Un messaggio email è un contenitore MIME. Nella parte text/html può comparire un riferimento a una risorsa remota, per esempio un'immagine 1×1 trasparente. La risorsa non è incorporata: viene recuperata quando un client, un proxy o un sistema di sicurezza decide di caricarla. L'URL può codificare un identificatore univoco del messaggio, del destinatario o della campagna.
From: marketing@example.invalid To: user@example.invalid MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="demo" --demo Content-Type: text/plain; charset=UTF-8 Offerta commerciale (versione testo). --demo Content-Type: text/html; charset=UTF-8Offerta commerciale
--demo--
Questo è un esempio sintetico, non un frammento estratto da email reali. Quando l'immagine è richiesta, il server remoto può registrare timestamp, percorso URL, token, IP del richiedente, User-Agent e header HTTP disponibili. La presenza di un identificatore univoco consente una correlazione con il database del mittente anche se l'indirizzo email non compare esplicitamente nell'URL.
Mail sender ──SMTP/MIME──> Mailbox
│
HTML renderer / scanner
│ GET /o.gif?rid=...
▼
Proxy / Internet egress
│
▼
Tracking endpoint
│
token → recipient mapping
│
▼
event log / marketing CRMIl server può osservare una richiesta HTTP, non una prova certa di lettura umana. Un proxy, un antivirus o un client con prefetch possono generare l'evento senza che l'utente abbia letto il messaggio. Un client che blocca le immagini può invece leggere il messaggio senza generare alcuna richiesta.
3. Semantica degli eventi: opened ≠ read
| Evento | Osservabile? | Limite epistemico |
|---|---|---|
| Consegna SMTP | Accettazione dal server ricevente | Non prova arrivo in inbox o lettura |
| Download immagine | Richiesta GET al server/proxy | Può essere prefetch, scanner, cache o apertura reale |
| Click su link riscritto | Richiesta all'endpoint di redirect | Può essere eseguita da scanner o protezione URL |
| Tempo di lettura | Generalmente non direttamente | Inferenza statistica, non telemetria certa |
| Inoltro | Talvolta richieste da contesti differenti | Non identifica automaticamente chi ha inoltrato |
| Cancellazione/archiviazione | Non rilevabili in modo generale da un normale pixel HTTP | Richiedono altre integrazioni, segnali o inferenze |
In una piattaforma di marketing, open_count è spesso un conteggio di richieste o di eventi deduplicati secondo regole del fornitore. La deduplicazione per token, IP o finestra temporale non trasforma l'evento in una conferma di lettura. Anche un eventuale header Referer non è affidabile: dipende da client, policy e proxy.
4. HTTP, cache e proxy: perché l'IP osservato può essere falso rispetto al destinatario
Le immagini possono essere recuperate da un proxy remoto. Apple Mail Privacy Protection, quando abilitata, nasconde l'IP del destinatario e scarica i contenuti remoti privatamente in background, anche indipendentemente dall'apertura effettiva. Il server di tracking può vedere l'IP del proxy e un timestamp di prefetch. Un'immagine servita dalla cache potrebbe non generare una seconda richiesta quando viene mostrata all'utente.
Con servizi di posta che impiegano proxy per le immagini, il mittente non può assumere che remote_addr sia l'IP dell'utente. Analogamente, un User-Agent del proxy non identifica necessariamente browser, dispositivo o sistema operativo finale. Gli header Cache-Control: no-store o URL univoci possono influenzare la cache, ma non garantiscono di aggirare i comportamenti privacy dei client.
Il tracciamento tramite click è una superficie distinta: un link https://click.example.invalid/r?id=... può registrare un evento e poi reindirizzare verso il sito commerciale. I filtri antiphishing che seguono automaticamente i link possono produrre falsi positivi; per questa ragione un semplice click non dovrebbe autorizzare operazioni irreversibili o attestare un consenso.
Riferimento: Apple — Protect email privacy in Mail.
5. Il quadro europeo: due livelli di legalità da non confondere
Livello 1 — ePrivacy / art. 122 Codice privacy. L'art. 5(3) della direttiva 2002/58/CE, recepito in Italia dall'art. 122 del d.lgs. 196/2003, riguarda memorizzazione di informazioni nel terminale e accesso a informazioni già memorizzate. L'EDPB ha chiarito il campo tecnico di applicazione nelle Guidelines 2/2023, versione finale del 16 ottobre 2024. Le linee guida italiane del 2026 qualificano il tracking pixel email nell'ambito dell'art. 122.
Livello 2 — GDPR. Quando gli eventi sono associati a persone identificate o identificabili, si applicano i principi di liceità, correttezza, trasparenza, limitazione delle finalità, minimizzazione, conservazione limitata, sicurezza e accountability (art. 5), oltre agli obblighi informativi (artt. 12–14), privacy by design (art. 25), rapporti con responsabili (art. 28), sicurezza (art. 32), eventuale DPIA (art. 35) e diritti dell'interessato, compresa opposizione al marketing diretto (art. 21).
Livello 3 — marketing elettronico. L'invio della comunicazione commerciale è una questione distinta dall'impiego del pixel. L'art. 13 della direttiva ePrivacy e l'art. 130 del Codice privacy disciplinano il marketing via email. Esistono ipotesi specifiche di cosiddetto soft spam per propri prodotti o servizi analoghi verso clienti esistenti, alle condizioni di legge: questa eventuale possibilità di inviare la mail non equivale automaticamente a un'autorizzazione al tracking individuale.
Riferimenti: EDPB Guidelines 2/2023; Direttiva 2002/58/CE; GDPR; Garante, linee guida 2026.
6. Quando il consenso è richiesto e quando possono esistere deroghe
Il Garante individua come caso tipico soggetto a consenso il pixel che misura il comportamento del singolo destinatario per ottimizzare una campagna, personalizzare contenuti, modulare frequenza o profilare preferenze. In linea generale il consenso dev'essere preventivo, libero, informato, specifico e inequivocabile.
Le linee guida non affermano tuttavia che ogni pixel richieda sempre il consenso: sono contemplate condizioni derogatorie da valutare rigorosamente, per esempio statistiche realmente aggregate con misure che impediscano di monitorare il singolo destinatario, determinati usi strettamente necessari alla sicurezza, e specifiche comunicazioni istituzionali o di servizio per le quali la verifica della presa di conoscenza sia rilevante. La classificazione non dipende dall'etichetta commerciale attribuita dal fornitore, ma dalla funzione effettiva e dall'implementazione tecnica.
| Scenario | Valutazione di principio |
|---|---|
| Campagna con token univoco, eventi per singolo destinatario, scoring CRM | Consenso preventivo generalmente necessario |
| Un pixel comune alla campagna, aggregazione e anonimizzazione effettiva dei log tecnici | Possibile deroga, subordinata alle condizioni indicate dal Garante |
| Token per proteggere un'azione autenticata e strettamente necessaria | Possibile deroga di sicurezza, da motivare e documentare |
| Comunicazione obbligatoria di sicurezza o contrattuale | Possibile deroga in casi specifici, non generalizzabile |
| Newsletter promozionale con misurazione delle aperture individuali | Non basta definirla “statistica” per evitare il consenso |
Il Garante precisa inoltre che il consenso al pixel in comunicazioni promozionali può in linea di principio essere incluso nel consenso generale al marketing, ma solo se la formulazione rende il tracciamento conoscibile e la scelta è effettivamente libera e informata. È richiesta la possibilità di revoca selettiva: continuare a ricevere email senza pixel, oppure cessare le comunicazioni. Non si può dedurre l'illecito dalla sola presenza del pixel senza esaminare informativa, finalità, consenso ed eventuale deroga.
7. Caso pratico: email commerciali di operatori di telecomunicazioni
Si consideri una email promozionale apparentemente inviata da un grande operatore telefonico. Il nome visualizzato nel campo From non autentica da solo il mittente. Una verifica tecnica separa almeno cinque domande: (1) il dominio di invio è autenticato? (2) il messaggio contiene risorse remote? (3) queste risorse portano token individuali? (4) quale soggetto controlla l'endpoint? (5) esistono informativa e consenso o una deroga documentata?
La presenza di loghi, domini di CDN, ESP (email service provider) o link di unsubscribe non dimostra automaticamente tracciamento illecito. Viceversa, un dominio apparentemente legittimo non esclude l'impiego di un sistema di profilazione di terze parti. I controlli SPF, DKIM e DMARC servono a verificare aspetti dell'autenticazione e dell'allineamento del dominio, non la conformità privacy dei pixel.
8. Acquisizione forense non invasiva di un messaggio
Per verificare un messaggio senza generare richieste indesiderate, si lavora preferibilmente sul file .eml esportato dal client, con caricamento automatico delle immagini remote disabilitato. Si conservano l'originale e un hash SHA-256, evitando di inoltrarlo a servizi di analisi pubblici perché potrebbe contenere indirizzi personali, token e dati contrattuali.
Una pipeline difensiva può estrarre gli header Authentication-Results, Received, List-Unsubscribe, il MIME tree, gli attributi src delle immagini e gli href dei link. I token devono essere oscurati nei report; non è necessario visitare gli URL per individuarli.
Evidence acquisition (.eml, read-only)
│
├─ SHA-256 + chain of custody
├─ MIME structure and HTML extraction
├─ Remote image inventory (no GET)
├─ Link / redirect inventory (no GET)
├─ Authentication-Results review
└─ Privacy notice and consent evidence review
│
▼
Risk assessment
9. Laboratorio C#/.NET 10: estrazione statica degli URL da HTML
Questo esempio non effettua alcuna richiesta di rete. Legge un file HTML di laboratorio, identifica gli elementi img e mostra l'host, il percorso e i nomi dei parametri, senza stampare i valori dei token. Usa HtmlAgilityPack tramite NuGet per evitare parsing HTML con espressioni regolari.
// dotnet new console -n PixelInspector -f net10.0
// cd PixelInspector
// dotnet add package HtmlAgilityPack
// Salvare una copia autorizzata della parte HTML come message.html
using HtmlAgilityPack;
var path = args.Length > 0 ? args[0] : "message.html";
var html = await File.ReadAllTextAsync(path);
var doc = new HtmlDocument();
doc.LoadHtml(html);
var images = doc.DocumentNode.SelectNodes("//img[@src]")
?? Enumerable.Empty<HtmlNode>();
foreach (var img in images)
{
var raw = HtmlEntity.DeEntitize(img.GetAttributeValue("src", ""));
if (!Uri.TryCreate(raw, UriKind.Absolute, out var uri)) continue;
if (uri.Scheme != Uri.UriSchemeHttps && uri.Scheme != Uri.UriSchemeHttp)
continue;
var names = uri.Query.TrimStart('?')
.Split('&', StringSplitOptions.RemoveEmptyEntries)
.Select(part => Uri.UnescapeDataString(part.Split('=', 2)[0]));
Console.WriteLine($"host={uri.Host}; path={uri.AbsolutePath}; " +
$"width={img.GetAttributeValue("width", "?")}; " +
$"height={img.GetAttributeValue("height", "?")}; " +
$"query_keys=[{string.Join(",", names)}]");
}
Limiti intenzionali: il codice non analizza direttamente il MIME, non identifica i CSS background URL, non esegue normalizzazione IDN, non visita URL e non stabilisce automaticamente se una risorsa sia un tracking pixel. Per un parser completo del file .eml è opportuno utilizzare MimeKit e trattare le parti text/html secondo la struttura multipart. La dimensione 1×1 è un indizio, non una prova: anche un'immagine di grandi dimensioni può essere usata per il tracking.
10. Laboratorio ASP.NET Core: dimostrazione locale con dati sintetici
Il seguente endpoint restituisce un GIF trasparente 1×1 e conta le richieste per un token sintetico. Non registra IP, User-Agent o email, non usa cookie, non comunica con servizi esterni e non è destinato a essere esposto pubblicamente. Serve a osservare il meccanismo HTTP in un ambiente controllato.
// dotnet new web -n PixelLab -f net10.0
// Program.cs — avviare solo su localhost
using System.Collections.Concurrent;
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseUrls("http://127.0.0.1:5088");
var app = builder.Build();
var counts = new ConcurrentDictionary<string, int>();
byte[] gif = Convert.FromBase64String(
"R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=");
app.MapGet("/pixel/{id}", (string id) =>
{
if (id.Length > 64 || id.Any(c => !char.IsAsciiLetterOrDigit(c)))
return Results.BadRequest();
counts.AddOrUpdate(id, 1, (_, n) => n + 1);
return Results.File(gif, "image/gif");
});
app.MapGet("/stats", () => Results.Json(counts));
app.Run();Per testare: aprire localmente http://127.0.0.1:5088/pixel/DEMO123, poi /stats. La seconda richiesta potrebbe essere soddisfatta da una cache client in alcuni contesti. Questo dimostra perché un contatore di richieste HTTP non misura in modo affidabile il numero di letture. Il codice non costituisce un sistema di tracking utilizzabile in produzione.
11. Detect engineering: indicatori e falsi positivi
Un sistema di analisi statica può assegnare un punteggio di rischio a ciascuna risorsa esterna. Segnali possibili: dimensioni dichiarate minime, URL con token ad alta entropia, host terzo distinto dal dominio del mittente, endpoint dedicato a open events, assenza di valore visuale, parametri per campagna e destinatario. Ma nessuno di questi elementi prova, da solo, un trattamento illecito.
| Indicatore | Rischio tecnico | Possibile falso positivo |
|---|---|---|
| Immagine 1×1 | Open tracking | Elemento grafico o layout legacy |
| Query string univoca | Identificazione destinatario | Cache busting o asset firmato |
| Dominio terzo | Trasferimento a ESP/CDN | Hosting immagini legittimo |
| Link con redirect | Click tracking | Protezione URL antiphishing |
| Richieste multiple | Riaperture correlate | Proxy, scanner, prefetch |
Il DNS e i certificati TLS possono aiutare a identificare l'operatore tecnico dell'endpoint, ma l'hosting su un cloud provider non identifica il titolare del trattamento. La relazione titolare-responsabile va verificata nei contratti e nelle informative, non dedotta da un indirizzo IP.
12. Privacy engineering: minimizzazione, pseudonimizzazione e segregazione
Le linee guida del Garante suggeriscono, come possibile misura di privacy by design, identificatori non intelligibili e non sequenziali, con mappatura verso l'indirizzo email conservata in un ambiente separato. È un miglioramento rispetto a URL contenenti email in chiaro, ma non equivale ad anonimizzazione: se il token è ricollegabile al destinatario, resta un dato personale pseudonimizzato.
Per finalità statistiche realmente aggregate, la progettazione dovrebbe evitare la produzione di eventi individuali quando non necessari. Un'architettura che raccoglie prima tutti gli eventi per persona e li aggrega successivamente non è automaticamente equivalente a un sistema che non può identificare il destinatario. La verifica deve comprendere log applicativi, reverse proxy, CDN, analytics, backup, retention, accessi e fornitori.
Campaign-level token (same for all recipients)
│
HTTP endpoint
│
Remove/minimize IP,
UA and identifiers
│
Aggregate counters
│
Short retention / ACL
│
Aggregate dashboardLa liceità di una deroga resta una valutazione giuridico-tecnica contestuale. La sola scelta di un token comune non rende automaticamente anonimi tutti i dati di log.
13. Consenso come macchina a stati, non come checkbox
Un sistema robusto dovrebbe distinguere almeno Unknown, Granted, Denied, Withdrawn, conservando data, versione dell'informativa, finalità, provenienza della scelta e prova della raccolta. Il default per il tracking soggetto a consenso deve evitare l'invio di pixel individuali finché non esiste una base valida. Una revoca deve impedire il tracking nelle comunicazioni successive, senza imporre necessariamente la disiscrizione dalla newsletter.
UNKNOWN ── explicit consent ──> GRANTED
│ │
└── refusal ──> DENIED └── withdrawal ──> WITHDRAWN
Render(email):
if (individualTrackingRequiresConsent && state != GRANTED)
omitIndividualTrackingPixel();
else
applyDocumentedPurposeAndControls();Non è corretto considerare l'apertura del messaggio, il silenzio o l'assenza di opposizione come consenso espresso al pixel quando la legge lo richiede. Occorre inoltre separare la prova del consenso al marketing da quella relativa alle finalità di tracciamento, anche quando le informazioni sono presentate in un'unica esperienza di raccolta.
14. Sicurezza: phishing, link wrapping, redirect e correlazione
I pixel non sono necessariamente malware. Il rischio principale è la raccolta di telemetria e la correlazione dei comportamenti. Possono però aumentare la superficie di esposizione: caricamento di contenuti da domini terzi, possibili bug nei decoder di immagini, risoluzioni DNS, richieste verso host controllati da attaccanti e link di redirect che nascondono la destinazione finale. I client di posta moderni limitano l'esecuzione di script nel corpo HTML, ma ciò non elimina i rischi del caricamento remoto.
Le contromisure difensive comprendono blocco dei contenuti remoti, proxy privacy, riscrittura dei link da parte di sistemi antiphishing, scanning degli allegati, policy del mail gateway, autenticazione SPF/DKIM/DMARC e formazione degli utenti. Nessuna misura, da sola, sostituisce una valutazione completa. Il blocco delle immagini può ridurre il tracking ma compromettere contenuti legittimi; l'uso di un proxy può nascondere l'IP ma produrre eventi di apertura falsi.
15. Microsoft 365, Outlook, Apple Mail e client enterprise: modello di difesa
In un ambiente aziendale occorre verificare il comportamento reale del client e del gateway, non affidarsi a una singola impostazione astratta. Per esempio: Outlook classico, nuovo Outlook, Outlook sul web e app mobile possono differire nella gestione di contenuti remoti e download immagini; Apple Mail con Mail Privacy Protection opera attraverso un meccanismo di protezione differente. Il comportamento può inoltre variare in base a criteri dell'organizzazione, aggiornamenti e integrazioni antispam.
Una procedura di test sicura utilizza messaggi sintetici verso caselle di laboratorio, un endpoint locale o di test sotto il proprio controllo, e una matrice client × impostazione × gateway. Si registra se la risorsa viene richiesta prima dell'apertura, durante l'anteprima, dopo l'apertura e dopo una riapertura. Le conclusioni valgono per la configurazione testata, non per ogni installazione del prodotto.
16. Trasferimenti extra-SEE e catena dei fornitori
Se un ESP, CDN o sistema di marketing tratta eventi riferibili a interessati europei, occorre analizzare ruoli privacy, contratti di nomina, sub-responsabili, luoghi del trattamento e, ove applicabile, trasferimenti verso paesi terzi ai sensi del capo V GDPR. L'uso di un endpoint con dominio europeo o di un server fisicamente collocato nell'UE non risolve automaticamente la questione: contano accessi, supporto, subfornitori e flussi effettivi.
La verifica architetturale dovrebbe coprire data flow mapping, base giuridica, data retention, diritti degli interessati, cancellazione, logging, accessi amministrativi, gestione degli incidenti e possibili valutazioni d'impatto. Una DPIA non è obbligatoria per ogni pixel in modo automatico: va valutata secondo natura, ambito, contesto e rischi del trattamento.
17. Checklist tecnica per un'organizzazione europea
- Inventariare i template email e le risorse remote, incluse immagini, CSS, redirect e piattaforme di marketing automation.
- Distinguere invio marketing, analytics aggregata, open tracking individuale, click tracking e finalità di sicurezza.
- Identificare i titolari, responsabili e sub-responsabili e verificare gli accordi.
- Verificare informativa preventiva, consenso ove necessario, deroghe documentate e granularità della revoca.
- Assicurare che il rendering del template ometta il tracciamento individuale quando manca la condizione di liceità.
- Ridurre dati e retention in endpoint, log HTTP, proxy, CDN, backup e CRM.
- Testare client e gateway per falsi positivi, prefetch e cache.
- Documentare accountability, privacy by design, sicurezza e trasferimenti internazionali.
- Verificare il rispetto delle linee guida italiane alla luce della scadenza del 29 ottobre 2026.
18. Come verificare una singola email commerciale ricevuta
Un destinatario può esaminare il sorgente originale del messaggio senza cliccare link e senza caricare le immagini. Può identificare gli host remoti, verificare l'informativa privacy e l'eventuale area di gestione delle preferenze. Se desidera contestare un trattamento, può chiedere al mittente informazioni su finalità, categorie di dati, base giuridica, destinatari, conservazione e modalità di revoca/opposizione. Per il marketing diretto il GDPR riconosce il diritto di opposizione ai sensi dell'art. 21; il reclamo al Garante è uno strumento distinto, da valutare quando ricorrono i presupposti.
Un singolo URL non prova la violazione. È invece un elemento tecnico utile per porre domande precise: quale identificatore contiene? È associato al destinatario? Quali eventi vengono conservati? Qual è la finalità? Quale consenso o deroga giustifica l'accesso? È possibile continuare a ricevere le comunicazioni senza tracciamento?
19. Sintesi architetturale
Il tracking pixel è un meccanismo di osservazione indiretta basato su richieste HTTP. Il problema privacy non si esaurisce nell'immagine 1×1: nasce dalla correlazione tra token, identità, eventi, finalità e decisioni automatizzate. Il problema ingegneristico è separare una telemetria realmente necessaria e minimizzata dal monitoraggio individuale, preservando prova del consenso, revoca selettiva e tracciabilità dei flussi.
La lezione del 2026 è netta: in Europa non basta che una tecnologia sia tecnicamente comune o commercialmente utile. Dev'essere progettata per finalità legittime, trasparenza, minimizzazione e controllo effettivo da parte dell'interessato. Le linee guida italiane rendono particolarmente concreta questa esigenza per l'email marketing.
20. Fonti primarie e approfondimenti
- Garante Privacy, Provvedimento 17 aprile 2026 — Linee guida sui tracking pixel email.
- Garante Privacy, Vademecum 5 ottobre 2026 e termine 29 ottobre.
- Garante Privacy, scheda tecnica e FAQ.
- EDPB, Guidelines 2/2023, versione finale 16 ottobre 2024.
- Direttiva 2002/58/CE (ePrivacy), articoli 5 e 13.
- Regolamento (UE) 2016/679 (GDPR).
- Apple Support, Mail Privacy Protection.
- CNIL, Raccomandazioni sui tracking pixel email, 2026.
Nota: questo articolo è un approfondimento tecnico-normativo generale, non un parere legale su una specifica azienda o campagna. Gli esempi di codice sono dimostrativi e non sono stati eseguiti contro messaggi o servizi di terzi.
