Apple backtracks: Hide My Email addresses aren't moving after all

What’s actually changing

Apple has confirmed a tweak to how “Sign in with Apple” handles its private relay email addresses — the randomly generated ones (like abc123@privaterelay.appleid.com) that let you sign into an app without giving it your real email. From later this year, newly issued addresses of this type will use a different domain: private.icloud.com instead of privaterelay.appleid.com.

Crucially, Apple’s post says addresses already issued on the old domain will keep working exactly as before, forwarding mail without interruption. Nothing you’ve already set up needs touching.

The bit that got walked back

Here’s the part that caused a stir on developer forums and Hacker News: Apple’s separate iCloud+ perk, Hide My Email — the one you use to generate throwaway addresses for newsletters, shops or dodgy sign-up forms, not tied to any specific “Sign in with Apple” flow — was reportedly at risk of a similar domain shuffle. Apple’s update explicitly says that, “after further consideration and reviewing community feedback,” those Hide My Email addresses will remain on icloud.com. In plain terms: a change was floated, people complained, and Apple has held the line on the domain that underpins millions of existing masked addresses.

That distinction matters. Sign in with Apple relay addresses and Hide My Email addresses look similar and use related plumbing, but they’re not the same feature, and only one of them is getting a new domain.

So who is actually affected

If you’re an ordinary iPhone or Mac user who has handed out Hide My Email addresses to random websites over the years, this news changes nothing for you — those addresses stay put on icloud.com, as they always have.

The people who need to pay attention are developers. Apple’s guidance is aimed squarely at anyone who has built an app or website using “Sign in with Apple”: they’re told to update their account systems, email validation logic and allowlists so they accept addresses from the new private.icloud.com domain alongside the existing one. Fail to do that, and new users signing in with Apple could find their relay emails silently rejected or flagged as invalid by your service.

Commenters on Hacker News also flagged a practical reason all this matters: relay domains are a favourite target for spam filters and fraud-detection systems, which sometimes block entire domains known to issue disposable addresses. Splitting the two features across separate domains, rather than merging them, arguably makes both a bit more resilient — one domain doesn’t tank the reputation of the other.

What to do about it

For everyday users, there’s genuinely nothing to do — check the claim yourself if you like by looking at an existing masked address, it’ll still be on icloud.com and will carry on working.

For developers, the actionable step is concrete and time-bound: update allowlists and validation logic to accept both privaterelay.appleid.com and private.icloud.com before the new domain starts appearing “later this year,” a date Apple hasn’t pinned down more precisely.

The takeaway

This is a narrower, more technical story than the headline might suggest — a plumbing change for one Apple sign-in feature, and a reversal that spares another. No existing addresses break, no user action is required, and the only people with actual homework are the developers integrating Apple’s login system.