Bisogna cambiare il modulo di iscrizione perché Chrome ora sa confermare un indirizzo Gmail con un clic? L’8 luglio 2026 Google ha aperto l’origin trial di un nuovo protocollo, l’Email Verification Protocol (EVP): l’emittente attesta che esiste una sessione attiva presso il fornitore di posta e il browser trasporta la prova, senza inviare un’email di conferma. In pratica, questo elimina un attrito preciso, quello del codice monouso o del link di conferma ricevuto via email, il passaggio in cui il tuo strumento di emailing mostra tutto verde mentre il tasso di hard bounce sale in silenzio. Quello che il protocollo dimostra, e soprattutto quello che non dimostra, si legge in una griglia di 12 situazioni di raccolta.
Il meccanismo del protocollo EVP, in 6 fasi
Il protocollo distingue 3 ruoli. Il validatore raccoglie l’indirizzo email sul proprio modulo. Il fornitore di posta ospita la casella. L’emittente, accounts.google.com per un indirizzo Gmail, gestisce la sessione dell’account. Possedere un indirizzo e avere una sessione attiva presso il proprio fornitore sono due cose distinte: il protocollo verifica solo la seconda. Servono inoltre due condizioni. L’utente deve essere connesso alla propria casella di posta nello stesso profilo Chrome. Deve anche scegliere il proprio indirizzo dall’autocompletamento invece di digitarlo a mano. Senza di esse, il protocollo non genera alcun token. Il percorso si articola in 6 fasi.
- L’utente sceglie il proprio indirizzo dall’autocompletamento del browser, mai digitandolo manualmente.
- Chrome interroga il record DNS _email-verification del dominio per identificare l’emittente responsabile.
- L’emittente conferma che esiste una sessione attiva per quell’account, senza rivelare altre informazioni sull’utente.
- Genera un Email Verification Token in formato SD-JWT+KB, ovvero un token a divulgazione selettiva legato a una chiave pubblica effimera, firmato in EdDSA o in ES256.
- Il token transita in un campo nascosto del modulo al momento dell’invio.
- Il server del sito esegue 5 controlli: decodifica del JWT, verifica di email_verified, del nonce e dell’audience, validazione del key binding, interrogazione DNS, quindi verifica della firma tramite l’endpoint well-known dedicato.
Il meccanismo ricorda quello di BIMI, un altro protocollo che si basa su un record DNS e su un’adozione fornitore per fornitore, mai universale fin dal primo giorno. Se un controllo fallisce o se il token è assente, il sito torna al proprio flusso abituale. Google la definisce un miglioramento progressivo.
I metodi di verifica attuali costringono l’utente a lasciare il sito, con il rischio che abbandoni la sessione prima di aver completato l’iscrizione. Rowan Merewood, Staff Developer Relations Engineer presso Google, Chrome for Developers, 8 luglio 2026.
La griglia: dove il protocollo risponde, dove non serve a nulla
12 situazioni di raccolta, 12 risposte diverse. Il protocollo copre solo una fascia ristretta del percorso di iscrizione: quella in cui Chrome e Gmail si combinano, con l’autocompletamento effettivamente utilizzato sullo stesso profilo. Su Safari, Apple ha già il proprio livello con Nascondi la mia email, un meccanismo indipendente che ridistribuisce gli indirizzi delle tue liste senza alcun rapporto con il protocollo di Chrome.
| Situazione di raccolta | EVP risponde? | Cosa fai |
|---|---|---|
| Iscrizione Gmail in Chrome, indirizzo scelto tramite l’autocompletamento | Sì | Il token viene accettato, lo conservi come prova di possesso al momento T |
| Iscrizione Gmail in Safari, Firefox o un browser in-app (LinkedIn, Instagram) | No | Ritorno al flusso classico di email di conferma |
| Indirizzo aziendale su un dominio senza record DNS _email-verification | No | Verifica dell’indirizzo prima dell’invio |
| Outlook, Yahoo, Proton, finché non emettono un token | No | Verifica dell’indirizzo |
| Errore di battitura nel dominio, gmial.com invece di gmail.com | No, nessun emittente risponde | Controllo della sintassi e verifica dei record MX |
| Catch-all aziendale | No | Verifica dell’indirizzo |
| Indirizzo usa e getta, se il fornitore un giorno implementa l’emittente | Sì: è la trappola | Rilevamento di indirizzi usa e getta a integrazione del token |
| Indirizzo di ruolo su Workspace, contact@ o info@ | Sì ma valore marketing nullo | Filtraggio degli indirizzi di ruolo |
| Database già raccolto, migliaia di contatti in archivio | Fuori perimetro per costruzione | Pulizia del database, per esempio tramite CaptainVerify |
| Indirizzo validato 8 mesi fa, casella piena o chiusa da allora | Fuori perimetro, la validazione è un’istantanea | Riverifica periodica |
| Importazione CRM, file da fiera, inserimento telefonico | Fuori perimetro | Verifica dell’indirizzo |
| Prova di consenso GDPR | No, il protocollo attesta un possesso tecnico, insufficiente come prova di consenso | Conservare una traccia di opt-in distinta |
Il caso più controintuitivo si trova in una sola riga della tabella. Un indirizzo usa e getta, ospitato presso un fornitore che un giorno implementasse l’emittente, supererebbe il controllo EVP con un token perfettamente valido. Il token misura soltanto una sessione attiva al momento T; non dice nulla sulla durata di vita prevista della casella, né sull’intenzione reale dietro l’iscrizione. Un indirizzo Yopmail o Mailinator che disponesse di un proprio emittente firmerebbe un token tanto pulito quanto quello di un indirizzo Gmail classico.
L’altro punto cieco riguarda il tempo. Il token conferma un possesso al momento dell’iscrizione, mai dopo. Su un indirizzo appena creato, lo scarto tra quanto afferma il protocollo e la realtà della casella resta marginale. Dopo alcuni mesi di inattività, invece, nulla nel meccanismo segnala una casella piena o abbandonata da mesi. EVP del resto non ha questo scopo: si limita alla prova di possesso al momento della raccolta, un’istantanea che si degrada senza mai aggiornarsi.
Una terza zona di incertezza riguarda gli indirizzi aziendali. Google Workspace rivendicava oltre 11 milioni di clienti paganti nel quarto trimestre 2025, cifra annunciata da Sundar Pichai il 4 febbraio 2026, altrettante organizzazioni le cui caselle sono ospitate da Google. La documentazione non dice se questi domini possano pubblicare il record _email-verification e rientrare nella prima colonna della griglia. La riga della tabella resta condizionata all’assenza di questo record, mai al tipo di indirizzo.
Il token EVP può servire come prova GDPR?
La documentazione di Chrome non dedica alcuna sezione alla privacy. Il GDPR non vi compare. Nemmeno il consenso marketing, né la durata di conservazione prevista per il token. Questo silenzio rimanda la decisione al titolare del trattamento piuttosto che al browser.
Una salvaguardia esiste comunque lato utente. Chrome mostra una richiesta di autorizzazione la prima volta che un indirizzo viene fornito per la convalida; questa richiesta non riappare più in seguito per lo stesso indirizzo. La prima convalida non avviene quindi all’insaputa della persona iscritta. Per quell’indirizzo, le successive non richiedono più nulla.
Il token incorpora dati personali concreti: l’emittente (iss), l’indirizzo o il suo equivalente (email), un indicatore di validità (email_verified), una marca temporale (iat), una chiave di conferma (cnf), l’origine del sito (aud), un nonce e un hash di conferma (sd_hash). Conservarlo come giustificativo equivale a trattenere un dato personale, soggetto ai principi di minimizzazione e limitazione della conservazione. Per quanto tempo conservarlo? La documentazione non lo precisa. È una questione da definire con il tuo DPO piuttosto che con il tuo fornitore tecnico.
Un dettaglio cambia le carte in tavola sul fronte della minimizzazione: la claim email può essere oggetto di divulgazione selettiva. Configurata in questo modo, trasmette al validatore un hash invece dell’indirizzo in chiaro, un’impostazione da verificare prima di qualsiasi messa in produzione.
L’articolo 7.1 del GDPR impone al titolare del trattamento di essere in grado di dimostrare il consenso della persona. Il clic di conferma del double opt-in svolge oggi questo ruolo. Il token EVP non lo sostituisce: attesta un possesso tecnico della casella al momento dell’iscrizione, senza dire nulla sull’accordo a ricevere messaggi in seguito. Risolve invece un altro problema, che il double opt-in copre solo in modo imperfetto, quello dell’obiezione «non sono stato io a inserire questo indirizzo». Il double opt-in dimostra il consenso, il token dimostra il possesso della casella al momento dell’iscrizione: un modulo che combina entrambi chiude entrambi gli angoli contemporaneamente.
Sulla riservatezza lato emittente, Google è esplicito: «L’emittente vede solo una richiesta di verifica dell’esistenza dell’utente, non vede quale sito ha avviato la richiesta.» L’architettura del token rende credibile questa affermazione: è il browser a costruire il token di key binding contenente l’origine del sito e il nonce, firmato con la chiave effimera, dopo aver ricevuto il token dall’emittente. Quest’ultimo non ha quindi mai bisogno di conoscere il sito destinatario per firmare la propria parte del token.
Due domande restano senza risposta nella documentazione attuale. Il ruolo giuridico esatto dell’emittente nella catena resta non precisato: agisce come titolare del trattamento o come responsabile del trattamento per conto terzi? La documentazione tace anche sui trasferimenti fuori dall’Unione Europea, anche se l’emittente è di fatto il fornitore che già ospita la casella di posta della persona, e non dice nulla sul trattamento del token stesso né sulla sua localizzazione.
Calcolare la copertura reale del protocollo
Chrome rappresenta il 65,23% delle sessioni browser nel mondo a maggio 2026, una cifra che sale al 76,39% solo su desktop (StatCounter, maggio 2026). Questa quota globale ignora la tua copertura EVP reale, che dipende esclusivamente dai tuoi dati di traffico e di iscrizione. Sul fronte della posta elettronica, Gmail viene accreditato di circa 1,8 miliardi di utenti attivi nel mondo, una stima Statista di novembre 2024 che il settore riprende in assenza di pubblicazioni regolari da parte di Google. Questo volume fissa un tetto teorico, mai la tua quota reale: una base alimentata da indirizzi aziendali e una base alimentata da iscrizioni consumer non danno affatto la stessa percentuale.
Bastano 3 numeri. La quota di traffico Chrome sul tuo modulo di iscrizione, leggibile in Google Analytics o Matomo. La quota di indirizzi Gmail tra le tue iscrizioni recenti, estraendo il dominio dalla tua base ESP. E la quota di queste iscrizioni in cui l’autocompletamento ha effettivamente compilato il campo invece di una digitazione manuale, un dato che nessuna API restituisce nativamente e che va strumentato da soli, per esempio confrontando gli eventi input e change scatenati sul campo email.
Moltiplicare i primi due numeri dà un tetto massimo. Il terzo, quasi sempre ignorato, lo fa scendere.
Il montaggio a 3 livelli, dal token all’invio
La reazione immediata, una volta compreso il meccanismo: se Chrome convalida già l’indirizzo all’iscrizione, a che serve continuare a pagare una verifica prima dell’invio? La risposta sta nel perimetro del token, che si ferma esattamente dove indica la griglia.
Il token permette di saltare il passaggio del clic sul link di conferma, per le iscrizioni Gmail avvenute tramite Chrome. Il double opt-in mantiene così il proprio ruolo, descritto sopra: la prova di un consenso attivo, marcato temporalmente in pratica per poterlo dimostrare come richiede l’articolo 7.1 del GDPR. Un token EVP non sostituisce né la casella spuntata né la marca temporale conservate nel database al momento del consenso.
Dal 2024 Google fissa una soglia di complaint rate allo 0,3% per gli invii massivi, pena la marcatura dei messaggi come spam o il rifiuto lato Gmail, una cifra già visibile nelle tabelle di Google Postmaster Tools per dominio mittente. Un indirizzo usa e getta o una casella chiusa che riceve comunque la campagna spinge questo tasso verso l’alto, anche in piena fase di IP warmup, indipendentemente da ciò che mostrava il token all’iscrizione. La deliverability si gioca al momento dell’invio, quando la raccolta è già lontana alle spalle. Non è il primo protocollo tecnico a ridisegnare un anello della catena senza eliminare gli altri: DKIM2 ha seguito la stessa logica sul fronte dell’autenticazione dei messaggi.
Il controllo che verifica la sintassi, il dominio MX e talvolta la storia di deliverability prima dell’invio, quello che effettua CaptainVerify, si inserisce logicamente tra la raccolta e la campagna. L’unico modo per sapere se la tua base ha bisogno di questo filtro è farla passare su un campione prima del prossimo invio.
Quello che va conservato nel database, come minimo: la traccia di opt-in GDPR, lo stato dell’ultimo controllo di list hygiene e la data dell’ultima campagna inviata senza bounce. Il token EVP, invece, non ha vocazione a essere conservato oltre la sessione di iscrizione.
Gmail resta oggi l’unico emittente rivolto al grande pubblico. Il protocollo, invece, è portato avanti dai browser Chromium: Chrome dalla versione 150, Edge tramite un proprio origin trial lato Microsoft. La sua traiettoria di standardizzazione è già tracciata: un Internet-Draft firmato da Dick Hardt e Sam Goto è depositato presso l’IETF dal 17 giugno 2026, in una revisione datata 4 luglio, in presentazione individuale, senza gruppo di lavoro né validazione allo stato attuale. Validity stima nella sua analisi di luglio 2026 che il double opt-in faccia perdere dal 20 al 35% degli iscritti al momento della conferma, un attrito che EVP potrebbe effettivamente ridurre lato Gmail. Se Outlook o Yahoo un giorno implementassero un proprio emittente, la prima colonna della griglia si allargherebbe; senza di loro, resta circoscritta a Gmail.
Domande frequenti sull’Email Verification Protocol
Il protocollo EVP funziona su mobile o in un’app?
La documentazione non chiarisce esplicitamente questo punto. Il protocollo presuppone l’autocompletamento del browser, il che esclude di fatto i contesti in cui non è disponibile, in particolare alcuni browser in-app.
Quali browser supportano EVP nel 2026?
Chrome dalla versione 150, tramite l’origin trial aperto l’8 luglio 2026. Edge segue con un proprio origin trial, elencato nella sezione Implementation Status del draft IETF: stesso meccanismo Chromium, con un token da registrare lato Microsoft, distinto da quello di Chrome. Sul fronte Safari, nessun annuncio a oggi.
Il protocollo funziona con Outlook o Yahoo?
Non ancora. Gmail è l’unico fornitore di posta a emettere token al lancio. L’API destinata agli altri fornitori di posta resta in sviluppo presso Google.
Bisogna attivare subito l’origin trial?
Solo se Chrome e Gmail rappresentano una quota misurabile delle tue iscrizioni. Il trial impone limiti di traffico e un fallback obbligatorio verso l’email di conferma classica in caso di fallimento.
