The short answer: if an app, website, CRM, fraud filter, email provider, or test suite assumes Apple private relay addresses end only in @privaterelay.appleid.com or @icloud.com, it needs an update.
Apple announced on June 15 that new Sign in with Apple and iCloud+ Hide My Email addresses will move to a shared domain, private.icloud.com, later this summer. Existing relay addresses on the legacy domains will keep working and forwarding mail.
Status check — August 13, 2026: Apple has announced the migration but has not published an exact cutover date in its developer notice. The safest implementation is therefore to support the new domain and keep supporting both legacy domains.
What changes, and what does not
| Area | Before | After the migration | What developers should do |
|---|---|---|---|
| Sign in with Apple private email | @privaterelay.appleid.com | New aliases use @private.icloud.com | Accept both domains |
| iCloud+ Hide My Email | @icloud.com | New aliases use @private.icloud.com | Accept both domains |
| Existing relay aliases | Legacy domains | Continue working | Do not migrate or rewrite stored addresses |
| Sign in with Apple user identity | Apple user identifier | Unchanged | Keep using the user identifier as the account key |
| Outbound relay authentication | Registered source domains plus SPF/DKIM rules | Still required | Keep sender configuration valid |
Apple explicitly tells developers to update account systems, email-validation logic, and allowlists to accept private.icloud.com. It also tells email service providers to update domain-based filters, suppression lists, and routing rules that enumerate relay domains.
The tricky part is that the failure may not be inside Sign in with Apple itself. It can be several systems downstream.
1. Email validation that hard-codes Apple domains
The most obvious bug is a validator that contains special handling such as:
privaterelay.appleid.com
icloud.com
If the code treats those strings as the complete set of valid Apple relay domains, a newly created @private.icloud.com address can fail registration, profile updates, imports, or support tooling.
For ordinary email validation, the better design is to validate the address as an email address rather than maintain a list of providers.
If the application genuinely needs to classify Apple private relay addresses, temporarily treat all three domains as valid:
const APPLE_PRIVATE_RELAY_DOMAINS = new Set([
'privaterelay.appleid.com',
'icloud.com',
'private.icloud.com',
]);
Do not replace the old strings with the new one. Apple says existing legacy addresses will continue to work.
2. Account linking that treats email as the user ID
This migration is also a useful architecture check.
Apple's Sign in with Apple documentation says developers should use the user identifier rather than the email address to identify the user. The email can be real or private, and relay addresses are part of a privacy layer rather than a permanent identity key.
A fragile account model looks like this:
account_id = email
A safer Sign in with Apple model is closer to:
account_id = apple_user_identifier
contact_email = current Apple-provided email
The domain migration should not require existing Apple users to be recreated, merged, or renamed. If changing an email-domain rule can accidentally create a second account for the same Apple user, the account-linking logic deserves attention before the cutover.
3. Email-provider rules that silently suppress the new domain
Apple specifically calls out email service providers because relay domains are often present in infrastructure rules that product teams rarely inspect.
Check for domain lists in:
- suppression rules;
- bounce handling;
- routing rules;
- deliverability monitoring;
- customer-segmentation queries;
- transactional-email templates or middleware;
- data warehouse transformations.
A useful repository search is:
rg -n "privaterelay\.appleid\.com|private\.icloud\.com|@icloud\.com" .
Then repeat the search in infrastructure repositories, email-provider settings, analytics jobs, and no-code automation that may not live beside the application code.
4. Fraud and “disposable email” filters
Some services classify relay or masked addresses separately from ordinary mailboxes. A new dedicated domain makes that classification easier because private.icloud.com is explicit.
That creates two possible problems:
- a third-party anti-fraud product may initially classify the new domain incorrectly;
- an internal rule may deliberately reject privacy-relay addresses and start blocking legitimate Sign in with Apple users.
Apple's developer guidance is clear that apps using Sign in with Apple should accept the new domain. If a risk system blocks it, treat that as a policy decision that needs review rather than assuming the address is invalid.
There is also a broader privacy implication. TechCrunch noted that moving Hide My Email aliases away from the ordinary icloud.com domain makes new masked addresses easier for websites to distinguish. Apple has not said that making aliases easier to identify is the purpose of the change, so that consequence should be treated as an external analysis, not an Apple-stated goal.
5. CRM, support, and analytics rules that classify relay users
A migration can appear technically successful while internal operations break later.
Common examples include:
- a support macro that searches only for
@privaterelay.appleid.com; - a CRM segment named “Apple relay users” built from one domain suffix;
- a dashboard that counts private-email signups using the old domain;
- a data-cleaning job that marks unknown domains as invalid;
- an export pipeline that strips or rewrites relay addresses.
These failures are less visible than a broken login because users may still sign up successfully. The symptom appears later as missing email, duplicate reporting, or a support agent who cannot find the account.
The practical fix is to search data and automation definitions, not just application source code.
6. Tests and fixtures that keep the old assumption alive
Hard-coded fixture addresses often outlive production rules.
Search test data for examples like:
user@privaterelay.appleid.com
alias@icloud.com
Then add cases for @private.icloud.com while retaining legacy-domain tests.
At minimum, cover these flows:
- new Sign in with Apple registration using the new domain;
- returning login for an existing legacy relay address;
- account lookup by Apple user identifier;
- transactional email to the relay address;
- bounce/suppression handling;
- support and admin search.
A migration test is incomplete if it checks only whether the OAuth flow returns successfully.
Do not confuse recipient domains with your sender configuration
Apple's Private Email Relay has another requirement that is easy to mix up with this change.
To send mail through Apple's relay, developers must register their outbound email domains or addresses with Apple. Apple says those senders must pass SPF and/or DKIM authentication, and it recommends using both when possible.
That is separate from accepting private.icloud.com as a recipient domain.
Think of the two sides like this:
Your registered/authenticated sender
↓
Apple Private Email Relay
↓
user@private.icloud.com
Adding the new Apple recipient domain does not remove the existing sender-authentication requirements.
A 20-minute migration audit
Minutes 0–5: search code and configuration
Search for all three domain strings across application code, infrastructure, tests, and deployment configuration.
Minutes 5–10: inspect identity assumptions
Confirm that Sign in with Apple accounts are keyed by Apple's stable user identifier rather than by the relay email string.
Minutes 10–15: inspect email and operations systems
Review allowlists, suppression rules, fraud tooling, CRM segments, support searches, and analytics transformations.
Minutes 15–20: add transition tests
Keep legacy-domain fixtures and add private.icloud.com. Exercise both new-user and returning-user paths.
The important migration rule is simple:
add the new domain; do not delete the old ones.
What is still uncertain
As of August 13, Apple's June announcement still says the new domain will arrive “later this summer” rather than naming a specific day.
Apple's current Private Email Relay documentation also still describes relay addresses ending in @privaterelay.appleid.com or @icloud.com, while the newer developer-news notice says newly generated addresses will move to @private.icloud.com.
That is a good reason not to write rollout detection around a date. Make the system tolerant of all three domains now and let Apple control the transition timing.
What to watch next
Watch Apple's developer news and Sign in with Apple documentation for an exact rollout date or updated relay examples. After the switch begins, the most useful production signals will be:
- signup validation failures by email domain;
- bounced transactional email to
private.icloud.com; - fraud-tool rejects involving the new domain;
- duplicate-account creation in Sign in with Apple flows;
- support searches that fail to locate new relay users.
A small alert on those events is more useful than waiting for users to report that “Sign in with Apple stopped working.”
Conclusion
Apple's move to private.icloud.com is a small-looking domain change with a wide blast radius because email addresses often leak into validation, identity, deliverability, fraud, analytics, and support logic.
The safest migration is not complicated: support all three domains, keep legacy aliases untouched, key Apple accounts by the Apple user identifier, verify outbound relay authentication, and test the systems around login as well as the login itself.
Do that before the cutover and the domain change should be routine rather than an account-recovery incident.
Sources
Checked August 13, 2026:
- Apple Developer — New domain for Sign in with Apple and iCloud+ Hide My Email
- Apple Developer — Communicating using the Private Email Relay Service
- Apple Developer — Configure Private Email Relay Service
- Apple Developer — Receiving a User's Identity Token
- TechCrunch — Apple's Hide My Email domain change could make masked addresses easier to identify