Apple told developers on August 24, 2026, that new Sign in with Apple relay addresses will move from the privaterelay.appleid.com domain to a new one, private.icloud.com, later this year, while confirming that iCloud+ Hide My Email addresses will stay on icloud.com after the company reviewed feedback from its developer community.

In short

Apple is changing the domain used for new Sign in with Apple email addresses, moving future ones from privaterelay.appleid.com to private.icloud.com starting later in 2026, according to a notice posted on the Apple Developer News page. This matters for any company that lets people log in with an Apple Account and then emails those users, because a mail system that only recognizes the old domain could silently fail to deliver messages to newly issued addresses. The practical takeaway: developers need to add private.icloud.com to their allowlists and validation logic alongside the existing domain, since old addresses will keep working exactly as before.

The update, published on the Apple Developer News page on August 24, 2026, is narrow in scope but touches a piece of infrastructure that sits underneath a very large number of consumer sign-up flows. Sign in with Apple has been available since 2019, and its privacy-preserving relay system, commonly called Hide My Email when used through Sign in with Apple, generates a unique, anonymized email address for each app or website a user connects to. Those addresses forward messages to the user's real inbox without exposing the underlying address to the service on the other end. Apple's notice confirms that this basic mechanism is not changing. What changes is the domain name attached to newly created addresses.

What Apple announced

According to Apple's developer notice, new Sign in with Apple addresses will be issued on private.icloud.com rather than privaterelay.appleid.com starting later this year. The company did not attach a specific calendar date to the switch beyond "later this year," leaving developers with a general timeframe rather than a fixed deadline. Existing addresses already issued on privaterelay.appleid.com are explicitly unaffected. Apple's notice states that those addresses "will continue to work and forward mail to users without interruption," meaning no migration, re-verification, or user action is required for accounts that already have a relay address tied to the old domain.

A second, separate clarification appeared in the same notice: iCloud+ Hide My Email addresses, the version of the feature available broadly through an iCloud+ subscription rather than specifically through Sign in with Apple, will remain on the icloud.com domain. Apple described this as a decision reached "after further consideration and reviewing community feedback," language that suggests the company had at some point considered folding that feature into the same domain change and stepped back from doing so. The notice does not specify what the community feedback contained or who submitted it, and Apple has not published additional detail beyond the developer news item itself.

The distinction between the two systems is easy to miss but matters for anyone building account infrastructure. Sign in with Apple's relay addresses and iCloud+'s Hide My Email addresses are related features that both anonymize a user's real email behind a forwarding address, but they serve different entry points. One is generated automatically when a user chooses to hide their email during an Apple sign-in flow inside a third-party app. The other can be created independently by any iCloud+ subscriber, including directly from the Mail app on iCloud.com, without any connection to a third-party login at all. Apple's decision keeps the iCloud+ version untouched while moving only the Sign in with Apple version to the new domain.

Why the domain matters for deliverability

Email relay addresses are not decorative. Every message a business sends to a user who signed up through Sign in with Apple with email hidden has to pass through Apple's relay infrastructure before it reaches an inbox, and that infrastructure only forwards mail from senders it recognizes as registered. Apple's own developer documentation, referenced in the notice under a link to "Communicating using the Private Email Relay Service," lays out requirements around domain registration, sender authentication, and message formatting that developers must follow for their mail to be relayed at all.

A domain change touches several of those requirements at once. Any system that validates incoming email addresses against a fixed pattern, such as a regular expression checking for an appleid.com suffix, would fail to recognize a private.icloud.com address as valid unless updated. Any allowlist that filters accepted sender or recipient domains at the infrastructure layer, whether inside a company's own mail transfer agent or a third-party email service provider, faces the same exposure. Apple's notice is direct about the fix: "Developers with apps or websites that use Sign in with Apple should ensure that their account systems, email validation logic, and allowlists accept addresses on the new private.icloud.com domain in addition to the existing privaterelay.appleid.com domain."

That last phrase, "in addition to," is the operative instruction. Because old addresses persist indefinitely on the original domain, developers cannot simply swap one domain for another in their configuration. Systems need to accept both domains simultaneously, on an ongoing basis, since a single user base will likely contain a mix of addresses issued before and after the cutover for as long as any user retains an account created under the old system.

The mechanics behind Apple's private email relay illustrate why the domain string itself carries weight beyond cosmetics. Apple's own developer documentation describes a relay architecture in which mail transfer agents on Apple's side only forward messages from source domains or email addresses that a developer has registered in the Apple Developer Portal. That registration step is domain-specific: a sending domain authorized to relay mail to addresses under privaterelay.appleid.com is a distinct configuration entry from one authorized under private.icloud.com, even though both ultimately forward to the same underlying inboxes. Developer forum threads on Apple's own support channels have historically documented cases where messages bounced with a "550 5.1.1 Relay not allowed" error after configuration changes elsewhere in a developer's Apple account, illustrating how sensitive the relay system is to exact domain matching. A migration that introduces a second valid domain without a corresponding update to sender authorization records risks a similar failure mode, one that can be difficult to diagnose because affected users typically only discover the problem when they stop receiving expected mail, such as password resets or order confirmations, without any visible error on the sending side.

The marketing and ad tech angle

