Apple Is Changing Your Relay Email Domain — and Backed Off Half of It

Sign in with Apple addresses move to private.icloud.com later this year. Hide My Email stays on icloud.com after Apple reversed course. Here is why.

On 24 August 2026, Apple published a developer note with an unglamorous title: "Update: New domain for Sign in with Apple." It contains one sentence that is genuinely interesting, and it is not the one about the new domain.

After further consideration and reviewing community feedback, iCloud+ Hide My Email addresses will remain on icloud.com.

That is Apple reversing a decision it announced ten weeks earlier. And the reason it reversed is a good illustration of something most people get wrong about how these privacy features actually work: for an email alias, being identifiable is the failure mode.

Key Takeaways

Sign in with Apple relay addresses are moving from privaterelay.appleid.com to private.icloud.com, starting later this year.
iCloud+ Hide My Email addresses are staying on icloud.com. Apple planned to move them in June and cancelled that in August.
Nothing you already use breaks. Existing addresses on the old domains keep working and keep forwarding.
The reversal exists because a dedicated domain is a blocklist entry. A site can reject an entire domain. It cannot reject icloud.com without rejecting every real iCloud user.
Expect phishing to exploit this. A new, unfamiliar Apple domain appearing in your inbox is exactly the kind of change attackers build campaigns around.

Three Different Things, All Called "Private"

Before anything else, this needs untangling, because the June plan made intuitive sense only if you conflate two of these — and the reason it was wrong is that they are not the same product.

When you tap "Sign in with Apple" on an app or website and choose to hide your address, Apple generates a relay address for that specific developer and forwards their mail to you. It is free with any Apple Account.

Current domain: @privaterelay.appleid.com
New domain: @private.icloud.com, for newly issued addresses, starting later this year
Managed on your Mac at System Settings → [your name] → Sign in with Apple

2. iCloud+ Hide My Email

A paid iCloud+ feature. You generate aliases yourself, for anything at all — a newsletter, a form, a shop — with a label and a note so you remember what each one was for. It is not tied to any sign-in flow.

Domain: @icloud.com — unchanged
Managed on your Mac at System Settings → [your name] → iCloud → Hide My Email
Also available inline in Safari and Mail by clicking an address field and choosing Hide My Email

3. iCloud Private Relay

Not email at all. It is a two-hop relay for Safari browsing and certain unencrypted traffic, designed to keep any single party from seeing both who you are and what you are looking at. It shares the word "relay" and nothing else. We covered a real-world failure mode of this one in iCloud Private Relay leaking your real IP address.

The confusion is not the reader's fault: both of the first two present a button labeled "Hide My Email." One gives you a privaterelay.appleid.com address, the other an icloud.com address, and Apple has never made the distinction loud. That shared label is almost certainly why unifying the domains looked tidy in June.

What Apple Said, in Both Versions

Worth reading side by side, because the change is precise.

15 June 2026:

Later this summer, Apple will unify the email domains used by Sign in with Apple and iCloud+ Hide My Email under a single, shared domain: private.icloud.com.

New addresses generated for both features will be issued on the new domain. For example:

Sign in with Apple addresses, previously issued on privaterelay.appleid.com, will be issued on private.icloud.com.

iCloud+ Hide My Email addresses, previously issued on icloud.com, will be issued on private.icloud.com.

Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.

24 August 2026:

Starting later this year, 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.

After further consideration and reviewing community feedback, iCloud+ Hide My Email addresses will remain on icloud.com.

Two changes between them. Hide My Email is out of the migration. And the timeline moved from "later this summer" to "starting later this year" — the original schedule has already slipped past, which is worth noting if you are planning around it.

Why Keeping Hide My Email on icloud.com Is the Right Call

Here is the mechanism, and it is worth understanding because it generalizes to every alias service.

An email alias protects you only if the recipient cannot cheaply tell it is an alias. The moment a service can identify alias addresses, it can refuse them — and services have strong incentives to refuse them, because an alias is a customer they cannot re-identify, cannot match against a data broker's records, and cannot keep reaching if you burn the address.

John Gruber put the user's side of it directly when the reversal was announced:

we often want to use such hidden email addresses on sites that would prefer to block those addresses and try to force us to use our "real" addresses

A dedicated private.icloud.com domain is a single string. Any signup form could reject it in one line of validation. Every alias Apple had ever issued would become simultaneously worthless at any site that added that line.

