Apple confirmó el 24 de agosto de 2026 que las direcciones de correo oculto de Sign in with Apple, hasta ahora todas bajo privaterelay.appleid.com, empezarán a emitirse desde un dominio nuevo: private.icloud.com. El aviso, publicado en el portal de noticias para desarrolladores de Apple, aclara que nada se rompe de inmediato: las direcciones ya existentes van a seguir reenviando correo sin interrupciones.
Pero sí hay una tarea pendiente. Cualquier app, backend o proveedor de email que valide, filtre o guarde direcciones de Sign in with Apple por su dominio necesita sumar private.icloud.com a su lógica antes de que empiecen a aparecer las primeras direcciones nuevas.
TL;DR
- Apple anunció el 24 de agosto de 2026 que las nuevas direcciones de Sign in with Apple se emitirán en el dominio private.icloud.com.
- El cambio arranca "más adelante este año", según el aviso oficial de Apple, es decir, en lo que resta de 2026.
- Las direcciones ya emitidas en privaterelay.appleid.com seguirán funcionando y reenviando correo sin interrupciones.
- Apple revirtió su plan original tras recibir comentarios de la comunidad: las direcciones de iCloud+ Hide My Email permanecen en icloud.com.
- Los desarrolladores deben actualizar sistemas de cuentas, lógica de validación de email y allowlists para aceptar ambos dominios.
- Apple no fijó una fecha exacta de corte; recomienda soportar los dos dominios en paralelo de forma indefinida.
- El cambio afecta a cualquier app o sitio que use "Sign in with Apple" y filtre direcciones de correo por dominio.
Introducción
Para cualquier app que use el botón "Continuar con Apple", el correo del usuario nunca es un dato fijo: puede ser el real o un alias generado por Apple. Ese alias es la pieza que ahora cambia de dominio.
Este artículo explica qué anunció Apple, por qué lo hizo, y qué tiene que tocar un equipo de desarrollo para que Sign in with Apple siga funcionando sin fricción cuando empiecen a llegar las primeras direcciones en el dominio nuevo.
Qué pasó con Sign in with Apple
El anuncio es corto pero directo: "a partir de más adelante este año, las nuevas direcciones de Sign in with Apple, antes emitidas en privaterelay.appleid.com, se emitirán en private.icloud.com". Apple no dio una fecha exacta de arranque, solo "más adelante en 2026".
El texto también aclara un punto que había generado ruido en la comunidad de desarrolladores: después de revisar el feedback recibido, Apple decidió que las direcciones de iCloud+ Hide My Email van a seguir viviendo en el dominio icloud.com, sin cambios. Es decir, el movimiento a private.icloud.com es exclusivo de Sign in with Apple, no de todo el ecosistema de relay de correo de Apple.
Apple le pide explícitamente a los desarrolladores revisar tres cosas: los sistemas de cuentas, la lógica de validación de email y las listas de dominios permitidos (allowlists), para que acepten el dominio nuevo además del existente.
Contexto e historia
Sign in with Apple se presentó en la WWDC de 2019 como una alternativa a "iniciar sesión con Google" o "iniciar sesión con Facebook" que no obliga a compartir el correo real del usuario. En vez de eso, Apple genera una dirección alias con formato algo-aleatorio@privaterelay.appleid.com y reenvía los mensajes a la bandeja real, sin que el desarrollador vea nunca el correo verdadero salvo que el usuario elija compartirlo.
Ese mecanismo, documentado en la guía oficial de Apple sobre Communicating using the Private Email Relay Service, corre en paralelo a Hide My Email, la función de iCloud+ (lanzada en 2021) que deja crear alias de correo desactivables desde cualquier formulario, no solo desde botones de Sign in with Apple. Ambas funciones comparten idea (esconder el correo real detrás de un alias que reenvía) pero hasta ahora usaban dominios distintos por diseño: privaterelay.appleid.com para Sign in with Apple, icloud.com para Hide My Email.
El cambio anunciado esta semana no unifica esos dos dominios: separa aún más el espacio de nombres de Sign in with Apple, moviéndolo de un subdominio de appleid.com a uno de icloud.com. Es un ajuste de infraestructura interna de Apple, no un cambio de producto visible para el usuario final.
Detalles técnicos y rendimiento
Para un desarrollador, Sign in with Apple entrega dos cosas en el callback de autenticación: un identity token firmado en formato JWT y, la primera vez que el usuario autoriza la app, un correo (real o de relay) en el claim email. Ese correo es el que hoy puede terminar en privaterelay.appleid.com y que, más adelante en 2026, también podría llegar en private.icloud.com.
El problema práctico aparece en cualquier sistema que trate ese dominio como un valor fijo: validadores de email con una expresión regular hardcodeada, listas blancas de dominios para scoring de fraude, reglas de spam en servidores de correo propios, o integraciones de CRM que categorizan leads por dominio de correo. Si tu validador solo reconoce privaterelay.appleid.com, una dirección nueva en private.icloud.com puede rebotar como "email inválido" o disparar una alerta de fraude falsa.
Un primer paso mínimo es actualizar la expresión regular de validación:
// Antes: solo reconocía un dominio de relay de Apple
const APPLE_RELAY_REGEX = /^[a-z0-9._%+-]+@privaterelay\.appleid\.com$/i;
// Ahora: acepta los dos dominios válidos de Sign in with Apple
const APPLE_RELAY_REGEX = /^[a-z0-9._%+-]+@(privaterelay\.appleid\.com|private\.icloud\.com)$/i;
console.log(APPLE_RELAY_REGEX.test('a1b2c3d4e5@private.icloud.com')); // true
console.log(APPLE_RELAY_REGEX.test('a1b2c3d4e5@privaterelay.appleid.com')); // true
Ese cambio cubre la validación de formato, pero no alcanza si tu backend además usa la dirección para decidir comportamiento (por ejemplo, saltar verificación de dominio propio, o marcar la cuenta como "creada vía relay de Apple"). Ahí conviene centralizar la lista de dominios permitidos en una sola constante, no repetirla en cada validador:
const ALLOWED_APPLE_RELAY_DOMAINS = new Set([
'privaterelay.appleid.com',
'private.icloud.com',
]);
function esCorreoDeRelayApple(email) {
const dominio = email.split('@')[1]?.toLowerCase();
return ALLOWED_APPLE_RELAY_DOMAINS.has(dominio);
}
app.post('/auth/apple/callback', (req, res) => {
const { email } = decodeIdentityToken(req.body.id_token);
if (esCorreoDeRelayApple(email)) {
marcarCuentaComoRelay(email); // evita pedir verificación extra de dominio propio
}
crearOActualizarUsuario(email);
res.redirect('/dashboard');
});
La tabla resume qué cambia y qué no entre los dos dominios:
Aspectoprivaterelay.appleid.com (actual)private.icloud.com (nuevo)
EstadoSigue activo, sin fecha de baja anunciadaEmpieza a emitirse en direcciones nuevas desde fines de 2026
Direcciones ya emitidasSiguen reenviando correo sin cambiosNo aplica retroactivamente
Acción del desarrolladorDebería estar ya en tu allowlistHay que agregarlo a validaciones y allowlists
Hide My Email (iCloud+)No usa este dominio, vive en icloud.comTampoco lo usa, se mantiene en icloud.com
El botón "Continuar con Apple" es el mismo; cambia el dominio detrás del alias.
Cómo probarlo hoy
No hace falta esperar a que Apple active el dominio nuevo para dejar tu sistema listo. Podés simular el escenario hoy con estos pasos:
- Actualizá cualquier expresión regular, lista blanca o regla de firewall de correo que mencione privaterelay.appleid.com para que también acepte private.icloud.com.
- Si guardás el dominio del correo en una columna separada para reportes o segmentación, corré una consulta de auditoría para ver cuántos usuarios ya son de relay de Apple:
SELECT split_part(email, '@', 2) AS dominio, count(*) AS usuarios
FROM cuentas
WHERE email LIKE '%@privaterelay.appleid.com'
OR email LIKE '%@private.icloud.com'
GROUP BY dominio;
Esa consulta te da una foto de cuántas cuentas dependen hoy del dominio viejo, útil para dimensionar el riesgo si algún validador todavía lo tiene hardcodeado. Como tercer paso, revisá los logs de tu proveedor de email transaccional (SendGrid, Postmark, SES) filtrando por dominio destinatario; si empieza a aparecer tráfico rebotado hacia private.icloud.com, es la señal de que Apple ya activó el cambio para tu base de usuarios.
💡 Tip: centralizá la lista de dominios de relay de Apple en una sola constante o variable de entorno, no la repitas en cada validador; así el próximo cambio de dominio (si vuelve a pasar) se corrige en un solo lugar.
Impacto y análisis
El cambio en sí es menor comparado con otros anuncios de Apple para desarrolladores, pero toca un punto sensible: cualquier sistema de scoring de fraude o de calidad de leads que trate el dominio de correo como señal fija va a necesitar una actualización silenciosa. Es un patrón conocido en autenticación federada: cuando un proveedor migra parte de su infraestructura de OAuth, o cuando un servicio de email transaccional rota sus dominios de envío, la fricción no aparece en el producto sino en las reglas de negocio que asumieron que un dominio era estable para siempre.
Lo más interesante del anuncio es el "después de revisar comentarios de la comunidad": sugiere que Apple originalmente evaluó un alcance más amplio del cambio de dominio (posiblemente incluyendo Hide My Email) y dio marcha atrás ante el feedback de desarrolladores. Es una señal de que Apple sigue escuchando bug reports y feedback técnico en el Apple Developer Forums antes de mover infraestructura que millones de apps dan por sentada.
El reenvío de correo no cambia; solo el dominio que aparece en el alias.
Para equipos de seguridad, el cambio también obliga a revisar reglas de DMARC/SPF propias si alguna vez trataron privaterelay.appleid.com como dominio confiable en una lista blanca de remitentes. Agregar private.icloud.com a esa misma lista evita falsos positivos de spam en los primeros reenvíos.
⚠️ Ojo: si tu sistema de fraude o de deduplicación de leads usa el dominio de correo como parte de una huella (fingerprint) de usuario, revisá esa lógica: dos alias de relay de Apple con dominios distintos pueden pertenecer al mismo usuario real y no deberían tratarse como cuentas separadas.
flowchart TD
A["Usuario"] -->|"Continuar con Apple"| B["Apple ID"]
B -->|"crea dirección de relay"| C["Alias oculto: privaterelay.appleid.com o private.icloud.com"]
C -->|"reenvía el correo real"| D["Bandeja del usuario"]
B -->|"identity token JWT"| E["Backend del desarrollador"]
E -->|"valida dominio del email"| F["Base de datos de cuentas"]
Qué sigue
Apple no publicó una fecha de corte para privaterelay.appleid.com, y todo indica que no la va a haber: el anuncio dice explícitamente que las direcciones existentes "van a seguir funcionando y reenviando correo a los usuarios sin interrupción". La recomendación práctica es soportar ambos dominios de forma indefinida, no tratar esto como una migración con deadline.
Vale la pena marcar en el calendario una revisión a fin de 2026, cuando según el propio aviso debería estar activo el dominio nuevo, para confirmar con datos reales de producción (no solo en teoría) que las direcciones en private.icloud.com se procesan igual que las viejas en todo el pipeline: registro, envío de notificaciones, recuperación de cuenta y reportes internos.
📖 Resumen en Telegram: Ver resumen
Probalo vos: actualizá hoy la regex o el allowlist de tu backend para aceptar private.icloud.com y confirmá el cambio corriendo la consulta de auditoría de dominios contra tu base de usuarios actual.
Preguntas frecuentes
¿Mi app deja de funcionar si no actualizo nada?
No de forma inmediata. Las direcciones existentes en privaterelay.appleid.com siguen reenviando correo sin cambios. El riesgo aparece cuando un usuario nuevo obtenga una dirección en private.icloud.com y tu validador la rechace por no reconocer el dominio.
¿Cuándo empieza a usarse private.icloud.com?
Apple solo dijo "más adelante este año" (2026), sin fecha exacta. No hay anuncio de un día puntual de activación.
¿Esto afecta a Hide My Email de iCloud+?
No. Apple aclaró que, tras revisar el feedback de la comunidad, las direcciones de Hide My Email se mantienen en el dominio icloud.com, sin cambios.
¿Tengo que migrar las cuentas que ya tienen una dirección de privaterelay.appleid.com?
No. El cambio aplica solo a direcciones nuevas emitidas a partir de la activación. Las direcciones existentes no se reemplazan ni caducan.
¿Qué pasa si mi sistema de email transaccional rechaza el dominio nuevo?
Vas a perder la entrega de correos (confirmaciones, recuperación de contraseña, etc.) a usuarios con esa dirección. Por eso conviene actualizar allowlists de proveedores de email (SendGrid, SES, Postmark) además de tus propios validadores.
¿Dónde está documentado oficialmente el mecanismo de relay?
En la guía de Apple Communicating using the Private Email Relay Service, que explica cómo detectar y responder a direcciones de relay desde tu backend.
Referencias
- Apple Developer News: Update: New domain for Sign in with Apple: el anuncio oficial del cambio de dominio, publicado el 24 de agosto de 2026.
- Communicating using the Private Email Relay Service: documentación oficial de Apple sobre cómo funciona el reenvío de correo de Sign in with Apple.
- Sign in with Apple: página oficial del producto para desarrolladores.
- Sign in with Apple en Wikipedia: contexto histórico sobre el lanzamiento en la WWDC 2019.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
