Sign in with Apple Moves New Private Relay Emails to private.icloud.com: What to Check

If your app or website offers Sign in with Apple, some of your customers are registered with a relay email address rather than their real one. Until now those addresses have ended in privaterelay.appleid.com. On August 24, 2026, Apple confirmed in a developer notice that new Sign in with Apple addresses will instead be issued on private.icloud.com, starting later in 2026.

Nothing breaks for existing users. The risk is on the other side: sign-up forms, fraud filters, CRM rules and email tools that recognize the old domain and have never heard of the new one. This article explains what Apple announced, how it differs from the first version of the plan, and what the people responsible for your iPhone app development and back-end systems should check.

What Apple announced on August 24, 2026

The notice makes three statements. New Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com. Existing addresses on privaterelay.appleid.com will continue to work and forward mail to users without interruption. And developers whose apps or websites use Sign in with Apple should make sure their account systems, email validation logic and allowlists accept the new domain in addition to the existing one.

The timing is given only as starting later this year. Apple's notice does not name a day, so this is an announced change with no published effective date as of October 4, 2026.

How the plan changed since June

This is the second announcement on the subject, and teams that acted on the first one should know what moved. On June 15, 2026, Apple said it would unify the domains for two features, Sign in with Apple and iCloud+ Hide My Email, under private.icloud.com later in the summer. That page now carries a note that it contains outdated information and points to the August update.

The August 24 notice narrows the change. It says that after further consideration and community feedback, iCloud+ Hide My Email addresses will remain on icloud.com. Only Sign in with Apple addresses move, and the timing shifted from summer to later in the year. If your team added private.icloud.com to its rules after the June notice, that work is still valid.

How relay addresses work, briefly

When someone uses Sign in with Apple, they can choose to hide their email address. Apple's documentation on the private email relay service explains that the user is then given an automatically generated address, and that mail between your business and that user is routed through Apple's relay servers. Your systems store and send to the relay address; Apple forwards the message to the user's real inbox.

The same documentation says senders must register the email addresses or domains they send from and authenticate outbound mail with Sender Policy Framework (SPF), so that only authorized senders can reach users through the relay. It also notes that a user receives the same relay address across the apps of one development team, and that users can turn off forwarding for an app in their settings.

The domain change does not alter this mechanism. It changes what the part after the @ sign looks like for accounts created after the switch.

Where the new domain can cause problems

Apple's notice names account systems, validation logic and allowlists. In practice, a domain name tends to be written into more places than a team remembers. The list below is our own guidance on where to look, not Apple's wording.

• Sign-up and profile forms that validate email format or check domains against an approved or blocked list.
• Code that detects relay addresses by matching privaterelay.appleid.com, for example to skip marketing email, to ask the user for a contact address at checkout, or to merge duplicate accounts.
• Fraud and risk scoring that treats unfamiliar or newly seen domains as suspicious.
• Email service provider settings, suppression lists and routing rules that list relay domains explicitly.
• CRM, help desk and analytics tools that segment customers by email domain.

The second item is the easiest to miss. A rule written to give relay users special handling will quietly stop applying to new customers, and nothing will raise an error. An illustrative example: a retailer's checkout asks relay-address customers for a contact email for delivery updates. After the switch, new customers on private.icloud.com would not be asked, and delivery messages would go only through the relay.

What this means for your business

This section is interpretation and should be read as guidance.

The change is small in engineering terms and uneven in its consequences. For most businesses it is a short review followed by a few configuration or code edits. The cost of missing it falls on new customers at the moment they are trying to register: a rejected sign-up, a verification email that never arrives, or an account flagged for review. Those failures tend to show up as lower conversion rather than as a reported bug, which makes them slow to diagnose.

It also affects more than the iOS app. Sign in with Apple is commonly offered on websites and Android apps too, and the validation usually lives on the server, in whatever framework your back end uses. The same applies to third-party identity providers and authentication services that sit between Apple and your system. If you use one, check its documentation or ask its support team whether any domain-based logic on its side has been updated; we have not verified individual vendors.

The rules are identical for US and UK businesses. If you rely on email domain to make decisions about marketing consent or customer contact, review those rules with whoever advises you on data protection. This article is not legal advice.

What to do next

Start by searching your code, configuration and third-party tools for the string privaterelay.appleid.com. Every match is a place to add private.icloud.com alongside it. Keep the old domain: Apple says existing addresses continue to work, so both will be in use for the foreseeable future.

Next, test with a made-up address on the new domain in a staging environment. Confirm that it passes sign-up validation, that it is treated as a relay address wherever your logic makes that distinction, and that it is not blocked by your email provider. Confirm that your sending domains are still registered with Apple and that SPF passes, because relay delivery depends on it whichever domain the address uses.

Finally, because Apple has not published an exact date, make the change now rather than waiting for one. Accepting the new domain early has no downside, and it removes the need to watch for the switch.

Conclusion

On August 24, 2026, Apple confirmed that new Sign in with Apple relay addresses will be issued on private.icloud.com starting later in 2026, that existing privaterelay.appleid.com addresses keep working, and that iCloud+ Hide My Email stays on icloud.com. The required action is modest: find every place your systems recognize the old domain and make them accept both.

If you are not sure where those rules live in an application someone else built, request a quote for a short review and we can help you locate and update them.