HN Debrief

Apple 'Hide My Email' vulnerability reveals peoples' real email addresses

  • Privacy
  • Security
  • Apple
  • Infrastructure

The linked post is a disclosure timeline for a bug in Apple’s Hide My Email, an iCloud+ feature that creates throwaway addresses which forward to your real inbox. According to the report, an attacker can turn one of those aliases back into the real email on the Apple ID, which is much worse than ordinary spam leakage because that address often anchors a person’s identity across Apple services and may include their real name. Apple had reportedly known for about a year without fixing it, and the exploit details were intentionally withheld because some people use the feature for personal safety.

Treat Hide My Email as a convenience alias, not a safety boundary, until Apple explains the failure mode and ships a fix. If your business or users depend on email aliasing for privacy or abuse prevention, review whether reply flows, forwarded headers, and provider-specific behavior can reveal the underlying address.

Discussion mood

Mostly negative and distrustful. People were frustrated that a privacy feature appears to leak identity at all, more frustrated that Apple has not fixed it after a long disclosure window, and many concluded the feature is fine for spam control but unsafe for anything security-sensitive.

Key insights

  1. 01

    DMARC headers can reveal your domain

    Forwarding to a personal domain can expose more than Apple likely intended. In a tested reply flow, Apple’s relay inserted an `X-DMARC-Info` header that disclosed the recipient domain behind the alias, and it also preserved enough headers to reveal the downstream provider such as Fastmail. That turns Hide My Email into a partial deanonymizer even without the full exploit from the article.

    If you use Hide My Email with a custom domain, inspect raw headers on received and replied messages now. For sensitive use cases, route aliases only to an Apple-hosted inbox or stop using the feature until Apple documents what it strips and what it keeps.

      Attribution:
    • js2 #1
  2. 02

    The exposed address may be the Apple ID

    The leak appears to resolve the alias to the email linked to the Apple ID, not merely the mailbox the alias forwards into. That is a bigger deal because the Apple ID address often doubles as an account recovery identifier and a real-world identity marker across multiple services.

    Do not assume the blast radius is limited to one inbox. If your Apple ID email is reused elsewhere, review recovery paths and consider changing which address is attached to the Apple account.

      Attribution:
    • freehorse #1
    • Dibby053 #1
  3. 03

    Reply leaks may depend on client or provider

    One hands-on test claimed that replying from iOS Mail sent the message with the real sender address visible to the recipient even though the interface showed the Hide My Email alias. Another person failed to reproduce the same behavior, which points to a narrower edge case tied to a specific provider such as Yahoo or Sonic, a client path, or both. That inconsistency makes the feature harder to trust because users cannot tell when they are in the bad path.

    Test your own setup end to end instead of trusting the Mail UI. Cover the exact combination you use in practice, including iOS versus macOS and each provider you forward to.

      Attribution:
    • jijijijij #1 #2
    • Barbing #1
  4. 04

    Apple’s mail privacy features have a pattern

    This report landed next to prior complaints that Apple’s other mail privacy controls are poorly understood or behave unpredictably, including claims that Protect Mail Activity can fail or re-enable itself. That pattern made people read this bug as part of a broader operational weakness in Apple’s email systems, not a one-off mistake.

    If you depend on Apple’s mail privacy features, audit them as separate systems instead of assuming one trust decision covers all of them. Product teams building on Apple mail flows should expect surprising edge cases and add their own checks.

      Attribution:
    • mike-cardwell #1
    • lapcat #1

Against the grain

  1. 01

    Impact is still hard to size

    Without the exploit details, it is hard to tell whether this is a universal break or an ugly corner case with effective mitigations already in place. The disclosure timeline also shows at least one alarming line about stopping new sales was sincere but more measured in the original blog context, which weakens the most dramatic reading of the report.

    Avoid overcorrecting based on vibes alone. Keep the feature for low-stakes spam control if it is useful, but separate that from whether it is safe for anonymity or safety-critical use.

      Attribution:
    • alwa #1 #2
    • tjames7000 #1
  2. 02

    Low-risk signup use may be fine

    For people who only use Hide My Email for throwaway trials and random signups, the practical risk may be acceptable even if the feature is flawed. The real damage shows up when exposing the underlying address creates safety, identity, or account recovery problems.

    Classify aliases by purpose. Keep disposable addresses for marketing junk if you want, but move anything tied to harassment risk, pseudonymity, or sensitive accounts to a more robust aliasing setup.

      Attribution:
    • Jbird2k #1
    • ezfe #1

In plain english

Apple ID ↩
The main account used to sign in to Apple services such as iCloud, the App Store, and device management.
DMARC ↩
Domain-based Message Authentication, Reporting, and Conformance, an email policy system that tells receivers how to handle messages that fail sender authentication checks.
Fastmail ↩
A commercial email hosting provider.
Hide My Email ↩
An Apple iCloud+ feature that creates disposable email aliases which forward mail to a real inbox.
iCloud+ ↩
Apple’s paid iCloud subscription tier that includes extra storage and privacy features such as Hide My Email.
Protect Mail Activity ↩
An Apple Mail privacy feature intended to reduce tracking by hiding when and where a user opens email content.
X-DMARC-Info ↩
A nonstandard email header used by some systems to record DMARC evaluation details on a message.

Reference links

Primary reporting and disclosure

Related mail privacy issues

Exploit speculation and reproductions

Alternatives and related tools

Related discussion