Apple’s iCloud+ Hide My Email feature creates disposable forwarding addresses, and the signal driving the current discussion is that those addresses will continue to use the icloud.com domain rather than moving to a separate one.
Key takeaways
- Hide My Email is a paid iCloud+ feature that generates random forwarding addresses so a user can sign up for services without disclosing their primary mailbox.
- The domain part of a relay address matters because many websites, anti-fraud systems and mailing tools make decisions based on the domain alone.
- The trending signal is that these relay addresses will remain on the icloud.com domain rather than being moved to a distinct, dedicated one.
- Keeping aliases on a widely used consumer domain makes them harder to filter out in bulk, which privacy advocates welcome and anti-abuse teams often resist.
- The precise wording, timing and official channel behind this development are not verified here, and readers should check Apple’s own support documentation for current behaviour.
What is actually happening with these addresses
Hide My Email, part of the paid iCloud+ tier, lets a subscriber generate a randomly composed email address that forwards messages to their real inbox. The user hands the random address to a shop, newsletter or app; the shop sees only the alias. If that alias later attracts spam or is exposed in a breach, the subscriber can deactivate it without changing their real address.
The point of contention is the right-hand side of the address — the domain. Aliases generated by this feature have used the same domain as ordinary Apple consumer mailboxes, icloud.com. That places them in the same namespace as millions of everyday personal addresses. The signal now circulating is that this will not change: the aliases stay on icloud.com rather than moving to a separate, clearly identifiable relay domain.
What is not established here is the exact form of that decision — whether it was a formal policy statement, a documentation update, a reversal of an earlier plan, or a clarification of something that was never going to change. Anyone who needs certainty should read Apple’s own current support pages rather than rely on secondary summaries.
Why this is being discussed now
Domain questions rarely reach a wide audience, but this one did because it sits at the intersection of two groups with opposing interests. Privacy-minded users track any change that would make their aliases easier to recognise. Developers, merchants and anti-fraud staff track the same change from the other side, because a dedicated relay domain would give them a single string to match against.
Interest also tends to spike whenever a large platform appears to be reconsidering the plumbing of a feature that people have already built habits around. Users who have generated dozens or hundreds of aliases over several years have an accumulated dependency: those addresses are recorded in account settings, billing systems and password managers across the web. A change to how they are structured or classified would ripple outwards in ways that are hard to predict individually.
The discussion is therefore less about a single product detail than about whether the ground under a widely used privacy tool is stable. Confirmation that it is not moving is, for many, the substance of the news.
Background a newcomer needs
Email aliasing is an old idea with several modern implementations. A relay provider issues an address it controls, accepts mail sent to it, and forwards the contents to a subscriber’s real mailbox. Replies can usually be routed back through the same relay, so the correspondent never learns the underlying address. Independent services offer this, some email hosts build it in, and Apple’s version is bundled with its paid storage tier.
Forwarding is technically delicate. Modern anti-spoofing standards — the family of mechanisms covering sender policy records, message signing and alignment policies — were designed on the assumption that mail travels directly from sender to recipient. Relaying breaks that assumption, and relay operators have to handle it carefully to avoid forwarded mail being classified as spam.
There is also a related but separate mechanism tied to Apple’s single sign-on feature, which issues private relay addresses on its own dedicated domain when a user chooses to hide their address while creating an account. The existence of two different relay paths, on different domains, is part of why the domain question generates confusion in the first place.
Who is affected and in what way
Subscribers are affected most directly. If aliases remain in the ordinary consumer namespace, they are less likely to be rejected at sign-up by sites that block known disposable-address domains. That is a practical benefit: a rejected address means an account that cannot be created.
Merchants, subscription businesses and anti-fraud teams sit on the other side. Some of them want to identify relay addresses in order to limit trial abuse, duplicate accounts or promotional fraud. A shared domain makes wholesale blocking impossible without also blocking a very large number of ordinary customers, so those teams must rely on behavioural signals instead of a domain blocklist.
Mailing list operators and marketers are affected indirectly, because deliverability and list hygiene behave differently when a share of subscribers are forwarding through a relay. Developers building sign-up flows are affected in the same way, and any code that treats a particular domain as a proxy for “throwaway account” is fragile by design.
Where informed people disagree
One camp argues that relay addresses should be indistinguishable from ordinary ones. In this view, the whole purpose of the feature is to prevent third parties from sorting users into categories, and a dedicated relay domain would hand them exactly the label they need. Blocking relay users, on this account, is a way of forcing people to give up an address they did not want to give.
The opposing view is that a distinct domain is a form of honesty. Services that provide something of value at their own cost, such as free trials, have a legitimate interest in knowing whether an address is a durable identity or a disposable one, and a clear domain lets them make that call without invasive fingerprinting.
A third strand of criticism is about concentration rather than labelling. Aliases issued by a large platform are tied to a paid subscription and to one company’s infrastructure; if either lapses, the addresses may stop working. Independent relay services and self-hosted catch-all domains offer portability that a bundled feature does not.
What this means in practice
For users, the sensible approach does not change. Treat relay aliases as convenient for newsletters, one-off purchases and services of unknown quality, and treat them with more caution for accounts that would be painful to lose, such as banking, government portals or the recovery address on a primary account. An alias that is deactivated, or that depends on a subscription remaining active, is a single point of failure for password resets.
Keep a record of which alias was issued to which service, because that mapping is what makes the feature useful after a breach: unusual mail arriving at an alias tells you which relationship leaked. Check what happens to existing aliases if the subscription lapses before relying on them for anything important, since this behaviour is defined by the provider and may change.
For anyone building sign-up systems, a domain blocklist is not a durable defence. Rate limits, payment verification and behavioural analysis are slower to implement but do not break the moment a provider changes a domain or declines to change one.
What to watch next
The clearest source of truth is the provider’s own support documentation and any developer-facing notes, which describe current behaviour rather than intent. Changes to how aliases are created, how many can exist, or what happens when a subscription ends would all be more consequential than the domain itself.
Also worth watching is whether other mail providers move towards built-in aliasing, and whether large services adjust their sign-up policies in response to relay use becoming ordinary rather than niche. On the regulatory side, data protection authorities have taken a steady interest in data minimisation, and tools that reduce the spread of a personal identifier fit that direction of travel — though no specific regulatory action on this feature is established here.
Frequently asked questions
What is iCloud+ Hide My Email?
It is a feature bundled with Apple’s paid iCloud+ tier that generates random email addresses which forward incoming mail to a subscriber’s real inbox. The user gives the random address to a website or app instead of their personal one, and can deactivate it later if it starts receiving unwanted mail. It is intended to limit how widely a primary address is shared.
Are Hide My Email addresses changing domain?
The signal behind the current discussion is that they are not: the addresses are expected to remain on the icloud.com domain rather than moving to a separate, dedicated relay domain. The exact form, timing and official wording of that development are not verified in this article, so anyone who needs certainty should consult Apple’s own current support documentation.
Why does the domain of an alias matter?
Many websites and anti-fraud systems make decisions using only the domain part of an address. If relay aliases share a domain with ordinary consumer mailboxes, they cannot be blocked in bulk without also rejecting a large number of regular customers. A dedicated relay domain, by contrast, would be trivial to filter, which is why the question attracts attention from both privacy advocates and anti-abuse teams.
Do relay addresses stop working if the subscription ends?
Aliasing bundled with a paid tier depends on that tier remaining active, and providers define what happens to existing aliases when it does not. Because this behaviour is set by the provider and can change, users should check the current terms before relying on an alias for anything critical, particularly account recovery, password resets or any address tied to a payment relationship.
Is it safe to use an alias for important accounts?
It is safer to reserve aliases for low-stakes sign-ups and to use a stable, directly controlled address for accounts that would be difficult to recover. An alias that is deactivated, misrouted or dependent on a subscription becomes a single point of failure at exactly the moment a password reset is needed. The convenience is real, but so is the dependency.
What are the alternatives to a bundled aliasing feature?
Independent relay services offer similar functionality without tying addresses to a device ecosystem, and some email hosts include aliasing directly. Users who own a domain can configure a catch-all or per-service addresses, which keeps the namespace under their own control and makes migration between providers possible. Each option involves different trade-offs in cost, effort, deliverability and long-term portability.
Sources and further reading
- Apple support and privacy documentation, for the authoritative description of how Hide My Email and iCloud+ features currently behave.
- Hacker News discussion threads, where the topic surfaced and where developers and users debated the implications for sign-up flows.
- Technical standards documentation on email authentication, for background on why forwarding and relaying interact awkwardly with anti-spoofing mechanisms.
- Consumer privacy and technology publications, for general explanations of email aliasing and comparisons between relay providers.
Surfaced from the hackernews signal “email alias domain decision”. AI-assisted draft, editorially reviewed.
