Sign in with Apple Domain Consolidation: Developer and ESP Update Guide

Apple will stop issuing new relay addresses from its current Sign in with Apple and Hide My Email domains later this summer, consolidating both under a single shared domain. The Sign in with Apple domain consolidation affects only newly generated addresses; existing ones keep forwarding without interruption. Developers and email providers whose systems name the old domains explicitly need to update before the rollout begins.

Starting later this summer, all newly generated relay addresses for both features will come from private.icloud.com, replacing privaterelay.appleid.com for Sign in with Apple and icloud.com for Hide My Email, according to Apple's developer notice published two days ago. Only new addresses are affected; nothing about existing addresses changes.

If those systems aren't updated, users could encounter problems creating accounts, receiving verification codes, resetting passwords, and accessing other account-related emails, AppleInsider reported today. The failures split into two distinct categories that operate at different points in a user's workflow and fall to different teams to fix.

Hide My Email domain consolidation: what breaks and what doesn't

Apple is consolidating two relay domains into one. That is the full scope of the infrastructure change on Apple's side.

Sign in with Apple has routed masked login addresses through privaterelay.appleid.com; iCloud+ Hide My Email has issued aliases on icloud.com, the same domain as standard Apple email accounts. Both shift to private.icloud.com for any address created after the rollout, per Apple's notice, with WebProNews reporting the same yesterday.

Addresses already in use on the old domains are not migrated. They remain on their original domains and continue forwarding normally, Cult of Mac confirmed yesterday.

Apple has given no firm date beyond "later this summer" and has not confirmed a specific software release as the trigger. Cult of Mac noted that the rollout may coincide with iOS 27 in September, though Apple has not confirmed this. The rollout could begin without a separate announcement that would prompt a last-minute scramble.

Two failure modes, two teams responsible

The potential breakage falls into two categories that operate at different points in a user's workflow. They can occur independently, and conflating them makes both harder to diagnose.

Failure type 1: Account rejection at signup or login (developer responsibility)

When a user creates a new Sign in with Apple or Hide My Email address after the rollout, that address ends in @private.icloud.com. Any app or website that validates email format or domain against a fixed allowlist, without including the new domain, will reject that address at account creation or login.

Apple's developer notice is specific: account systems, email validation logic, and allowlists must all be expanded to accept private.icloud.com alongside privaterelay.appleid.com and icloud.com, per the notice. Those systems may need updates to properly handle new addresses created after the rollout, Apple said.

Account access problems can occur even if email forwarding continues to function normally, AppleInsider noted. Account-matching logic tied to a specific relay domain could fail to recognize a returning user who creates a second masked address on the new domain. That problem may not surface immediately, and it won't generate any obvious error.

Failure type 2: Transactional email delivery failure after signup (email provider/ESP responsibility)

Even when a user successfully creates an account with a private.icloud.com address, transactional emails can still fail to arrive if the sending infrastructure hasn't been updated.

Any ESP whose suppression lists, filtering rules, or domain-based routing configurations explicitly enumerate Apple relay domains will need to add private.icloud.com before the rollout. Without that update, messages to new-domain addresses could bounce or route to spam rather than forward correctly, WebProNews reported.

The detection problem is what makes this genuinely dangerous. Apple's relay accepts messages from unregistered sending domains at the SMTP level and returns a 250 OK response, then silently discards the email with no bounce and no delivery status notification, according to MailerToGo's deliverability guide. A team monitoring bounce rates sees nothing wrong. Users just never receive the email.

Those two failure types are independent. A service could successfully accept a new-domain signup address and still fail to deliver the verification code that completes account setup.

What each team needs to review before rollout

Apple's guidance names three categories of systems and two distinct audiences.

App and site developers:

• Email validation logic: expand any allowlist or regex specifying Apple relay domains to include private.icloud.com alongside the existing two, per Apple's notice
• Account systems: ensure identity matching, deduplication, and account-linking logic does not break when a user presents a private.icloud.com address
• Relay registration: outbound mail to Hide My Email users must route through Apple's Private Email Relay; the sending domain and outbound IP must be registered in the Apple Developer portal. Unregistered senders receive a 250 OK and their mail is dropped silently, per MailerToGo's deliverability guide

Email providers and ESPs:

• Domain-based filtering: update any rules that identify or treat Apple relay addresses differently based on domain name
• Suppression lists: review for explicit enumeration of privaterelay.appleid.com or icloud.com as relay indicators; add private.icloud.com
• Routing rules: ensure transactional mail bound for the new domain routes correctly rather than being flagged, deferred, or dropped, as Apple's notice specifies

Apple's guidance to both groups: treat relay addresses like ordinary customer email addresses and respect the forwarding rules. No sender verification beyond the designated relay is permitted, WebProNews reported.

One secondary shift is worth noting. Hide My Email addresses previously used the generic icloud.com domain, making them indistinguishable from standard Apple email accounts. The new domain labels them clearly as privacy relay addresses, and some users have raised concerns on forums including Reddit that websites and apps could more easily identify or block accounts using it, Times Now reported today. Sign in with Apple relay addresses have always been domain-identifiable, so the practical exposure is narrower than user concern suggests. No documented blocking has been reported.

No launch date, but the documentation is ready

Apple has given no precise launch date, and no specific software release has been named as the trigger. Apple's developer notice from two days ago is the authoritative checklist for both developers and ESPs.

The silent-drop behavior is the reason timing matters. Because Apple's relay returns a 250 OK before discarding mail from unregistered senders, per MailerToGo's guide, standard bounce monitoring won't catch delivery failures after rollout. The first signal will be users unable to verify accounts or reset passwords, not an alert in a dashboard.

"Later this summer" is not a launch date. It's a deadline for readiness. The updates themselves aren't technically complex they're configuration and process work that takes time to identify and QA, not to implement. Teams that wait for a firm date and then monitor for bounce spikes will miss the failures entirely. The documentation to act is already published.