AI & TechnologySign in with Apple New Relay Domain private.icloud.com 2026

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 19, 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

Source for all three rows: Apple Developer News.

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.
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 Apple relay domains, and nothing I read says the new domain changes these steps. 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. In the part of the page I read, it does not mention the private relay or either domain. I read the whole page and found no mention of the relay or either domain.
• sign_in_with_apple (8.2.0 on pub.dev when I read it). 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. 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.

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 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.