10 semanas. Es el tiempo que necesitó Apple para anunciar, a mediados de junio de 2026, un cambio de dominio para Hide My Email, y luego cancelarlo el 24 de agosto de 2026, tras los comentarios de su comunidad de desarrolladores. En concreto, los alias Hide My Email de iCloud+ siguen alojados en icloud.com, exactamente igual que las direcciones iCloud clásicas; solo Sign in with Apple cambia realmente de dominio, más adelante en 2026, migrando a private.icloud.com, mientras mantiene privaterelay.appleid.com activo para las direcciones ya creadas. Para quien valida listas de email o configura una allowlist de Sign in with Apple, este matiz tiene un impacto directo en la lectura de los bounces y en la lógica de filtrado.
Lo que Apple anunció el 24 de agosto de 2026
La página de desarrolladores de Apple actualizada ese día tiene un título sobrio, casi anecdótico: «Update: New domain for Sign in with Apple». Hide My Email desapareció del título y queda resuelto en una frase del cuerpo del texto: tras revisar los comentarios de la comunidad, las direcciones permanecen en icloud.com. Así confirma Apple el abandono del proyecto, sin comunicado independiente ni anuncio por todo lo alto (Apple Developer News, 24 de agosto de 2026). El texto precisa que las futuras direcciones de Sign in with Apple, hasta ahora emitidas en privaterelay.appleid.com, se generarán a partir de ahora en private.icloud.com; las direcciones existentes siguen funcionando y transmitiendo los mensajes sin interrupción. En cambio, nada cambia para Hide My Email: los alias mantienen el formato alias@icloud.com, igual que desde el lanzamiento de la función.
El proyecto inicial de junio de 2026: por qué fracasó en 10 semanas
El 15 de junio de 2026, Apple anunciaba lo contrario: Sign in with Apple y Hide My Email iban a fusionarse bajo un dominio común, private.icloud.com. La idea parecía coherente sobre el papel, unificar la infraestructura de mensajería privada de Apple bajo una sola bandera técnica. Los comentarios no tardaron en llegar. Usuarios y desarrolladores plantearon un problema concreto en las semanas siguientes, hasta forzar una marcha atrás completa 10 semanas después.
Por qué un dominio dedicado habría facilitado el bloqueo de los alias
El razonamiento se resume en una frase técnica. Un dominio separado, reservado únicamente a los alias desechables, se convierte en un objetivo trivial para cualquier regla de bloqueo: basta con añadir private.icloud.com a una lista negra de dominios para que todos los alias Hide My Email desaparezcan del formulario de registro, sin tocar las bandejas iCloud reales. Esto es exactamente lo que temían los defensores de la función. 9to5Mac documenta este giro en su crónica del 24 de agosto de 2026. Al permanecer en icloud.com, cada alias se confunde con el mismo dominio que cientos de millones de direcciones iCloud reales. Bloquear este dominio equivaldría a bloquear una parte significativa de los usuarios de iPhone, algo que ningún servicio comercial puede permitirse.
Apple recomienda ahora a los desarrolladores que utilizan Sign in with Apple que se aseguren de que sus sistemas de cuentas, su lógica de validación de email y sus allowlists acepten private.icloud.com además del dominio existente privaterelay.appleid.com, precisa 9to5Mac citando la nota técnica de Apple del 24 de agosto de 2026.
El cambio, sin embargo, no afecta a todas las integraciones por igual. Las aplicaciones que codifican el antiguo dominio directamente en sus reglas de validación de Sign in with Apple deberán ajustar igualmente su configuración antes de que termine el año, ya que el nuevo dominio se añade al anterior sin sustituirlo de inmediato.
Lo que cambia realmente a partir de ahora
Tres hechos distintos, a menudo confundidos en las primeras reacciones. Hide My Email permanece en icloud.com, sin ninguna modificación para los usuarios ni para los servicios que reciben estas direcciones. Sign in with Apple, en cambio, sí migra a private.icloud.com, con un calendario fijado para «más adelante en 2026» sin fecha precisa comunicada por el momento. Las direcciones privaterelay.appleid.com ya emitidas siguen funcionando indefinidamente y transmitiendo el correo sin corte de servicio anunciado. El artículo publicado en este blog en julio presentaba la migración como decidida para ambos dominios; la situación ha evolucionado desde entonces: solo la parte de Sign in with Apple de nuestro artículo anterior sobre la migración a private.icloud.com sigue siendo válida hoy.
Lo que esto cambia para tus listas y tus validaciones de email
«Mis campañas acaban en spam y no tengo ni idea de por qué, mi herramienta de email marketing dice que todo está OK.» Este es el tipo de comentario que suele circular entre los equipos de growth cuando una dirección icloud.com se comporta de forma distinta de una campaña a otra. La razón cabe en una línea: un alias Hide My Email y una bandeja iCloud personal comparten exactamente el mismo dominio, la misma infraestructura MX y a menudo el mismo comportamiento en MAIL FROM. El dominio, por tanto, no dice nada. La única pista se esconde en el nombre de usuario: los alias generados siguen un formato reconocible, dos palabras aleatorias seguidas de un número, del tipo sunny.breeze_49@icloud.com. Este patrón detecta la mayoría de los alias, pero nunca llega a la totalidad. De paso, atrapa direcciones reales construidas como nombre.apellido_84, un formato que muchos usuarios eligen para su bandeja personal. La sender reputation de icloud.com, compartida entre alias y bandejas reales, se comporta así como un catchall gigante a escala de todo un proveedor.
Antes de concluir que basta con filtrar las direcciones icloud.com después del envío para limitar los alias desechables: este filtrado posterior no funciona, ya que también bloquearía a una parte masiva de usuarios reales. El único enfoque que funciona consiste en verificar cada dirección antes del envío, apoyándose en señales de engagement y deliverability en lugar del nombre de dominio, la única referencia que este giro ha vuelto inutilizable. En el apartado de Sign in with Apple, el ajuste es más mecánico: toda lógica de validación o de allowlist debe aceptar ahora tanto private.icloud.com como privaterelay.appleid.com, o corre el riesgo de rechazar cuentas legítimas creadas tras el cambio. Una prueba sencilla consiste en volver a pasar una muestra de la base por estos dos dominios antes de la próxima campaña, para comprobar que nada falla en la tasa de hard bounce.
FAQ
¿Hay que bloquear las direcciones icloud.com para limitar los registros a través de Hide My Email? No. El bloqueo por dominio afecta indistintamente a los alias y a las bandejas iCloud reales, algo que Apple neutralizó precisamente al mantener Hide My Email en icloud.com en lugar de en un dominio separado.
¿Cómo distinguir un alias Hide My Email de una dirección iCloud real? El dominio por sí solo no permite hacerlo. El nombre de usuario, en cambio, da una señal: los alias generados combinan dos palabras aleatorias y un número. Este patrón sigue siendo probabilístico, una dirección real del tipo nombre.apellido_año se le parece en todo. Lo más seguro consiste en cruzarlo con las señales de comportamiento de la dirección (engagement, historial de bounce, NDR) en lugar de bloquear solo por este criterio.
¿Dejarán de funcionar las antiguas direcciones privaterelay.appleid.com? No. Apple no ha fijado ninguna fecha de extinción y precisa que estas direcciones siguen transmitiendo el correo sin interrupción, en paralelo a las nuevas direcciones creadas en private.icloud.com.
¿Cuándo terminará el cambio de Sign in with Apple a private.icloud.com? Apple no ha comunicado ninguna fecha de finalización, ni una posible extinción futura del dominio privaterelay.appleid.com. El calendario oficial se limita a «más adelante en 2026».
