Apple is preparing a small but important plumbing change for Sign in with Apple: later this year, newly generated private relay email addresses will use the @private.icloud.com domain instead of @privaterelay.appleid.com. Existing relay addresses are not being retired, and Apple says they will continue forwarding email without interruption.

For most people, this will be invisible. Someone signing up for an app with “Hide My Email” enabled will still get a randomly generated address rather than exposing their personal inbox. But for developers, email platforms, and companies with overly strict address-validation rules, it is a reminder that identity infrastructure has a habit of becoming product infrastructure – and that even a domain-name change can break a customer journey if nobody is watching.

Sign in with Apple arrived as Apple’s privacy-first alternative to conventional social login. Instead of creating yet another password or handing over a personal email address to every app and website, users can authenticate with their Apple Account. When they choose the “Hide My Email” option, Apple gives the service a unique relay address and forwards messages sent there to the user’s verified email address. The app gets a way to contact its customer; the customer keeps their real address out of the service’s database.

The new @private.icloud.com suffix does not change that underlying bargain. It is still a relay, not a conventional mailbox that users log into. Apple’s documentation says relay addresses can route messages to a verified email address associated with the user’s Apple Account, and that the addresses are designed to differ across development teams. That distinction matters: it makes it harder for separate companies to use the address itself as a simple cross-service tracking identifier.

What changes is the address that new Sign in with Apple users may see. Until now, Apple issued these addresses through @privaterelay.appleid.com. Going forward, it will issue new ones through @private.icloud.com. Apple has explicitly said the older addresses will remain operational and keep forwarding mail, so this is a migration of the front door, not a shutdown of the old building.

There is one meaningful clarification tucked into Apple’s announcement. The company had apparently considered moving iCloud+ Hide My Email addresses as well, but after reviewing community feedback, it decided that those addresses will remain on the familiar @icloud.com domain. In other words, the new @private.icloud.com domain is specific to newly issued Sign in with Apple relay addresses, rather than a universal rebranding of every Apple email-alias product.

That nuance is likely to spare users some confusion. Apple’s privacy tools can look similar from the outside because both hide a personal email address, but they sit in slightly different places in the company’s ecosystem. Sign in with Apple is an authentication and account-creation mechanism for third-party apps and websites; iCloud+ Hide My Email is a broader alias tool people can use more generally. Keeping their visible domains separate makes the distinction a little easier to preserve.

For developers, however, the practical message is blunt: accept both domains. Apple says organizations using Sign in with Apple need to update account systems, email-validation logic, and allowlists so they recognize @private.icloud.com as well as the legacy @privaterelay.appleid.com.

This sounds obvious, but plenty of systems still make assumptions about what a “real” email address should look like. A signup flow might accept addresses from gmail.com, outlook.com, and icloud.com while rejecting an unfamiliar subdomain. A fraud tool could score a newly seen domain as suspicious. A marketing platform may reject addresses that were not explicitly approved by an administrator. An internal support agent may even mistakenly tell a customer that a relay address is invalid.

Those failure points are especially awkward because the customer usually has done exactly what the service asked: they selected a supported sign-in option and chose the privacy setting Apple offered. If an app then blocks the address or repeatedly asks for a personal email account, it turns a privacy-preserving choice into extra work. Apple’s design guidance is unusually direct on this point: developers should avoid asking users for their real email address after they have chosen a private relay address.

The right technical response is not merely to add one more domain to a hard-coded list. Companies should treat Apple relay addresses as valid customer identities wherever email is a legitimate communication channel. That means reviewing form validation, CRM imports, transactional-email providers, support tools, fraud rules, and any allowlists used by backend services. If a product verifies an email address by sending a confirmation link, it should also ensure that its outbound sender domain is properly configured for Apple’s relay service.

Apple requires developers to register the email domains or sources they use to send messages through its private email relay system, and it requires SPF authentication for outbound mail. Those controls are designed to prevent unauthorized senders and reduce spam reaching users through the relay. The service also imposes a daily limit of 100 emails per private relay address, counting both messages from the developer and replies from the user – another sign that this is intended for useful account communication, not high-volume marketing blasts.

There is a broader lesson in the update. Privacy features often fail or succeed at the edges: the login button may work perfectly, but a rigid email validator, a badly configured sender domain, or a customer-service workflow can quietly undermine the experience. Apple is moving Sign in with Apple addresses closer to the iCloud brand in name, but it is also asking the developer community to keep up with the operational reality behind that new label.

For consumers, nothing needs to be done. Existing @privaterelay.appleid.com addresses should continue working, while future Sign in with Apple registrations may generate the newer @private.icloud.com addresses. For businesses that support Apple’s login system, this is a low-effort update with a high potential cost if ignored: accept the new domain now, preserve support for the old one, and make sure customers who choose privacy do not have to fight their way through signup.