icloud.com cannot be treated that way. It is the domain hundreds of millions of people use for their ordinary personal email. A service that blocks icloud.com to stop aliases blocks a large share of its actual customers. Hide My Email's protection is not cryptographic — it is that the aliases are hiding among real addresses. Moving them to a distinct domain would have removed the hiding place.

That is what Apple appears to have concluded, and it is the correct conclusion. It is also a rare example of a shipped plan being pulled back on a privacy argument rather than a technical one.

It would be easy to finish that argument and conclude Apple has left Sign in with Apple users exposed. That is not right, and it is worth being precise about why.

Sign in with Apple relay addresses were already on a dedicated, obviously identifiable domain. privaterelay.appleid.com announces itself. Any service that wanted to reject them has been able to since 2019. Moving to private.icloud.com is a lateral move on that axis — a different identifiable domain, not a newly identifiable one.

There is also a structural reason the exposure matters less. A Sign in with Apple relay address is not something you type into a form. It is issued as part of an authentication flow that the site chose to offer. A site that does not want relay addresses does not implement Sign in with Apple. The blocking scenario that makes Hide My Email fragile does not really arise.

So the honest summary is: Apple protected the feature that needed protecting and moved the one that did not. The June plan would have damaged one of them, and Apple caught it.

Comparing Apple's private email systems

What Actually Changes For You

For most people, very little — but the details are worth knowing before they surprise you.

Your existing addresses do not change. Every privaterelay.appleid.com address you already have keeps working and keeps forwarding. Apple says so explicitly in both announcements. You do not need to update anything, re-register anywhere, or migrate accounts.

New sign-ins will produce a domain you have not seen before. After the change, using Sign in with Apple on a new service issues an address at private.icloud.com. If you keep records of which alias went to which service, expect two domains in that list from here on.

A small number of sites will reject the new domain. Any service whose signup validation, allowlist, or anti-abuse rule hardcodes privaterelay.appleid.com will not recognize private.icloud.com until it is updated. Apple's note is explicitly asking developers to accept both. Not all of them will read it.

Corporate mail filtering may hold messages. If you use Sign in with Apple for anything work-adjacent and your organization filters by sender or recipient domain, a brand-new domain can land in quarantine.

The Phishing Window

This is the part with a real security consequence, and it is the part nobody is writing about.

Apple published this to developers. There is no consumer-facing announcement, no notification in Settings, no email to users. The first time most people encounter private.icloud.com will be when it simply appears — in a From line, in an account settings page, in a password manager entry.

An unfamiliar domain that genuinely belongs to Apple, appearing without warning, during a publicized transition, is close to ideal conditions for a phishing campaign. The messages practically write themselves: your Apple relay address is being migrated, confirm your account to avoid losing access to services you signed in with.

Some rules that hold regardless of this change:

Apple does not require you to do anything for this migration. Any message asking you to confirm, verify, migrate, or re-authenticate a relay address is fraudulent. There is no user-facing step, because there is no user-facing step.
Never act on a link in an email about your Apple Account. Open System Settings yourself and look. If a change is real, it is visible there.
Check where a link actually goes. private.icloud.com is Apple. private-icloud.com, privateicloud.com, private.icloud.com.example.net, and icloud-private.com are not. Attackers register lookalikes for exactly this kind of moment.
A password prompt you did not initiate is the signal. Legitimate macOS password prompts follow an action you just took. We covered how convincingly this can be faked in the fake Mac crash report password prompt.

If you want the broader hardening pass, our Mac security and privacy guide covers the surrounding settings.

Auditing What You Actually Have

A good moment to look, since most people have never checked.

Which apps use Sign in with Apple:

On a Mac, open System Settings, click your name at the top of the sidebar, then Sign in with Apple. You get every app and site where you used it, and you can stop using Sign in with Apple for any of them individually.

Read that list carefully before revoking anything. Turning off Sign in with Apple for a service breaks the relay address, which means the service can no longer reach you — including for password resets. If you have no other login method registered there, you can lock yourself out. Set up an alternative sign-in first.

Which Hide My Email aliases exist:

System Settings → [your name] → iCloud → Hide My Email. Each entry shows its label, its note, and the address it forwards to. You can deactivate an alias you no longer want, which stops delivery without deleting the record of what it was for.

Where mail is forwarded:

Same pane. If you have several personal addresses on your Apple Account, one of them is the forwarding target for all your aliases. Confirm it is one you still read — a forwarding address you have abandoned is a silent failure that only surfaces when you need an account recovery message.

Two things worth doing while you are in there

Label your aliases properly. The note field exists so that in two years you can tell what an alias was for. An unlabelled alias is an address you will be afraid to deactivate.

