Update: Sign in with Apple relay emails will be issued on private.icloud.com (Aug 2026)

This is a small announcement with outsized support impact. If your signup, login, or CRM stack has any domain-based rules, you want this on your “prevent silent breakage” checklist.

• Source: Apple Developer News, “Update: New domain for Sign in with Apple” (Aug 24, 2026)
• Read: https://developer.apple.com/news/?id=1ptvdtcm

What changed (vs the June announcement)

Apple’s June note suggested both Sign in with Apple relay addresses and iCloud+ Hide My Email would unify under private.icloud.com.

This August update clarifies the final shape:

• Sign in with Apple (new relay addresses): moving from privaterelay.appleid.com to private.icloud.com (later this year).
• Existing Sign in with Apple addresses: keep working and will continue forwarding.
• iCloud+ Hide My Email: will remain on icloud.com (after community feedback).

Why app marketers should care

• Lifecycle/CRM failures look like “random churn”. If your emails stop landing for a subset of users, you see it as lower activation, fewer paywall recoveries, higher refund risk, and “support is busy”.
• Validation and allowlists are surprisingly common. Many teams have “must be a normal domain” logic in onboarding or account tools, or vendor allowlists for support/admin accounts.
• Fraud/risk and ESP rules can block new domains. Domain-level suppression and routing rules are an easy way to create invisible deliverability issues.

Tiny win (15 minutes)

1. Audit any domain-specific logic: email validation, allowlists, fraud/risk, ESP routing, suppression.
2. Ensure you accept private.icloud.com in addition to privaterelay.appleid.com.
3. Add a QA checklist step: create a new Sign in with Apple account and verify at least one triggered email arrives.

Related (June context): https://developer.apple.com/news/?id=sus6t6ab