Apple renonce au changement de domaine pour « Masquer mon adresse e-mail »

Apple a finalement séparé en deux son projet de changement de domaine. Après avoir annoncé en juin que les fonctions iCloud+ « Masquer mon adresse e-mail » et « Se connecter avec Apple » utiliseraient toutes deux @private.icloud.com, l’entreprise a indiqué le 24 août que les alias « Masquer mon adresse e-mail » resteraient en @icloud.com. En revanche, les nouvelles adresses créées avec « Se connecter avec Apple » passeront bien de @privaterelay.appleid.com à @private.icloud.com plus tard en 2026. Les adresses déjà attribuées continueront de fonctionner et de transférer les messages sans interruption. 10

Ce qu’Apple a changé

Le projet initial consistait à regrouper les nouvelles adresses générées par les deux fonctions sous le domaine commun @private.icloud.com. Les anciens alias « Masquer mon adresse e-mail » en @icloud.com et les anciennes adresses « Se connecter avec Apple » en @privaterelay.appleid.com devaient continuer à transférer les messages. 15

La décision révisée est plus limitée :

• iCloud+ « Masquer mon adresse e-mail » : les nouveaux alias resteront en @icloud.com.
• « Se connecter avec Apple » : les nouvelles adresses relais utiliseront @private.icloud.com plus tard en 2026.
• Adresses « Se connecter avec Apple » existantes : celles qui se terminent par @privaterelay.appleid.com resteront valides et continueront de transférer les e-mails.

Apple explique ce revirement par une « réflexion plus approfondie » et par les retours de la communauté. L’entreprise n’a pas affirmé qu’une faille de sécurité précise était à l’origine de cette décision. 10

Pourquoi le domaine @private.icloud.com a suscité des critiques

Le problème n’était pas qu’un changement de domaine aurait automatiquement révélé la boîte de réception associée à un alias. La crainte portait surtout sur la visibilité du domaine lui-même : @private.icloud.com aurait clairement signalé qu’il s’agissait d’une adresse relais de confidentialité Apple.

Un site ou une application aurait pu détecter ce suffixe avec une simple vérification de domaine, puis refuser l’inscription, demander une autre adresse ou l’utiliser comme indicateur dans ses systèmes de détection de fraude et d’évaluation des risques. La fonction aurait ainsi été plus facile à bloquer à la création d’un compte. 44

À l’inverse, @icloud.com sert également aux adresses iCloud classiques. Un alias « Masquer mon adresse e-mail » utilisant ce domaine est donc moins immédiatement identifiable pour un service qui cherche à distinguer les adresses masquées des boîtes aux lettres ordinaires.

C’est le cœur de la contestation : les utilisateurs redoutaient que le nouveau domaine réduise l’efficacité pratique de la fonction et sa capacité à préserver une forme de dénégation plausible, même si l’infrastructure de transfert d’Apple restait inchangée. 35

Ce que les développeurs doivent préparer

Les équipes qui utilisent « Se connecter avec Apple » doivent traiter cette évolution comme une transition entre deux domaines relais, et non comme un remplacement brutal de l’ancien domaine.

Accepter les deux domaines relais

Les systèmes de comptes, règles de validation des e-mails, expressions régulières, listes d’autorisation et traitements reposant sur le domaine doivent accepter les nouvelles adresses en @private.icloud.com ainsi que les adresses existantes en @privaterelay.appleid.com.

Les précédentes consignes d’Apple mentionnaient également @icloud.com pour la gestion des domaines relais. Les systèmes ne devraient donc pas partir du principe qu’un seul suffixe Apple est valide. 810

Surtout, il ne faut ni migrer ni désactiver les comptes existants au seul motif que leur adresse utilise l’ancien domaine. Apple indique que les adresses en @privaterelay.appleid.com continueront de fonctionner et de transférer les messages sans interruption. 10

Vérifier la configuration des e-mails sortants

Lorsqu’une application ou un site envoie des messages via le relais privé d’Apple, les développeurs doivent enregistrer dans leur compte Apple Developer les domaines et sous-domaines utilisés pour l’envoi. Apple demande également que ces sources d’e-mails passent une vérification SPF. 6