Check that your recovery paths do not depend on a relay. If a critical account's only contact address is a Sign in with Apple relay, and you later revoke that app's access, recovery for that account goes with it. Keep at least one path that does not route through a relay you might turn off.

Auditing Sign in with Apple and Hide My Email

For Developers and Administrators

If you operate anything that touches email addresses, there is concrete work here. Apple's ask:

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.

Specifically:

Accept both domains. Not a replacement — both. Existing addresses on privaterelay.appleid.com remain valid indefinitely.
Find the hardcoded strings. Grep your codebase and your configuration for privaterelay.appleid.com. It turns up in validation regexes, anti-fraud rules, analytics segmentation, deliverability allowlists, and support tooling.
Check your email service provider's rules. Domain-based routing, suppression lists, and reputation rules live outside your repository and are the easiest place for this to be missed.
Do not build new blocking on private.icloud.com. Beyond being hostile to your own users, an address you reject at signup is a customer you did not acquire, and Sign in with Apple is an authentication method your app chose to offer.
Test the whole flow. Signup, verification email, password reset, and account recovery. A validation rule that accepts the address at registration but rejects it at password reset is a genuinely painful bug, and it is the common shape of this failure.

For administrators: if you filter inbound mail by domain, add private.icloud.com to whatever list privaterelay.appleid.com is already on, before your users start reporting missing messages rather than after.

What the Relay Actually Hides

Worth being precise about, because people extend their trust in these features further than the features go.

What the developer does not get: your real email address. They get a relay address and can send mail to it, which Apple forwards. If you revoke access, the relay stops and their address for you becomes dead.

What the developer does get:

A stable identifier for you within their app. Sign in with Apple issues a per-developer user identifier that persists across sessions and devices, which is what lets them recognize you as a returning user. It is scoped to that developer — the same Apple Account produces a different identifier at a different developer, so two apps cannot join their records on it.
Your name, if you chose to share it, and you can edit it at the point of sign-in.
Everything you subsequently tell them. The relay covers your address, not your behavior. If you type your real name into a profile field, you have handed it over.
Whatever their analytics collect. Device fingerprinting, IP address, and advertising identifiers are entirely outside this feature's scope.

What Apple gets: the mail passes through Apple's servers to be forwarded. Apple states it does not read or retain the contents beyond what is needed to deliver, but the relay is by construction a path through Apple, not around it.

The clean way to think about it: a relay address is a revocable channel, not anonymity. It solves "this company sold my address to a data broker and now I cannot stop the mail." It does not solve "this company knows who I am."

That is a genuinely valuable thing to solve, and the revocability is the underrated half — being able to cut off one company's ability to reach you, without changing your address anywhere else, is something an ordinary mailbox has never offered.

How This Compares to Third-Party Alias Services

Apple is not the only option, and the comparison illuminates the blockability argument.

Dedicated alias services — SimpleLogin, AnonAddy, and similar — give you unlimited aliases, usually on domains shared with all their other users. That shared domain is exactly the blocklist target the June plan would have created for Hide My Email, and it is why these services are widely rejected by signup forms. The better ones let you bring your own domain, which restores unblockability at the cost of registering and paying for a domain, and of that domain being uniquely yours if anyone correlates it.

Fastmail and similar providers offer masked addresses on your own domain or theirs, with the same trade-off.

Apple's iCloud+ Hide My Email is unusual precisely because of what just got preserved: its aliases live on icloud.com, alongside hundreds of millions of ordinary users. It is the only major alias service whose addresses are not distinguishable from real ones. That is a structural advantage no competitor can replicate, because no competitor operates a consumer mail domain at that scale.

The limitations are real. Apple's aliases forward to one address, there is no send-as from an alias outside Apple Mail on Apple devices, and you cannot use your own domain. If you want fine-grained routing and replies from arbitrary clients, a dedicated service does more. If you want an alias that simply gets accepted everywhere, Apple's is the strongest option available — and it just stayed that way.

A Short History, and Why the Old Domain Was Always Odd

Sign in with Apple launched in 2019, and Apple's App Store review guidelines required apps offering third-party sign-in options to offer it as well — which is why it appeared nearly everywhere at once rather than gradually. The private email relay was its most distinctive feature: other sign-in providers hand the developer your address, and Apple offered not to.

The address it handed out instead was @privaterelay.appleid.com. That is a mouthful, it is on a domain most users have never otherwise encountered, and it announces its own nature. It made sense from Apple's side — appleid.com was where account infrastructure lived — and from a user's side it has always looked slightly like something a phishing kit would invent.

