⏱️ Lectura: 11 min
Apple confirmed on August 24, 2026 that hidden email addresses from Sign in with Apple, until now all under privaterelay.appleid.com, will begin to be issued from a new domain: private.icloud.com. The notice, published on Apple’s developer news portal, clarifies that nothing breaks immediately: existing addresses will keep forwarding email without interruption.
📑 En este artículo
- TL;DR
- Introduction
- What happened with Sign in with Apple
- Context and history
- Technical details and performance
- How to test it today
- Impact and analysis
- What’s next
- Frequently Asked Questions
- Does my app stop working if I don’t update anything?
- When does private.icloud.com start being used?
- Does this affect iCloud+’s Hide My Email?
- Do I need to migrate accounts that already have a privaterelay.appleid.com address?
- What happens if my transactional email system rejects the new domain?
- Where is the relay mechanism officially documented?
- References
But there is a pending task. Any app, backend, or email provider that validates, filters, or stores Sign in with Apple addresses by domain needs to add private.icloud.com to its logic before the first new addresses start appearing.
TL;DR
- Apple announced on August 24, 2026 that new Sign in with Apple addresses will be issued on the private.icloud.com domain.
- The change starts “later this year,” according to Apple’s official notice, meaning sometime in the rest of 2026.
- Addresses already issued on privaterelay.appleid.com will keep working and forwarding email without interruption.
- Apple reversed its original plan after receiving community feedback: iCloud+ Hide My Email addresses remain on icloud.com.
- Developers must update account systems, email validation logic, and allowlists to accept both domains.
- Apple did not set an exact cutoff date; it recommends supporting both domains in parallel indefinitely.
- The change affects any app or site that uses “Sign in with Apple” and filters email addresses by domain.
Introduction
For any app that uses the “Continue with Apple” button, the user’s email is never a fixed piece of data: it can be the real one or an alias generated by Apple. That alias is the piece that is now changing domain.
This article explains what Apple announced, why it did so, and what a development team needs to touch so that Sign in with Apple keeps working without friction once the first addresses on the new domain start arriving.
What happened with Sign in with Apple
The announcement is short but direct: “starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.” Apple did not give an exact start date, only “later in 2026.”
The text also clarifies a point that had generated noise in the developer community: after reviewing the feedback received, Apple decided that iCloud+ Hide My Email addresses will continue to live on the icloud.com domain, unchanged. In other words, the move to private.icloud.com is exclusive to Sign in with Apple, not to Apple’s entire email relay ecosystem.
Apple explicitly asks developers to review three things: account systems, email validation logic, and allowlists, so they accept the new domain in addition to the existing one.
Context and history
Sign in with Apple was introduced at WWDC 2019 as an alternative to “sign in with Google” or “sign in with Facebook” that doesn’t require sharing the user’s real email. Instead, Apple generates an alias address in the format [email protected] and forwards messages to the real inbox, without the developer ever seeing the real email unless the user chooses to share it.
That mechanism, documented in Apple’s official guide on Communicating using the Private Email Relay Service, runs in parallel with Hide My Email, the iCloud+ feature (launched in 2021) that lets you create disposable email aliases from any form, not just from Sign in with Apple buttons. Both features share the same idea (hiding the real email behind a forwarding alias) but until now used different domains by design: privaterelay.appleid.com for Sign in with Apple, icloud.com for Hide My Email.
The change announced this week does not unify those two domains: it further separates Sign in with Apple’s namespace, moving it from a subdomain of appleid.com to one of icloud.com. It’s an internal infrastructure adjustment for Apple, not a product change visible to the end user.
Technical details and performance
For a developer, Sign in with Apple delivers two things in the authentication callback: a signed identity token in JWT format and, the first time the user authorizes the app, an email (real or relay) in the email claim. That email is the one that today can end up on privaterelay.appleid.com and that, later in 2026, could also arrive on private.icloud.com.
The practical problem shows up in any system that treats that domain as a fixed value: email validators with a hardcoded regular expression, domain allowlists for fraud scoring, spam rules on in-house mail servers, or CRM integrations that categorize leads by email domain. If your validator only recognizes privaterelay.appleid.com, a new address on private.icloud.com could bounce as “invalid email” or trigger a false fraud alert.
A minimal first step is updating the validation regular expression:
// Before: only recognized one Apple relay domain
const APPLE_RELAY_REGEX = /^[a-z0-9._%+-]+@privaterelay\.appleid\.com$/i;
// Now: accepts both valid Sign in with Apple domains
const APPLE_RELAY_REGEX = /^[a-z0-9._%+-]+@(privaterelay\.appleid\.com|private\.icloud\.com)$/i;
console.log(APPLE_RELAY_REGEX.test('[email protected]')); // true
console.log(APPLE_RELAY_REGEX.test('[email protected]')); // trueThat change covers format validation, but it’s not enough if your backend also uses the address to decide behavior (for example, skipping own-domain verification, or flagging the account as “created via Apple relay”). There it’s worth centralizing the allowlist of domains in a single constant, instead of repeating it in every validator:
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); // skips asking for extra own-domain verification
}
crearOActualizarUsuario(email);
res.redirect('/dashboard');
});The table summarizes what changes and what doesn’t between the two domains:
| Aspect | privaterelay.appleid.com (current) | private.icloud.com (new) |
|---|---|---|
| Status | Still active, no announced retirement date | Starts being issued for new addresses from late 2026 |
| Already issued addresses | Keep forwarding email unchanged | Does not apply retroactively |
| Developer action | Should already be in your allowlist | Needs to be added to validations and allowlists |
| Hide My Email (iCloud+) | Doesn’t use this domain, lives on icloud.com | Doesn’t use it either, stays on icloud.com |
How to test it today
You don’t need to wait for Apple to activate the new domain to get your system ready. You can simulate the scenario today with these steps:
- Update any regular expression, allowlist, or email firewall rule that mentions privaterelay.appleid.com so it also accepts private.icloud.com.
- If you store the email domain in a separate column for reports or segmentation, run an audit query to see how many users are already on Apple relay:
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;That query gives you a snapshot of how many accounts currently depend on the old domain, useful for sizing the risk if some validator still has it hardcoded. As a third step, check your transactional email provider’s logs (SendGrid, Postmark, SES) filtering by recipient domain; if bounced traffic toward private.icloud.com starts appearing, that’s the signal that Apple has already activated the change for your user base.
💡 Tip: centralize the list of Apple relay domains in a single constant or environment variable, don’t repeat it in every validator; that way the next domain change (if it happens again) gets fixed in one place.
Impact and analysis
The change itself is minor compared to other Apple announcements for developers, but it touches a sensitive point: any fraud scoring or lead quality system that treats the email domain as a fixed signal will need a silent update. It’s a known pattern in federated authentication: when a provider migrates part of its OAuth infrastructure, or when a transactional email service rotates its sending domains, the friction doesn’t show up in the product but in the business rules that assumed a domain would be stable forever.
The most interesting part of the announcement is the “after reviewing community feedback”: it suggests Apple originally evaluated a broader scope for the domain change (possibly including Hide My Email) and backed off after developer feedback. It’s a sign that Apple keeps listening to bug reports and technical feedback on the Apple Developer Forums before moving infrastructure that millions of apps take for granted.
For security teams, the change also requires reviewing your own DMARC/SPF rules if you ever treated privaterelay.appleid.com as a trusted domain in a sender allowlist. Adding private.icloud.com to that same list avoids false spam positives during the first forwards.
⚠️ Heads up: if your fraud or lead deduplication system uses the email domain as part of a user fingerprint, review that logic: two Apple relay aliases with different domains can belong to the same real user and shouldn’t be treated as separate accounts.
flowchart TD
A["User"] -->|"Continue with Apple"| B["Apple ID"]
B -->|"creates relay address"| C["Hidden alias: privaterelay.appleid.com or private.icloud.com"]
C -->|"forwards real email"| D["User's inbox"]
B -->|"JWT identity token"| E["Developer's backend"]
E -->|"validates email domain"| F["Accounts database"]What’s next
Apple did not publish a cutoff date for privaterelay.appleid.com, and everything indicates there won’t be one: the announcement explicitly states that existing addresses “will keep working and forwarding email to users without interruption.” The practical recommendation is to support both domains indefinitely, not treat this as a migration with a deadline.
It’s worth marking a review for late 2026 on the calendar, when according to the notice itself the new domain should be active, to confirm with real production data (not just in theory) that addresses on private.icloud.com are processed the same as the old ones throughout the entire pipeline: registration, notification sending, account recovery, and internal reports.
📖 Summary on Telegram: See summary
Try it yourself: update your backend’s regex or allowlist today to accept private.icloud.com and confirm the change by running the domain audit query against your current user base.
Frequently Asked Questions
Does my app stop working if I don’t update anything?
Not immediately. Existing addresses on privaterelay.appleid.com keep forwarding email unchanged. The risk appears when a new user gets an address on private.icloud.com and your validator rejects it for not recognizing the domain.
When does private.icloud.com start being used?
Apple only said “later this year” (2026), with no exact date. There’s no announcement of a specific activation day.
Does this affect iCloud+’s Hide My Email?
No. Apple clarified that, after reviewing community feedback, Hide My Email addresses remain on the icloud.com domain, unchanged.
Do I need to migrate accounts that already have a privaterelay.appleid.com address?
No. The change applies only to new addresses issued after activation. Existing addresses are neither replaced nor do they expire.
What happens if my transactional email system rejects the new domain?
You’ll lose delivery of emails (confirmations, password recovery, etc.) to users with that address. That’s why it’s worth updating allowlists for email providers (SendGrid, SES, Postmark) in addition to your own validators.
Where is the relay mechanism officially documented?
In Apple’s guide Communicating using the Private Email Relay Service, which explains how to detect and respond to relay addresses from your backend.
References
- Apple Developer News: Update: New domain for Sign in with Apple: the official announcement of the domain change, published on August 24, 2026.
- Communicating using the Private Email Relay Service: Apple’s official documentation on how Sign in with Apple’s email forwarding works.
- Sign in with Apple: the official product page for developers.
- Sign in with Apple on Wikipedia: historical context on the WWDC 2019 launch.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
0 Comments