Sign in with Apple + Hide My Email: new relay domain private.icloud.com (Apple Developer)
Apple is unifying Sign in with Apple and iCloud+ Hide My Email relay domains under private.icloud.com. Existing relay addresses keep working, but your validation, allowlists, and ESP filtering rules need to accept the new domain to avoid silent deliverability bugs.
Apple posted a small notice that can turn into a big “why are users not receiving emails?” incident if you miss it.
- Source: Apple Developer News (June 15, 2026), “New domain for Sign in with Apple and iCloud+ Hide My Email”
- Read: https://developer.apple.com/news/?id=sus6t6ab
What changed
Later this summer, Apple will unify relay email domains under a single shared domain:
- New relay addresses will be issued on: private.icloud.com
- Legacy domains mentioned:
- Sign in with Apple used: privaterelay.appleid.com
- Hide My Email used: icloud.com
Apple says existing addresses will continue to work and forward mail without interruption.
Why this matters
Anything that “validates” email domains can accidentally break:
- signup / login flows that reject unknown domains
- account linking rules (“must be a real email provider” heuristics)
- ESP allowlists/suppression rules (domain-based filtering)
- support tooling that tries to dedupe or categorise relay accounts
The nasty part: you can create a silent failure where everything looks fine in-app, but verification and password-reset emails never arrive.
Tiny win (10 minutes)
Add private.icloud.com to:
- your email domain allowlist / validator
- any ESP domain-based rules, suppression lists, or routing logic
- your regression checklist (test: Sign in with Apple -> email verification -> password reset)
If you can, add a monitoring alert for sudden spikes in “didn’t receive email” tickets coming from relay accounts.
Want help with ASO?
If you want this implemented for your app, check out our services - or run your workflow in APPlyzer.