Consolidating onto private.icloud.com fixes that. icloud.com is a domain ordinary people recognize, and a subdomain of it reads as legitimate in a way that privaterelay.appleid.com never quite managed. For the sign-in relay, that is a straightforward improvement, and it is presumably the reasoning behind the whole exercise.

The June plan then over-applied it. Consolidation is good for the address that was already conspicuous. It was actively harmful for the one whose value came from being inconspicuous. That the fix took ten weeks and required public pushback is a small case study in how a change that improves one product can quietly degrade another that shares a name and a button.

Troubleshooting Common Issues

A website rejects my new Apple relay address as invalid

Problem: The site's email validation does not recognize private.icloud.com yet.

Solution: Report it to the site — it is their bug and Apple has published the fix. In the meantime, an iCloud+ Hide My Email alias on icloud.com will be accepted, since that domain is not changing and is indistinguishable from any ordinary iCloud address. That is precisely the property Apple preserved.

Mail from a service I signed into with Apple stopped arriving

Problem: Several possibilities: the forwarding address on your Apple Account is one you no longer read, you revoked Sign in with Apple for that app, or your mail provider is filtering an unfamiliar domain.

Solution: Check System Settings → [your name] → Sign in with Apple to confirm the app is still active, then verify your forwarding address under Hide My Email. Then check your spam and quarantine folders for the new domain.

Problem: Revoking access invalidates the relay address, and if that address was the account's only contact method, password reset has nowhere to go.

Solution: Contact the service's support directly and explain — this is a known situation and most have a manual path. To avoid it, register an alternative sign-in method before revoking anything.

I received an email about my Apple relay address changing

Problem: Apple is not sending users email about this. The migration requires nothing from you.

Solution: Treat it as phishing. Do not click. Verify anything you are worried about by opening System Settings yourself.

I cannot find Hide My Email in Settings

Problem: It is an iCloud+ feature and requires a paid iCloud+ or Apple One subscription. Without one, only the free Sign in with Apple relay is available.

Solution: Confirm your subscription under System Settings → [your name] → iCloud. If you are not subscribed, Sign in with Apple's hide-address option still works, at no cost — it is just scoped to sign-in flows rather than usable anywhere.

FAQ

Do I need to do anything?

No. Existing addresses keep working, and the change applies only to newly issued Sign in with Apple addresses. There is no user-facing migration step, which is exactly why any message claiming otherwise is fraudulent.

Will my old privaterelay.appleid.com addresses stop working?

No. Apple states in both announcements that existing addresses continue to work and forward without interruption. Apple has announced no end date for them.

Why did Apple change its mind about Hide My Email?

Apple's own wording is "after further consideration and reviewing community feedback." The substance of that feedback was that a dedicated domain makes alias addresses trivially blockable, which defeats the feature. Keeping them on icloud.com means they are indistinguishable from ordinary iCloud addresses.

No, though both present a button with that name. Hide My Email is a paid iCloud+ feature producing icloud.com aliases you create for any purpose. Sign in with Apple's relay is free, tied to a specific app, and is the one moving to private.icloud.com.

When exactly does the change happen?

Apple says "starting later this year." The June announcement said "later this summer," so the schedule has already moved once. No specific date has been published.

Does this affect iCloud Private Relay?

No. iCloud Private Relay is a network privacy feature for Safari browsing and has nothing to do with email addresses, despite the shared word.

Should I switch my important accounts to Hide My Email instead?

For accounts that matter, the more useful question is whether your recovery path survives the alias being turned off. Both systems are solid. The risk in both is the same: if an alias is an account's only contact method and you later deactivate it, recovery becomes difficult. Keep a second path on anything you cannot afford to lose.

Conclusion

The headline change is small and needs nothing from you: new Sign in with Apple addresses will arrive on private.icloud.com, old ones keep working, and the only people with real work to do are developers who hardcoded a domain string somewhere.

The part worth remembering is the part Apple undid. A privacy feature that everyone can identify is not a privacy feature — and Apple's June plan, which looked like sensible consolidation, would have taken an alias system whose entire protection is that it blends in with ordinary mail and given it a label anyone could filter on. That got caught, publicly, and reversed in ten weeks. Which is both a good outcome and a reminder that "unify these two things that share a button" is a design instinct that deserves a second look when one of them depends on being unremarkable.

Meanwhile: Apple will not email you about this. Anyone who does is not Apple.