Dos Cambios de Dominio, Una Marcha Atrás

Apple anunció a mediados de junio de 2026 que trasladaría dos funciones de reenvío de correo distintas a un único dominio nuevo, private.icloud.com: Hide My Email, la función de iCloud+ que genera direcciones de reenvío desechables, y Sign in with Apple, el sistema de inicio de sesión que oculta el correo real del usuario tras su propia dirección de relay. El 24 de agosto de 2026, Apple revirtió la mitad de ese plan. En una nota para desarrolladores, Apple dijo que, tras una mayor reflexión y revisar los comentarios de la comunidad, no aplicaría el cambio a Hide My Email, y que las direcciones de Hide My Email de iCloud+ seguirán en icloud.com.

La cobertura de la marcha atrás la ha tratado en gran medida como si Apple hubiera cancelado toda la migración de dominio. Esa lectura es incompleta. Sign in with Apple no formó parte de la reversión, y su traslado a private.icloud.com sigue en marcha más adelante en 2026.

Por Qué el Bloqueo por Dominio Falla de Cualquier Forma

La marcha atrás existe porque la identificación a nivel de dominio es una herramienta poco precisa. Las direcciones de Hide My Email comparten actualmente el dominio icloud.com con cualquier cuenta normal de iCloud Mail, así que un sitio web no puede bloquear una sin arriesgarse a bloquear la otra. Mover Hide My Email a su propio dominio habría resuelto esa ambigüedad para la ingeniería de Apple, pero habría dado a cualquier sitio web una forma fácil y fiable de detectar y rechazar direcciones de Hide My Email a simple vista - identificables por el dominio, no por ningún comportamiento, anulando el propósito de la función para cualquiera que se registre en un sitio que decida discriminarla.

FunciónDominio tras agosto de 2026Cambio respecto al plan de junio
Hide My Email (direcciones nuevas)icloud.com (sin cambios)Revertido - se mantiene
Sign in with Apple (direcciones nuevas)private.icloud.comSigue según lo planeado
Sign in with Apple (direcciones existentes)privaterelay.appleid.comSigue reenviando sin interrupción

Sign in with Apple no enfrenta el mismo riesgo de colisión, porque las direcciones de relay de esa función ya son visiblemente distintas de una bandeja personal de iCloud en la mayoría de los flujos de integración, lo que probablemente explica por qué Apple dejó continuar esa mitad del plan.

La Parte que la Mayoría de la Cobertura Pasó por Alto

Las direcciones de Sign in with Apple creadas a partir de ahora llevarán el nuevo dominio private.icloud.com, mientras que cualquier dirección creada antes del cambio seguirá funcionando sin interrupción en privaterelay.appleid.com, según la propia declaración de Apple. Se trata de una migración activa, no archivada, y tratar todo el anuncio como revertido es exactamente el tipo de error que rompe la entrega de correo a un usuario meses después.

Cualquier sistema, en cualquier lugar, construido para reconocer el tráfico de relay de privacidad de Apple comparando una cadena de dominio con una lista fija empezará a ver un dominio que no reconoce en cuanto un usuario se registre con una dirección de Sign in with Apple recién creada. Nada de la reversión de Hide My Email cambia eso.

Qué Deben Hacer Ya los Operadores de Sitios

Añada private.icloud.com a cualquier lista blanca, filtro antispam, regla antifraude o sistema de validación de correo que actualmente compruebe privaterelay.appleid.com, y hágalo antes de que el nuevo dominio empiece a aparecer en registros reales, no después de que lleguen los tickets de soporte. Deje las reglas de icloud.com exactamente como están; las direcciones de Hide My Email no se han movido ni se moverán bajo este anuncio.

No extienda la misma actualización a Hide My Email. Como esa migración se revirtió, una regla escrita para esperar direcciones de Hide My Email en private.icloud.com simplemente nunca coincidirá con nada, lo cual es inofensivo, pero una regla que solo reconozca el antiguo dominio de Sign in with Apple empezará a fallar silenciosamente en cuentas nuevas.

La Lección Más Amplia para el Diseño Antiabuso

El susto es un caso de estudio nítido de por qué el bloqueo por dominio de direcciones de relay de privacidad no funciona como control. Hacer que el dominio de relay sea distinto e identificable da a cualquier operador una forma trivial de rechazar directamente a usuarios preocupados por su privacidad, precisamente el resultado contra el que la propia comunidad de Apple protestó con fuerza suficiente para revertir un plan público. Mantener el dominio de relay compartido con cuentas normales impide a cualquier operador construir una regla fiable contra él, precisamente por lo que Sign in with Apple, diseñado como un espacio de nombres separado desde el inicio, nunca tuvo que enfrentar esta disyuntiva.

Cualquier equipo que esté construyendo su propia función de direcciones desechables o de relay de privacidad tiene ahora un ejemplo real de esa disyuntiva desarrollándose a la escala de Apple, decidido en público, en menos de tres meses.