10 semaines. C’est le temps qu’il aura fallu à Apple pour annoncer, mi-juin 2026, un changement de domaine pour Hide My Email, puis pour l’annuler le 24 août 2026, après les retours de sa communauté de développeurs. Concrètement, les alias Hide My Email d’iCloud+ restent hébergés sur icloud.com, exactement comme les adresses iCloud classiques ; seul Sign in with Apple change réellement de domaine, plus tard en 2026, en migrant vers private.icloud.com, tout en gardant privaterelay.appleid.com actif pour les adresses déjà créées. Pour qui valide des listes email ou configure une allowlist Sign in with Apple, la nuance a un impact direct sur la lecture des bounces et sur la logique de filtrage.
Ce qu’Apple a annoncé le 24 août 2026
La page développeur d’Apple mise à jour ce jour-là porte un titre sobre, presque anecdotique : « Update: New domain for Sign in with Apple ». Hide My Email a disparu du titre et se voit réglé en une phrase du corps de texte : après examen des retours de la communauté, les adresses restent sur icloud.com. C’est ainsi qu’Apple confirme le renoncement, sans communiqué séparé ni annonce en grande pompe (Apple Developer News, 24 août 2026). Le texte précise que les futures adresses Sign in with Apple, jusqu’ici émises sur privaterelay.appleid.com, seront désormais générées sur private.icloud.com ; les adresses existantes continuent de fonctionner et de relayer les messages sans interruption. Rien, en revanche, ne change pour Hide My Email : les alias restent au format alias@icloud.com, à l’identique de ce qui existe depuis le lancement de la fonctionnalité.
Le projet initial de juin 2026 : pourquoi il a capoté en 10 semaines
Le 15 juin 2026, Apple annonçait l’inverse : Sign in with Apple et Hide My Email allaient fusionner sous un domaine commun, private.icloud.com. L’idée semblait cohérente sur le papier, unifier l’infrastructure de messagerie privée d’Apple sous une seule bannière technique. Les retours n’ont pas tardé. Utilisateurs et développeurs ont fait remonter un problème concret dans les semaines suivantes, jusqu’à forcer un rétropédalage complet 10 semaines plus tard.
Pourquoi un domaine dédié aurait facilité le blocage des alias
Le raisonnement tient en une phrase technique. Un domaine séparé, réservé aux seuls alias jetables, devient une cible triviale pour n’importe quelle règle de blocage : il suffit d’ajouter private.icloud.com à une liste noire de domaines et tous les alias Hide My Email disparaissent du formulaire d’inscription, sans toucher aux vraies boîtes iCloud. C’est exactement ce que redoutaient les défenseurs de la fonctionnalité. 9to5Mac documente ce revirement dans son compte-rendu du 24 août 2026. En restant sur icloud.com, chaque alias se fond dans le même domaine que les centaines de millions d’adresses iCloud réelles. Bloquer ce domaine reviendrait à bloquer une part significative des utilisateurs iPhone, ce qu’aucun service commercial ne peut se permettre.
Apple recommande désormais aux développeurs qui utilisent Sign in with Apple de s’assurer que leurs systèmes de compte, leur logique de validation d’email et leurs allowlists acceptent private.icloud.com en plus du domaine existant privaterelay.appleid.com, précise 9to5Mac en citant la note technique d’Apple du 24 août 2026.
La bascule ne concerne toutefois pas toutes les intégrations de la même façon. Les applications qui codent en dur l’ancien domaine dans leurs règles de validation Sign in with Apple devront tout de même ajuster leur configuration avant la fin de l’année, le nouveau domaine venant s’ajouter à l’ancien sans le remplacer immédiatement.
Ce qui change réellement à partir de maintenant
Trois faits distincts, souvent confondus dans les premières réactions. Hide My Email reste sur icloud.com, sans aucune modification pour les utilisateurs ni pour les services qui reçoivent ces adresses. Sign in with Apple, lui, migre bien vers private.icloud.com, avec un calendrier fixé à « plus tard en 2026 » sans date précise communiquée à ce stade. Les adresses privaterelay.appleid.com déjà émises, elles, continuent de fonctionner indéfiniment et de relayer le courrier sans coupure de service annoncée. L’article publié par ce blog en juillet présentait la migration comme actée pour les deux domaines ; la situation a évolué depuis : seule la partie Sign in with Apple de notre précédent article sur la migration vers private.icloud.com reste valable aujourd’hui.
Ce que ça change pour vos listes et vos validations d’email
« Mes campagnes finissent en spam et j’ai aucune idée pourquoi, mon outil d’emailing dit que tout est OK. » C’est le type de retour qui circule souvent chez les équipes growth quand une adresse icloud.com se comporte différemment d’une campagne à l’autre. La raison tient en une ligne : un alias Hide My Email et une boîte iCloud personnelle partagent exactement le même domaine, la même infrastructure MX et souvent le même comportement en MAIL FROM. Le domaine ne dit donc rien. Le seul indice se loge dans le nom d’utilisateur : les alias générés suivent un format reconnaissable, deux mots aléatoires suivis d’un chiffre, du type sunny.breeze_49@icloud.com. Ce pattern repère la majorité des alias sans jamais atteindre la totalité. Il piège au passage les vraies adresses construites en prenom.nom_84, un format que beaucoup d’utilisateurs choisissent pour leur boîte personnelle. La sender reputation d’icloud.com, mutualisée entre alias et vraies boîtes, se comporte donc comme un catchall géant à l’échelle de tout un fournisseur.
Avant de conclure qu’il suffit de filtrer les adresses icloud.com après l’envoi pour limiter les alias jetables : ce filtrage post-hoc ne marche pas, puisqu’il bloquerait aussi une part massive d’utilisateurs réels. La seule approche qui fonctionne consiste à vérifier chaque adresse avant l’envoi, en s’appuyant sur des signaux d’engagement et de délivrabilité plutôt que sur le nom de domaine, seul repère devenu inutilisable depuis ce revirement. Sur le volet Sign in with Apple, l’ajustement est plus mécanique : toute logique de validation ou d’allowlist doit désormais accepter à la fois private.icloud.com et privaterelay.appleid.com, sous peine de rejeter des comptes légitimes créés après la bascule. Un test simple consiste à repasser un échantillon de la base sur ces deux domaines avant la prochaine campagne, pour vérifier que rien ne casse côté taux de hard bounce.
FAQ
Faut-il bloquer les adresses icloud.com pour limiter les inscriptions via Hide My Email ? Non. Le blocage par domaine touche indistinctement les alias et les vraies boîtes iCloud, un choix qu’Apple a justement neutralisé en gardant Hide My Email sur icloud.com plutôt que sur un domaine séparé.
Comment reconnaître un alias Hide My Email d’une vraie adresse iCloud ? Le domaine seul ne permet rien. Le nom d’utilisateur, lui, donne un signal : les alias générés combinent deux mots aléatoires et un chiffre. Ce pattern reste probabiliste, une vraie adresse en prenom.nom_annee lui ressemble trait pour trait. Le plus sûr consiste à le croiser avec les signaux comportementaux de l’adresse (engagement, historique de bounce, NDR) plutôt qu’à bloquer sur ce seul critère.
Les anciennes adresses privaterelay.appleid.com vont-elles cesser de fonctionner ? Non. Apple n’a fixé aucune date d’extinction et précise que ces adresses continuent de relayer le courrier sans interruption, en parallèle des nouvelles adresses créées sur private.icloud.com.
Quand la bascule Sign in with Apple vers private.icloud.com sera-t-elle terminée ? Apple n’a communiqué aucune date d’achèvement, ni d’éventuelle extinction future du domaine privaterelay.appleid.com. Le calendrier officiel s’arrête à « plus tard en 2026 ».
