10 settimane. È il tempo che è servito ad Apple per annunciare, a metà giugno 2026, un cambio di dominio per Hide My Email, per poi ritirarlo il 24 agosto 2026, dopo i feedback della sua community di sviluppatori. Nel concreto, gli alias Hide My Email di iCloud+ restano ospitati su icloud.com, esattamente come i normali indirizzi iCloud; solo Sign in with Apple cambia davvero dominio, più avanti nel 2026, migrando verso private.icloud.com, mantenendo comunque attivo privaterelay.appleid.com per gli indirizzi già creati. Per chi valida liste email o configura una allowlist per Sign in with Apple, la differenza ha un impatto diretto sulla lettura dei bounce e sulla logica di filtraggio.
Cosa ha annunciato Apple il 24 agosto 2026
La pagina sviluppatori di Apple aggiornata quel giorno porta un titolo sobrio, quasi marginale: «Update: New domain for Sign in with Apple». Hide My Email è sparito dal titolo, e Apple lo liquida in una frase nel corpo del testo: dopo aver esaminato i feedback della community, gli indirizzi restano su icloud.com. È così che Apple conferma la marcia indietro, senza un comunicato separato né un annuncio in pompa magna (Apple Developer News, 24 agosto 2026). Il testo precisa che i futuri indirizzi Sign in with Apple, finora generati su privaterelay.appleid.com, verranno d’ora in poi creati su private.icloud.com; gli indirizzi esistenti continuano a funzionare e a inoltrare i messaggi senza interruzioni. Nulla cambia invece per Hide My Email: gli alias restano nel formato alias@icloud.com, identico a quello esistente fin dal lancio della funzione.
Il progetto iniziale di giugno 2026: perché è saltato in 10 settimane
Il 15 giugno 2026, Apple annunciava l’esatto contrario: Sign in with Apple e Hide My Email si sarebbero fusi sotto un dominio comune, private.icloud.com. L’idea sembrava coerente sulla carta, unificare l’infrastruttura di messaggistica privata di Apple sotto un’unica bandiera tecnica. I feedback non si sono fatti attendere. Utenti e sviluppatori hanno segnalato un problema concreto nelle settimane successive, fino a spingere Apple a una retromarcia completa, 10 settimane dopo.
Perché un dominio dedicato avrebbe facilitato il blocco degli alias
Il ragionamento sta in una frase tecnica. Un dominio separato, riservato ai soli alias usa e getta, diventa un bersaglio banale per qualsiasi regola di blocco: basta aggiungere private.icloud.com a una lista nera di domini e tutti gli alias Hide My Email spariscono dal modulo di registrazione, senza toccare le vere caselle iCloud. È esattamente ciò che temevano i sostenitori della funzione. 9to5Mac documenta questa inversione nel suo resoconto del 24 agosto 2026. Restando su icloud.com, ogni alias si confonde nello stesso dominio delle centinaia di milioni di indirizzi iCloud reali. Bloccare questo dominio equivarrebbe a bloccare una parte significativa degli utenti iPhone, cosa che nessun servizio commerciale può permettersi.
Apple raccomanda ora agli sviluppatori che utilizzano Sign in with Apple di assicurarsi che i loro sistemi di account, la logica di validazione delle email e le allowlist accettino private.icloud.com oltre al dominio esistente privaterelay.appleid.com, precisa 9to5Mac citando la nota tecnica di Apple del 24 agosto 2026.
Il cambiamento non riguarda però tutte le integrazioni allo stesso modo. Le applicazioni che codificano in modo rigido il vecchio dominio nelle loro regole di validazione Sign in with Apple dovranno comunque aggiornare la configurazione entro fine anno, dato che il nuovo dominio si aggiunge al vecchio senza sostituirlo immediatamente.
Cosa cambia davvero da ora in avanti
Tre fatti distinti, spesso confusi nelle prime reazioni. Hide My Email resta su icloud.com, senza alcuna modifica per gli utenti né per i servizi che ricevono questi indirizzi. Sign in with Apple, invece, migra davvero verso private.icloud.com, con un calendario fissato a «più avanti nel 2026» senza data precisa comunicata al momento. Gli indirizzi privaterelay.appleid.com già emessi continuano a funzionare indefinitamente e a inoltrare la posta senza interruzioni di servizio annunciate. L’articolo pubblicato su questo blog a luglio presentava la migrazione come decisa per entrambi i domini; la situazione si è evoluta da allora: solo la parte relativa a Sign in with Apple del nostro precedente articolo sulla migrazione verso private.icloud.com resta valida oggi.
Cosa cambia per le tue liste e le tue validazioni email
«Le mie campagne finiscono in spam e non ho idea del perché, il mio tool di emailing dice che va tutto bene.» È il tipo di feedback che circola spesso tra i team growth quando un indirizzo icloud.com si comporta in modo diverso da una campagna all’altra. Il motivo sta in una riga: un alias Hide My Email e una casella iCloud personale condividono esattamente lo stesso dominio, la stessa infrastruttura MX e spesso lo stesso comportamento nel MAIL FROM. Il dominio quindi non dice nulla. L’unico indizio si nasconde nel nome utente: gli alias generati seguono un formato riconoscibile, due parole casuali seguite da un numero, del tipo sunny.breeze_49@icloud.com. Questo pattern individua la maggior parte degli alias senza però coprirli tutti. Nel frattempo intrappola anche i veri indirizzi costruiti come nome.cognome_84, un formato scelto da molti utenti per la propria casella personale. La sender reputation di icloud.com, condivisa tra alias e caselle vere, si comporta quindi come un catchall gigante su scala dell’intero provider.
Prima di concludere che basti filtrare gli indirizzi icloud.com dopo l’invio per limitare gli alias usa e getta: questo filtraggio post-hoc non funziona, perché bloccherebbe anche una parte massiccia di utenti reali. L’unico approccio efficace consiste nel verificare ogni indirizzo prima dell’invio, basandosi su segnali di engagement e deliverability piuttosto che sul nome del dominio, unico riferimento diventato ormai inutilizzabile dopo questa inversione di rotta. Sul fronte Sign in with Apple, l’adeguamento è più meccanico: qualsiasi logica di validazione o di allowlist deve ora accettare sia private.icloud.com sia privaterelay.appleid.com, pena il rifiuto di account legittimi creati dopo il cambio. Un test semplice consiste nel far ripassare un campione della base su questi due domini prima della prossima campagna, per verificare che il tasso di hard bounce non subisca contraccolpi.
FAQ
Bisogna bloccare gli indirizzi icloud.com per limitare le registrazioni tramite Hide My Email? No. Il blocco per dominio colpisce indistintamente gli alias e le vere caselle iCloud, una scelta che Apple ha proprio neutralizzato mantenendo Hide My Email su icloud.com invece che su un dominio separato.
Come riconoscere un alias Hide My Email da un vero indirizzo iCloud? Il dominio da solo non aiuta. Il nome utente, invece, dà un segnale: gli alias generati combinano due parole casuali e un numero. Questo pattern resta probabilistico, un vero indirizzo in nome.cognome_anno gli somiglia perfettamente. Il modo più sicuro consiste nell’incrociarlo con i segnali comportamentali dell’indirizzo (engagement, storico bounce, NDR) piuttosto che bloccare solo su questo criterio.
I vecchi indirizzi privaterelay.appleid.com smetteranno di funzionare? No. Apple non ha fissato alcuna data di dismissione e precisa che questi indirizzi continuano a inoltrare la posta senza interruzioni, parallelamente ai nuovi indirizzi creati su private.icloud.com.
Quando sarà completato il passaggio di Sign in with Apple a private.icloud.com? Apple non ha comunicato alcuna data di completamento, né un’eventuale futura dismissione del dominio privaterelay.appleid.com. Il calendario ufficiale si ferma a «più avanti nel 2026».