Les équipes devraient donc contrôler :

• les domaines et sous-domaines d’envoi enregistrés ;
• les enregistrements DNS SPF ;
• les parcours d’inscription, de validation et de récupération de compte ;
• les listes d’autorisation et de blocage ;
• les champs ou schémas de base de données qui supposent un domaine fixe ;
• les outils du service client et de recherche de comptes qui identifient les utilisateurs à partir du suffixe de leur adresse.

La documentation d’Apple précise que le relais transfère les messages vers l’une des adresses e-mail vérifiées du compte Apple de l’utilisateur. 3

Le contexte des récentes alertes de confidentialité

La controverse sur le domaine est survenue alors que plusieurs problèmes distincts touchant les systèmes de confidentialité d’Apple étaient rapportés. Ces incidents ne prouvent pas que @private.icloud.com aurait, à lui seul, révélé une adresse e-mail ou une adresse IP. Ils permettent toutefois de comprendre pourquoi les utilisateurs ont examiné avec autant d’attention une modification susceptible de rendre les alias plus faciles à classifier.

La faille liée aux messages rejetés comme spam

Une vulnérabilité signalée dans « Masquer mon adresse e-mail » pouvait révéler l’adresse réelle derrière un alias lorsqu’un message envoyé à celui-ci était rejeté comme spam. L’adresse sous-jacente pouvait alors apparaître dans les journaux de transfert de messagerie conservés du côté de l’expéditeur, ce qui affaiblissait la promesse centrale de confidentialité de la fonction.

Apple a indiqué avoir déployé un correctif le 3 juillet 2026, et des tests ultérieurs ont rapporté que le problème ne pouvait plus être reproduit. 474954

Un correctif ne supprime pas nécessairement les données déjà exposées : des services de messagerie tiers peuvent conserver d’anciens journaux de distribution. Les adresses révélées avant la correction pourraient donc encore figurer dans des systèmes échappant au contrôle d’Apple. 4860

Les fuites d’adresse IP rapportées dans Private Relay

Des chercheurs ont également signalé que certains flux liés à WebKit pouvaient contourner iCloud Private Relay et révéler l’adresse IP réelle d’un utilisateur. Les scénarios rapportés concernaient notamment les requêtes WebAuthn liées aux clés d’accès, WebTransport et la prélecture DNS. 192023

Un rapport ultérieur a fait état d’une correction apparente dans iOS 26.6.1. Les éléments disponibles décrivent toutefois un correctif rapporté, plutôt qu’une explication détaillée par Apple de l’architecture concernée ou de son impact. 18

Ces problèmes reposent sur des mécanismes différents de la visibilité du domaine e-mail. La faille de « Masquer mon adresse e-mail » concernait l’exposition d’une adresse via un message rejeté, tandis que les alertes sur Private Relay concernaient du trafic réseau susceptible de sortir du chemin de relais. Aucune de ces informations n’établit que le domaine @private.icloud.com aurait directement révélé l’identité d’un utilisateur.

Ce que signifie le revirement d’Apple

L’explication la mieux étayée reste l’opposition des utilisateurs au risque de blocage : ils estimaient qu’un domaine exclusivement associé aux alias de confidentialité donnerait aux sites un moyen simple de les identifier et de les refuser. L’annonce d’Apple confirme que le changement concernant « Masquer mon adresse e-mail » a été abandonné après examen des retours de la communauté. 10

Les alertes de sécurité survenues au même moment constituent surtout un contexte de confiance fragilisée, et non une cause officiellement établie. Elles ont pu rendre les utilisateurs plus méfiants envers une évolution qui aurait facilité la classification des alias, mais Apple n’a pas établi de lien entre ces incidents et sa décision sur le domaine.

Le compromis est donc clair : « Masquer mon adresse e-mail » conserve le suffixe moins visible @icloud.com, tandis que les développeurs utilisant « Se connecter avec Apple » doivent préparer la prise en charge de @private.icloud.com en parallèle de l’ancien domaine relais.