Core answer: Apple is issuing new Sign in with Apple relay addresses on a second domain. Nothing is being retired, so this is an additive allowlist change, not a migration.
Accept both private.icloud.com and privaterelay.appleid.com. Anything that hardcodes only the older domain will start rejecting legitimate new users.
What changed in Sign in with Apple private.icloud.com terms
On 24 August 2026 Apple published a short update to the Sign in with Apple private email relay. New relay addresses will be issued on private.icloud.com starting later in 2026.
Addresses already issued on privaterelay.appleid.com keep working and keep forwarding mail without interruption. Apple was explicit about that, which is the detail that changes how you should respond.
This is not a cutover with a deadline. It is a second valid domain appearing in a field your code already handles, which is a quieter and more dangerous kind of change.
Recognition cues: how this breaks in the wild
The failure does not announce itself as a domain problem. It arrives disguised as four ordinary bugs.
The rejected signup. A validation rule allowlists known relay domains and returns “invalid email” for everything else. The user sees a form that refuses a working address.
The silent bounce. Transactional mail is sent to an address your suppression logic classified as untrusted because the domain was unfamiliar. Delivery reports look fine; the user never receives anything.
The duplicate account. A returning user signs in and your matching logic fails to connect the new address to the existing record. They get an empty account and file a data-loss complaint.
The blocked reply. Your outbound sender was registered with Apple for one relay domain and mail to the other is refused. This one surfaces last, usually in a churn report rather than an error log.
Three places the old domain is hiding
Search your codebase for the literal string privaterelay.appleid.com. It usually appears in more layers than a team expects, and the layers fail differently.
Validation and matching. Signup regexes, email normalizers, account-linking rules, and the “is this a disposable address” heuristics that some teams bolt onto registration.
Deliverability configuration. Suppression lists, ESP allowlists, spam-scoring overrides, and the registered outbound sender addresses configured in the Apple Developer portal for the relay service.
Analytics and support tooling. Dashboards that bucket users by email domain, fraud rules that treat unfamiliar domains as risk signals, and the support macros that tell an agent an address looks fake.
The third group is the one that gets skipped. Nobody thinks of a fraud rule as email validation until it silently ranks a legitimate signup as suspicious.
The mistake to avoid: treating this as a rename
The obvious response is to find the old domain and replace it. That reading breaks the users you already have.
Existing relay addresses are not being reissued. A replacement leaves every account created before the change unmatched, which converts a future problem into a present outage.
There is a second trap in the same announcement. Apple had planned to move iCloud+ Hide My Email addresses to the same new domain and, after reviewing feedback, decided to leave them on icloud.com.
Hide My Email and Sign in with Apple are different products that produce similar-looking addresses. A rule written against the wrong one will pass review and still be wrong.
Test with a real address, not a synthetic one. Create a throwaway Apple Account and sign in to your own staging build. A hand-written fixture proves your regex matches your regex; it does not prove the domain Apple actually issues today is accepted.
Decision rules
Match on the relay behaviour, not the string. If your logic needs to know an address is a relay address, keep a list of relay domains rather than a single constant, and let that list grow without a code change.
Never reject an address because its domain is unfamiliar. Domain allowlists are a fraud control that ages badly. Bound the risk with rate limits and verification instead.
Keep account matching on the stable identifier. Sign in with Apple returns a stable user identifier; the email is a contact channel. A system that keys accounts on the address inherits every future change to the address.
Register both domains wherever a sender is registered. Deliverability configuration lives outside your repository, so it will not appear in any code search you run.
Field checklist
Run this against a staging environment before the new addresses start arriving, because the first production report will arrive as a confused user rather than an alert.
1. Grep the repository for the old relay domain and list every hit with its layer: validation, delivery, analytics, or support tooling.
2. Add the new domain everywhere the old one appears, keeping both. Confirm no branch treats the pair as mutually exclusive.
3. Check the outbound sender registration in the Apple Developer portal covers mail to both relay domains.
4. Sign in to a staging build with a fresh Apple Account and complete the full loop: create an account, receive a transactional email, sign out, sign back in, and confirm you land on the same record.
5. Verify your fraud and analytics rules did not silently downgrade that signup while the functional path succeeded.
6. Confirm your Hide My Email handling still reads icloud.com and was not swept into the same change.
The test worth running this week
Take one real address on the new domain through your signup, your mail, and your support console in a single sitting. The layers that fail will be the ones nobody listed as email validation.
That is the whole point of an additive change: it does not break the path you test. It breaks the paths you forgot were reading the same field.
Further reading on the platform decisions behind this: our guide to mobile app development and the walkthrough of AI tech in production systems.
Primary source: Apple’s developer update on the new domain for Sign in with Apple and the reference on communicating using the private email relay service.