For publications like PPC Land that track identity infrastructure changes affecting marketing technology, this kind of update sits in a recurring category: platform-level identity systems that were not built with advertising or marketing operations in mind, but that marketing systems depend on anyway because so much of digital commerce runs through email-based account creation and communication.

PPC Land's coverage of Gmail's own address change feature, which Google enabled for United States users on March 31, 2026, described a structurally similar problem from a different angle. That change let users pick a new @gmail.com username while keeping their old address alive as a forwarding alias, and a follow-up analysis from PPC Land noted that email addresses function as identity anchors used for audience matching, Customer Match uploads, email marketing lists, and cross-channel attribution, not merely as login credentials. The same logic applies here, in reverse. Apple is not changing which address a user is reachable at; it is changing the domain suffix attached to new addresses in a system many marketing platforms already treat as an opaque, non-human-readable identifier. But any code path that does pattern-match against the domain string, rather than treating the full address as an opaque token, needs updating regardless of whether a marketer ever looks at the address directly.

The recurring theme across these stories is that identity plumbing changes at the browser and platform level increasingly require marketing and product teams to audit systems not typically thought of as identity-dependent at all: spam filters, CRM validation rules, transactional email templates, and audience upload pipelines. PPC Land's reporting on Google's own migration to FedCM, the browser-mediated federated identity standard Google adopted starting in April 2024, covered a related shift in how consumer identity providers manage sign-in without depending on third-party cookies. That standard remained active in Chrome even after the browser retired most other Privacy Sandbox technologies on October 17, 2025, underscoring how browser-mediated identity standards have proven more durable than the advertising-specific infrastructure built around them. Apple's relay domain change is a smaller and more contained example of the same underlying dynamic: consumer-facing identity conveniences, once shipped, generate long-tailed maintenance obligations for every business that integrated with them.

What is not changing

Apple's notice is precise about scope, and the boundaries are worth stating plainly given how easily domain changes get overstated. The authentication mechanism behind Sign in with Apple, including its compatibility with OAuth 2.0 and OpenID Connect and its integration with Face ID, Touch ID, and Optic ID across Apple's device lineup, is untouched by this change. The relay and forwarding behavior itself, where a message sent to a hidden address reaches the user's real inbox automatically, continues operating the same way it always has. No user is required to take any action. Apple's notice states plainly that existing privaterelay.appleid.com addresses "will continue to work," a commitment that, if honored, means no developer needs to migrate stored addresses, re-authenticate users, or notify anyone that anything happened on the back end.

What is changing is narrower than a first read might suggest: only newly created Sign in with Apple relay addresses, generated after the still-unspecified rollout date later in 2026, will carry the private.icloud.com suffix. Everything issued before that date keeps its original domain permanently, based on Apple's stated commitment to uninterrupted forwarding.

Open questions

Apple's developer notice leaves several details unresolved. The company has not published an exact date for when the switch takes effect, only the general window of "later this year." It has not explained what specific community feedback led it to keep iCloud+ Hide My Email addresses on icloud.com rather than folding them into the same domain change developers had apparently anticipated. Nor has Apple indicated whether the private.icloud.com domain will eventually expand to cover other services, or whether this is a narrowly scoped change limited to Sign in with Apple relay addresses going forward. Developers monitoring the Apple Developer News page and the linked documentation on the Private Email Relay Service are likely to be the first to see any further clarification, since Apple has not indicated additional public disclosure through other channels.

Timeline

  • September 19, 2019 - Sign in with Apple launches as a single sign-on provider across iOS, Android, and the web.
  • April 26, 2021 - Apple releases App Tracking Transparency with the iOS 14.5 update, a separate privacy framework governing consent for cross-app tracking.
  • February 2024 - Google shifts Sign-in with Google onto the FedCM browser standard, a separate identity migration PPC Land reported at the time.
  • October 17, 2025 - Chrome retires most Privacy Sandbox advertising technologies while the FedCM standard remains active in the browser.
  • March 31, 2026 - Google enables Gmail address changes for United States users, a structurally comparable identity update covered by PPC Land.
  • April 2, 2026 - Google publishes technical guidance on what the Gmail username change could break for platforms relying on email-based identification, examined in PPC Land's follow-up report.
  • August 24, 2026 - Apple publishes its developer notice announcing the move of new Sign in with Apple relay addresses to private.icloud.com and confirming iCloud+ Hide My Email addresses remain on icloud.com.
  • Later in 2026 - Apple's stated rollout window for the private.icloud.com domain to begin issuing new Sign in with Apple relay addresses, per the company's developer notice.

Summary

Who: Apple, addressing developers who integrate Sign in with Apple into their apps and websites.

What: Apple is moving newly issued Sign in with Apple relay email addresses from the privaterelay.appleid.com domain to a new domain, private.icloud.com, while keeping existing addresses functional on the old domain indefinitely and keeping iCloud+ Hide My Email addresses on icloud.com.

When: Apple published the notice on August 24, 2026, with the domain change itself scheduled for an unspecified date "later this year."

Where: The announcement appeared on the Apple Developer News page, applicable globally to any developer using Sign in with Apple.

Why: The change affects any system that validates, filters, or allowlists email addresses tied to Sign in with Apple, requiring developers to update their infrastructure to accept the new domain alongside the old one before the rollout begins, or risk mail delivery failures to newly signed-up users.