HN Debrief

Apple is about to make Hide My Email useless

  • Privacy
  • Security
  • Infrastructure
  • Consumer Tech

The post argues that Apple is weakening Hide My Email by moving newly generated aliases from plain @icloud.com addresses to the clearly marked @private.icloud.com subdomain. Under the old setup, an alias looked like a normal iCloud mailbox, so a site that wanted to block disposable or privacy-preserving email had to risk blocking regular Apple users too. With the new subdomain, any service can reject Hide My Email with a single domain rule. Existing aliases stay active on the legacy domains, so the immediate damage is to future alias creation rather than today’s logins.

If email aliasing is part of your privacy or account hygiene, do not depend on a platform-managed alias system you cannot migrate. Move important accounts toward a custom domain or an alias provider with exportable setup, and expect more services to treat privacy-preserving email addresses as abuse risk.

Discussion mood

Strongly negative toward Apple. People saw this as an unnecessary privacy regression and another form of ecosystem lock-in, with extra frustration that sites already over-block aliases and Apple just handed them a cleaner switch to do more of it.

Key insights

  1. 01

    Alias blocking is often fraud scoring

    For payments and other high-abuse categories, rejecting relay or alias domains is not mainly about marketing. It is a cheap early filter for account farms before a business pays for heavier identity checks like KYC. That framing does not make the practice consumer-friendly, but it explains why blocks keep spreading even when the email address is perfectly valid and deliverable. It also exposes the weakness of the tactic. Sophisticated fraudsters can generate mainstream Gmail or Outlook accounts at scale, so the main effect is more friction for privacy-conscious legitimate users than a hard stop for abuse.

    If you run a high-risk signup funnel, treat alias-domain blocks as a blunt cost-control layer, not proof of identity. If you are a user, expect privacy-preserving email to trigger risk systems anywhere a service is trying to reduce verification cost.

      Attribution:
    • hamdingers #1
    • iamnothere #1 #2
    • FireBeyond #1
  2. 02

    Owning the domain lowers migration risk

    A custom domain with catch-all forwarding gives you the core benefit people actually want from Hide My Email, which is one address per service without depending on one vendor's namespace. That setup is not magic. You still need records, mail hygiene, and sometimes workarounds for sites with bad validation. But it changes the failure mode from "Apple changed the product" to "I can repoint my domain and keep the addresses." That is a much better place to be if aliases are tied to hundreds of accounts.

    Use provider-managed aliases only for disposable accounts. For anything important, put aliases behind a domain you control so you can switch providers without breaking logins.

      Attribution:
    • treesknees #1
    • Hnrobert42 #1
    • vitally3643 #1
    • jedberg #1
  3. 03

    Bad email validation is a bigger problem than policy

    A surprising amount of breakage comes from junk assumptions in signup systems, not thoughtful anti-privacy rules. Examples included forms that reject short or unusual TLDs, services that silently strip subdomains, and allowlists that block perfectly normal hosted mail providers like Fastmail. That matters because Apple moving to @private.icloud.com does not just help intentional blockers. It also creates a string that every brittle validator and cargo-cult blocklist can target by default.

    If you build signup flows, test them against subdomains, modern TLDs, hosted domains, and alias providers. If you rely on aliases, keep a fallback address ready because many failures will be accidental, not announced.

      Attribution:
    • cube00 #1
    • ocdtrekkie #1
    • BiteCode_dev #1
    • toast0 #1
  4. 04

    Aliases expose weak account design

    Support problems around Hide My Email came from apps treating the email address as the user’s memorable identity instead of as a transport channel. People forget which relay address they used, create duplicate accounts, and then blame the app when data appears missing. The useful lesson is not that aliases are bad. It is that products built around email-as-username age badly once users have multiple addresses, SSO, and privacy relays in the mix.

    Do not assume a customer will know or remember the email they signed up with. Build recovery around usernames, linked identities, or explicit account management instead of making email do every job.

      Attribution:
    • x0x0 #1
    • trollbridge #1
    • JoblessWonder #1
    • weakened_malloc #1
  5. 05

    Apple lock-in is operational, not technical

    Several people pointed out that cancelling iCloud+ does not immediately kill existing aliases. You just lose the ability to create new ones. That sounds mild until you realize it still leaves you dependent on Apple preserving old forwarding forever. The problem is not instant account breakage. It is that a basic account primitive now lives in a service you cannot port or regenerate elsewhere.

    Watch for dependencies that survive cancellation but cannot be recreated outside the vendor. Those are easy to underestimate and expensive to unwind later.

      Attribution:
    • weberer #1
    • KomoD #1
    • Barbing #1

Against the grain

  1. 01

    The feature is degraded, not dead

    Calling Hide My Email "useless" overstates it. For low-trust sites, many people were already using throwaway addresses or did not care if signup failed. The real value of Apple's aliases is on sites you do want mail from but do not fully trust long term. Those businesses may have little reason to block a paid Apple relay domain, so the change does not erase the feature overnight.

    Do not panic-migrate every alias at once. Separate critical accounts from casual ones and watch where rejections actually show up before paying the migration cost everywhere.

      Attribution:
    • frollogaston #1 #2
    • deepfriedbits #1
  2. 02

    Determined blockers already had enough signal

    Apple's old aliases were not perfectly hidden. Some had recognizable random patterns and some sites already blocked them. Moving to a dedicated subdomain makes blocking cheaper and broader, but it does not create the anti-alias behavior from scratch. Anyone assuming @icloud.com aliases were safely indistinguishable was relying on obscurity more than on a durable guarantee.

    Assume any alias scheme can eventually be fingerprinted. Choose systems based on portability and damage containment, not on the hope that detectors will stay lazy.

      Attribution:
    • Cider9986 #1
    • tehwebguy #1
    • SXX #1

In plain english

Fastmail ↩
A paid email provider that offers hosted mail and alias features, including masked email integration with password managers.
Hide My Email ↩
An Apple feature that creates random email aliases which forward to your real inbox, so you do not have to give sites your main address.
iCloud+ ↩
Apple's paid iCloud subscription tier that includes extra storage and features like Hide My Email.
KYC ↩
Know Your Customer, identity verification checks used by financial and regulated businesses to confirm who a user is.
SimpleLogin ↩
An email alias service, now owned by Proton, that creates forwarding addresses and can reply through them.
SSO ↩
Single sign-on, a login method where one account from a provider like Apple or Google is used to access other services.

Reference links

Apple documentation and policy

Alias providers and tools

Email standards and reference material

  • RFC 5233
    Referenced to explain that plus addressing is part of the email standard, not a Gmail-specific privacy feature.
  • Plain text version of RFC 5233
    Shared as an alternate plain text view of the same RFC.

Coverage of the Apple change