Apple's email-hiding feature leaked real addresses for over a year

Apple’s Hide My Email feature exists to do one specific thing: give people a disposable, forwarding-only address so they never have to hand out their real one. For more than a year, it had a hole in exactly that promise — if a message sent to someone’s hidden alias bounced as spam, the recipient’s real underlying address could end up exposed in the sending server’s own mail logs. The recipient would never know it happened, because a bounced message never reaches an inbox for anyone to notice. Apple shipped a server-side fix on July 3, 2026, days after the issue went public, and is now facing a proposed class action alleging the company knew and sat on it.

What actually happened

A security researcher reported the flaw in mid-2025. Apple told the researcher it was resolved by March 2026 — but independent testing kept finding it exploitable well past that claim, through early July 2026, when the story went public and Apple issued an actual patch two days later. The lawsuit filed in the Northern District of California alleges Apple continued marketing Hide My Email as a strong privacy control the entire time it knew about the gap, and is seeking damages on behalf of affected users.

Why this is relevant even if you’ve never touched Hide My Email

This isn’t really a story about one Apple feature. It’s a clean illustration of a risk that applies to anyone who sends bulk mail and handles bounces as a matter of routine: metadata that leaks through a delivery-status notification is just as real a privacy exposure as data that leaks through the message itself. Cold-email senders think about compliance almost entirely in terms of what’s in the send — consent basis, opt-out links, content — and much less in terms of what comes back. A bounce, a delivery status notification, a spam-complaint feedback loop report: all of these can carry more than the “delivered/failed” signal they’re nominally for, and this bug is a specific, documented case of exactly that happening at scale, to a company whose entire feature was built to prevent it.

There’s a practical angle for anyone building or buying a contact list, too. If a bounce or delivery log from a privacy-relay address (Apple’s own relay domains, or similar services from other providers) ever surfaces a “real” address behind an alias, that address did not come from a legitimate opt-in — it came from a bug. Treating it as a usable contact rather than what it actually is — leaked data from someone who deliberately chose not to give you their real address — is both an ethical problem and, depending on jurisdiction, a legal one under data minimization principles that most privacy law already encodes.

The part that took a year is the actual lesson

The technical bug is almost the less interesting half of this story. The part worth sitting with is the gap between “reported” and “actually fixed”: researchers flagged it in mid-2025, Apple told them it was resolved by March 2026, and independent testing kept finding it exploitable for months after that claim, until public reporting forced a real patch within days. That sequence — a vendor asserting a fix that isn’t actually complete, with no independent way for the person who reported it to verify the claim — is a pattern that shows up constantly in security disclosure generally, and it’s exactly why “we fixed it” from any vendor, including the platforms your own sending infrastructure depends on, is worth treating as a claim to verify rather than a fact to accept. If you operate a mailbox, a sending domain, or any system that handles other people’s contact information, the operating assumption should be the same one this bug punished Apple for violating: closed tickets and public statements are not the same thing as an independently confirmed fix.

What to actually do with this

• Audit what your own bounce and DSN handling logs, not just what your send content discloses. If your platform stores full bounce message bodies indefinitely, that’s a retention decision worth revisiting on its own privacy-risk merits, independent of this specific bug.
• Never “correct” a privacy-relay address into a real one, even if a bounce hands you the means to. Stale or accidentally-surfaced data is a compliance risk before it’s a data-quality one — the fact that you technically could reach someone’s real inbox doesn’t mean you have a lawful basis to.
• Remember that legacy bugs like this compound over time, not just at disclosure. The same pattern — a flaw known for a long stretch before it’s actually fixed — is worth keeping in mind any time an old, unglamorous vulnerability finally gets patched; the exposure window is usually much longer than the headline date suggests.
• If you use email verification as part of your list-building process, prefer a verification step that never has to actually deliver-and-bounce a message to find out an address is bad — a real-time syntax, domain, and mailbox check avoids generating the exact bounce artifacts this whole story is about.

Frequently asked questions

Does this affect all Apple Hide My Email addresses, or only some?+

Reporting describes the exposure as tied to the bounce-handling path specifically — a message to a hidden alias that bounced as spam or otherwise failed. Apple's July 3, 2026 patch was applied server-side, and post-fix guidance from privacy researchers suggested treating any alias created before roughly July 7, 2026 as potentially having been exposed in a third-party mail provider's logs at some point.

Is this the same kind of issue as a data breach?+

It's a different mechanism — no database was stolen — but the practical effect for an affected user is similar: information they intentionally withheld ended up somewhere they didn't authorize, through a channel (bounce logs) most people never think to audit for privacy risk.

What should a cold-email sender actually do differently because of this?+

Treat delivery-status metadata with the same care as message content, and verify addresses before sending rather than relying on the bounce itself to tell you an address is bad — that second habit is exactly the pattern that created this exposure in the first place.

Where Norbelys fits

Norbelys’s approach to list hygiene is built around exactly the principle this bug violated by accident: verify before you send, rather than learning an address is bad from what comes back. Email verification runs ahead of a send, and suppression state — bounced, unsubscribed, complained — is enforced automatically across every future campaign, so a bad or leaked address doesn’t sit around waiting to be accidentally “resolved” into something it shouldn’t be.

If your current process relies on send-and-see-what-bounces as your primary data-quality signal, that’s worth fixing before it becomes your own version of this story. See Norbelys’s plans — verification and suppression enforcement are included at every tier — and start building a list that’s clean going in, not one you’re cleaning up after the fact from someone else’s bounce.