What changed
Apple updated its private-email relay migration on August 24, 2026. Starting later this year, newly generated Sign in with Apple relay addresses will use `private.icloud.com` instead of `privaterelay.appleid.com`. Existing `privaterelay.appleid.com` addresses will continue to forward without interruption. Apple had originally announced in June that both Sign in with Apple and iCloud+ Hide My Email would move to the shared domain, but after community feedback it has reversed the Hide My Email part: those addresses will remain on `icloud.com`. Developers are explicitly told to update account systems, email validation logic and allowlists to accept the new Sign in with Apple domain alongside the legacy one.
Why it matters
Relay addresses often become durable account identifiers and flow through validation libraries, user tables, fraud systems, support tools, suppression lists and outbound-email routing. Code that assumes every Sign in with Apple relay ends in `privaterelay.appleid.com` can reject new users or misclassify their addresses once the migration begins. Because legacy addresses keep working, builders need dual-domain compatibility rather than a one-time data rewrite. Email providers and lifecycle systems also need to avoid treating the new domain as an ordinary untrusted alias if they have special routing or suppression logic for Apple relay addresses.
New and existing users can now have different relay domains
Apple says new Sign in with Apple addresses issued later in 2026 will use `private.icloud.com`, while previously created addresses on `privaterelay.appleid.com` remain active. Applications should therefore treat both domains as valid Apple private-relay identities for the foreseeable future rather than trying to normalize old stored addresses onto the new suffix.
The June plan has been partially reversed
Apple’s June announcement proposed one shared `private.icloud.com` domain for both Sign in with Apple and iCloud+ Hide My Email. The August update says Hide My Email will remain on `icloud.com` after feedback. Systems trying to identify Apple privacy addresses should not assume all relay features are converging on one suffix.
Validation rules are the first place to look
Apple specifically calls out account systems, email validation logic and allowlists. Builders should search for exact-domain comparisons, regular expressions, disposable-email filters and identity rules that special-case `privaterelay.appleid.com`. A standards-compliant generic email validator may already accept the new address, but business logic layered on top can still break.
Email routing and deliverability rules may also encode the old domain
The original migration notice told email service providers to review domain-based filtering, suppression and routing rules. Even though the August update narrows the scope to Sign in with Apple, that operational advice still applies wherever software explicitly recognizes Apple relay addresses. Teams should test transactional email, support replies, bounce handling and account-recovery flows using both relay domains.
Do not rewrite stored user addresses simply because the suffix changes
Existing relay addresses continue to forward, and a user’s stored email can be part of authentication, account linking or historical records. The safe migration is to accept the new domain for future addresses while preserving existing values unless Apple provides a user-driven account-change event or the application has another verified reason to update the address.