# Sign in with Apple New Relay Domain private.icloud.com 2026
> Sign in with Apple private.icloud.com: Apple moves new relay addresses there later in 2026. What to check in email rules and allowlists, checked Oct 21, 2026.
Canonical: https://app369.com/blog/sign-in-with-apple-private-icloud-com-relay-domain-2026/
Last updated: 2026-10-21
[ **Simon Dziak** Founder & developer, App369](https://app369.com/about/szymon-dziak/) [LinkedIn](https://www.linkedin.com/in/szymondziak/)
Published October 19, 2026 · Updated October 21, 2026•Facts last verified October 21, 2026•7 min
App369https://app369.com/blog/sign-in-with-apple-private-icloud-com-relay-domain-2026/
[← Back to Blog](https://app369.com/blog/)
## Key takeaways
- →Apple's August 24, 2026 post says that starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com. Apple gives no exact date.
- →Apple says existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without interruption. So you will have two relay domains in your data, not a swap.
- →Apple's action item is to make sure account systems, email validation logic and allowlists accept private.icloud.com in addition to privaterelay.appleid.com.
- →iCloud+ Hide My Email addresses stay on icloud.com, according to the same post. They are a separate feature from Sign in with Apple relay addresses.
- →Firebase's Flutter federated auth page and the sign_in_with_apple package page say nothing about the new domain on the page, so the checks are in your own code: regexes, allowlists, filters and dedupe logic.
Pricing an app? Try the free [app cost calculator](https://app369.com/tools/app-cost-calculator/) or get a range for your project in the [instant quote](https://app369.com/instant-quote/).
**Apple’s August 24, 2026 developer post says that starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com. Apple gives no exact date. Existing privaterelay.appleid.com addresses keep working, so your app can see both domains. Apple asks developers to make account systems, email validation logic and allowlists accept the new domain in addition to the old one.**
I checked Apple’s post and docs on October 21, 2026. Apple can change a date or wording, so open the linked page before you plan around it.
**Disclosure:** App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Apple doesn’t pay me for anything on this page.
## The dated table
| Change | Who is affected | Date | What to do |
| --- | --- | --- | --- |
| New Sign in with Apple relay addresses move from privaterelay.appleid.com to private.icloud.com | Any app or website that uses Sign in with Apple and validates, filters or stores user emails | Post dated August 24, 2026. Issuing starts “later this year” with no exact date | Accept both domains in validation, allowlists and account lookups |
| Existing privaterelay.appleid.com addresses | Users who already signed in with Apple and hid their email | No change announced. Apple says they “will continue to work and forward mail to users without interruption” | Keep the old domain accepted. Do not rewrite stored addresses |
| iCloud+ Hide My Email | Users who made addresses in iCloud settings, not through Sign in with Apple | Apple says they “will remain on icloud.com” | Nothing new for this feature |
Source for all three rows: [Apple Developer News](https://developer.apple.com/news/?id=1ptvdtcm).
## What Apple does and does not say
The post is short, so here is the whole of what I can verify.
- It says new addresses will be issued on `private.icloud.com` “starting later this year.”
- It says existing addresses on `privaterelay.appleid.com` continue to work.
- It says Hide My Email addresses remain on `icloud.com`.
- It tells developers to make sure “account systems, email validation logic, and allowlists” accept the new domain in addition to the old one.
It gives no exact date, no list of affected apps, and no technical detail about the sending side. I am not going to guess at any of those.
## Checks to run in your code
Because I can’t see your code, treat this as a search list. Each item is my reading of what Apple’s one-line instruction means in practice.
1. **Email regexes and validators.** Search for `privaterelay.appleid.com`, `appleid.com` and `privaterelay` across your app, backend, admin tools and tests. A validator that hardcodes the old domain, or a pattern that allows only a fixed set of domains, would reject a `private.icloud.com` address.
2. **Allowlists and blocklists.** If you allow only certain domains, for example in a business-only or invite-only app, add the new domain. If you block free or consumer domains, check whether your `icloud.com` rules match `private.icloud.com` (an exact match will not, a suffix match will) and that this is what you intend. Apple’s docs also say relay addresses can end in @icloud.com, so a rule on that domain can hit them too.
3. **Disposable-email filters.** Some filters, or third-party lists, treat relay-style addresses as risky. Check what yours does with a `private.icloud.com` address, and what it does with the old domain today, so the two behave the same way.
4. **Backend dedupe and account matching.** If any job groups accounts by email domain, or tries to match a Sign in with Apple user to an existing account by email, check that it does not assume one relay domain. Do not merge accounts on the email alone.
5. **Analytics, CRM and email tools.** Segments, rules and suppression lists that mention the old domain need the new one added. Downstream tools may have their own validation.
6. **Stored data.** Leave existing addresses as they are. Apple says they keep working.
My advice: add the new domain next to the old one, never in place of it. Apple says existing addresses keep working, so expect users on both.
## Outbound email through the relay
Apple’s post does not announce a change here. What the help page says today, in the Certificates, Identifiers & Profiles docs for the private email relay:
- To send email through the relay, you register your outbound email domains or addresses in the Email Sources section of Certificates, Identifiers & Profiles.
- Apple says outbound email through the relay must authenticate with SPF and/or DKIM, and recommends using both if possible.
- The registered domain and the envelope sender domain must match exactly for the SPF check. If your email provider uses its own envelope domain, DKIM is required, and the signature domain must match the registered From: domain.
- Per Apple, if you don’t register all the source domains or emails you use, mail sent to the relay will bounce.
- Individuals can register up to 32 email sources and organizations up to 100.
The help page does not name any relay domains, and nothing I read says the new domain changes these steps. Apple’s Communicating using the private email relay service page says relay addresses end in @private.icloud.com, @privaterelay.appleid.com, or @icloud.com. It also says each relay address has a daily limit of 100 emails, counting both your mail and user replies. My suggestion is to open that page, confirm your sending domains show as passing the SPF check, and send a test message to a relay address after Apple starts issuing the new domain.
## Firebase and Flutter
I looked for anything official on the new domain.
- **Firebase Auth.** The Flutter federated authentication page covers Apple sign-in setup, a nonce and ID token, and revoking tokens. It does not mention the private relay or either domain.
- **sign_in_with_apple** (8.2.0 on pub.dev on October 21, 2026). The example requests the email scope. The page has an Apple Mail Relay section that says you need an SPF record because users may choose the private relay. It names no relay domain.
So I can’t say how either library treats the new domain, and I won’t guess. The email string comes back from Apple, so the risk is in what your own code does with it afterwards. Check any Cloud Function, security rule or trigger of yours that reads the email.
My advice: do not assume your auth library filters on the domain. Search your own functions and rules for the old domain.
## A short plan
1. **Search** your repos for `privaterelay.appleid.com` and `appleid.com`, including tests and fixtures.
2. **Update** validators, allowlists, blocklists and filters to accept both `privaterelay.appleid.com` and `private.icloud.com`.
3. **Review** dedupe and account-matching code so it doesn’t treat the email domain as an identity.
4. **Check** your outbound mail: registered sender domains, SPF, DKIM, and the status in your Apple developer account.
5. **Test** a fresh Apple ID sign-in with Hide My Email on a real device once Apple starts issuing the new domain, and again on a release build. If the web sign-in fails with `invalid_client` while you test, see [Sign in with Apple invalid_client](https://app369.com/fix/supabase-sign-in-with-apple-invalid-client/). Apple gives no date, so I would add a test fixture with a `private.icloud.com` address now and run it against your validators.
6. **Watch** Apple’s developer news for the actual start date.
For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see [App Store and Google Play deadlines for 2026 and 2027](https://app369.com/blog/app-store-google-play-deadlines-2026-2027/).
## Need a hand?
If your Flutter app uses Sign in with Apple and you want the validation, allowlists and email setup checked before the new domain appears, the [App Fix Ticket](https://app369.com/fixed-price/flutter-firebase-bug-fix/) covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or [send me a short description](https://app369.com/contact/).
## **Frequently asked questions**
- **What is changing with Sign in with Apple relay addresses?**
- Apple's August 24, 2026 developer news post says that starting later this year, new Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com. Apple does not give a more exact date in the post.
- **Do my existing users' relay addresses stop working?**
- Apple's post says existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without interruption. The post does not say existing addresses will be changed.
- **Does this affect iCloud+ Hide My Email?**
- Apple's post says that after further consideration and reviewing community feedback, iCloud+ Hide My Email addresses will remain on icloud.com. The change applies to new Sign in with Apple addresses.
- **What exactly does Apple tell developers to do?**
- Apple says developers with apps or websites that use Sign in with Apple should ensure their account systems, email validation logic and allowlists accept addresses on private.icloud.com in addition to privaterelay.appleid.com.
- **Do I need to change my outbound email setup for the private relay?**
- Apple's post does not mention a change to sender registration. Apple's Certificates, Identifiers & Profiles help page says that to send email through the relay you register your sending domains or addresses, and that mail must authenticate with SPF and/or DKIM. Nothing there says the new domain changes this, so I would re-check your setup but not assume a change.
- **Does Firebase Auth or the Flutter sign_in_with_apple package handle the new domain?**
- I could not confirm it. Firebase's Flutter federated authentication page does not mention the relay or either domain. The sign_in_with_apple page on pub.dev does not name a relay domain either. Treat any claim that they handle private.icloud.com for you as unverified, and test it.
## **Sources**
1. [Apple Developer News, Update: New domain for Sign in with Apple (August 24, 2026)](https://developer.apple.com/news/?id=1ptvdtcm)
2. [Apple Developer Documentation, Communicating using the private email relay service](https://developer.apple.com/documentation/signinwithapple/communicating-using-the-private-email-relay-service/)
3. [Apple Developer Help, Configure private email relay service](https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/)
4. [Firebase Docs, Federated identity and social sign-in (Flutter)](https://firebase.google.com/docs/auth/flutter/federated-auth)
5. [pub.dev, sign_in_with_apple](https://pub.dev/packages/sign_in_with_apple)
Tags
#sign in with apple private.icloud.com #privaterelay.appleid.com #apple private email relay #sign in with apple email validation #apple hide my email icloud.com #sign in with apple allowlist #firebase auth apple sign in #flutter sign_in_with_apple #apple private relay spf dkim
Generated from app369.com . © 2026 App369. All rights reserved.
**Share:**
[Share on Twitter](https://twitter.com/intent/tweet?text=Sign%20in%20with%20Apple%20New%20Relay%20Domain%20private.icloud.com%202026&url=https%3A%2F%2Fapp369.com%2Fblog%2Fsign-in-with-apple-private-icloud-com-relay-domain-2026%2F) [Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fapp369.com%2Fblog%2Fsign-in-with-apple-private-icloud-com-relay-domain-2026%2F) [Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fapp369.com%2Fblog%2Fsign-in-with-apple-private-icloud-com-relay-domain-2026%2F)
## **Related Resources **
[How to Debug a Flutter and Firebase Bug: Find the Root Cause (2026)](https://app369.com/blog/how-to-debug-a-flutter-firebase-bug-2026/) [Firebase Cloud Functions Min Instances: What They Cost (2026)](https://app369.com/blog/firebase-cloud-functions-min-instances-cost-2026/) [How to Test Firebase Security Rules with the Emulator (2026)](https://app369.com/blog/how-to-test-firebase-security-rules-2026/) [Firebase Security Rules Best Practices: The Complete Guide (2026)](https://app369.com/blog/firebase-security-guide-2026/) [Firebase Studio Shutting Down: How to Migrate by March 2027](https://app369.com/blog/firebase-studio-shutting-down-migrate-project-2027/) [Firebase ML Model Hosting Shutting Down: How to Migrate](https://app369.com/blog/firebase-ml-model-hosting-shutting-down-migrate-2027/)
## **Related guides **
[**App Store and Google Play Deadlines for 2026 and 2027**
Dated table of App Store, Google Play, Firebase and Google API deadlines for mobile apps in 2026 and 2027, each linked to its source. Checked Oct 21, 2026.**Read more **](https://app369.com/blog/app-store-google-play-deadlines-2026-2027/) [**Google Play Contacts and Location Permission Changes 2027**
Google Play Contacts Permissions policy and other sensitive-permission changes: the dates, who must act, and what it means for Flutter, checked Oct 21, 2026.** Read more **](https://app369.com/blog/google-play-contacts-permissions-policy-2027/) [**Google Sign-In for Android Is Deprecated: Moving to Credential Manager**
Google Sign-In for Android is deprecated and moved to Credential Manager. How to migrate Android and Flutter apps (google_sign_in 7), checked Oct 21, 2026.** Read more **](https://app369.com/blog/google-sign-in-android-deprecated-credential-manager-2026/)