How Apple's Hide My Email exploit worked and why you're still at risk

By Ben and Tyler, Co-founders

20 min read

The vulnerability has been fixed as of July 7, 2026, but the exploit was simple, and hidden email addresses may still be in third-party logs.

We've updated this guide with more details following Apple's fix. You can see our original report here.

Apple's Hide My Email service is used by iCloud+ customers to send and receive emails while keeping their personal, permanent email address private. The service generates random, unique email addresses to act as intermediaries between your actual email address and the people you're emailing. For example, you could be given the email address random.email.22@icloud.com to hide your real email address, realname@example.com. People use Hide My Email addresses to sign up for accounts and communicate while maintaining privacy and anonymity.

The vulnerability

When an email sent to a Hide My Email address was rejected as spam, the rejection error message returned by iCloud's email servers included the meant-to-be-hidden email address in 100% of our limited tests. Other types of rejections were also problematic, though probably less common. As of July 7, 2026, the vulnerabilities are fixed.

But there's still a problem: Email rejection reasons are saved in third-party logs outside of Apple's control. For example, we use Mailgun to send emails to our customers. It saves email delivery and rejection logs for troubleshooting. We happen to save logs for only a few days, but some senders maintain logs for years.

Email addresses may have leaked more than expected given typical spam rejection rates. For the emails we were sending, emails forwarded via Hide My Email bounced (i.e., were rejected with an error message) at much higher rates.

This is how the leaked email addresses showed up in our logs:

Screenshot of Mailgun bounce logs. The JSON object's 'delivery-status' 'description' field includes the meant-to-be-hidden email address, redacated for privacy. The 'recipient' field indicates that the bounced email was originally sent to an @icloud.com email address, also redacted for privacy.

view full size

Hidden email addresses were leaked for a variety of mail hosts. We saw hidden email addresses for Gmail, Yahoo, Outlook, and Proton domains, among others.

The exploit

Coming up with a way to reliably exploit the vulnerability was straightforward after observing the issue. Here are the instructions we sent to Apple on June 13, 2025:

Send a spammy email to the Hide My Email address. Or send an email that doesn't strike you as spammy and hope that the email is rejected as spam anyway.

If the email is rejected SMTP code 550, look at the long description field and observe the real email address. For example, the message looks like the following: This is a system-generated message to inform you that your email could not be delivered to one or more recipients. Details of the email and the error are as follows: <redacted hidden email@gmail.com>: host 127.0.0.1[127.0.0.1] said: 550 5.7.1 message content rejected due to spam; if you feel that your email was rejected in error, please forward a copy to icloudadmin@apple.com (in reply to end of DATA command)

If the email wasn't rejected by the email server as spam, try again with a spammier email or different email. I think that once you've identified a message that's rejected as spam consistently, you can keep using it.

In practice, we usually didn't need to try with multiple emails to trigger the rejection. We could just open up our personal email's spam folder, and the first email we copied and sent would cause the rejection. Here's a typical example:

😈 Open this if you want her tonight

We recently learned that there are more reliable ways to trigger these kinds of bounces for most mail servers like the EICAR anti-malware test file, probably well-known to people more familiar with email handling.

We also noticed that at least one other kind of error could leak hidden email addresses: If someone deleted the hidden email address that their Hide My Email addresses forwarded to, the bounce message contained the hidden email address. We don't think it was possible to exploit widely.

There are other kinds of bounces, but we don't know if they were leaking hidden email addresses or were exploitable. Apple should be able to determine which other kinds of bounces were also leaking email addresses.

After news of the vulnerabilities was made public, some people online indicated having years-old knowledge of exploits based on other kinds of bounces:

Why we're sharing the exploit details

People are still at risk if leaked data has been retained anywhere.

Public knowledge of the exploit also helps other present and future email aliasing services avoid making the same mistake.

Why it matters

While many people use Hide My Email only for spam prevention, some rely on it for personal safety or sensitive privacy matters. Given the number of iCloud+ subscribers, there are probably people relying on Hide My Email's privacy claims to communicate with past domestic abusers, whistleblow at work or against an oppressive government, or coordinate cryptocurrency transactions. Lower-stakes situations are widespread. People register for social media or forums to talk about sensitive or controversial topics anonymously. People applying for jobs avoid sharing their real name to prevent unconscious bias. In theory, Hide My Email is a powerful tool for preventing third parties from associating your disparate accounts and communications in all sorts of situations.

Whether anyone was actively exploiting the vulnerabilities or not, any leaked data that was sent to third parties could still be stored in their email-related logs. It's not unusual to save logs for months or years, or to have no log retention policy at all, so that logs are kept indefinitely. Many businesses also use third-party email delivery services, which could have access to the leaked emails as well. Now that the exploit details are public, it's trivial for mail senders to review old email transfer logs to find previously-leaked hidden email addresses. Statutory requirements for the data sharing disclosures in privacy policies and for data breach notifications to regulators and to consumers may be relevant.

We also think it's wrong to sell a known-faulty product. Mistakes happen, but once Apple knew Hide My Email was leaking email addresses and was easily exploitable, they could have limited the damage by limiting the creation of new Hide My Email addresses or by disclosing the existence of vulnerabilities. There are many alternative email aliasing services that are easy to use, so anyone requiring an aliasing service still would have been able to use one. We don't know if Apple realized that leaked email addresses were being stored in third party logs before our May, 2026 message to them. In our opinion, at that point, the severity of the problem necessitated at least a warning to Hide My Email customers — a warning that only Apple could deliver with maximum effectiveness. Our disclosure has probably reached only a small fraction of Hide My Email users.

Timeline

This timeline doesn't include every detail. Some parts have been redacted for privacy.

June 11, 2025: We discovered and reported the issue.
We noticed that an unusual number of emails being sent to our customers were bouncing. Normal emails to @icloud.com email addresses were being rejected as spam. We noticed that the rejection reasons included email addresses different from our customers' @icloud.com addresses. We recognized that they were Hide My Email addresses and suspected that meant-to-be-hidden addresses were being leaked.

We checked with a customer whose emails were bouncing and the customer confirmed that the address we were seeing was the meant-to-be-hidden address. We reported the discovery of the problem to Apple.

Because the exposure in non-delivery reports was so easy to see, we thought it might be a known limitation in the design of Hide My Email. We asked Apple, and they confirmed that Hide My Email is not intended by design to allow discovery of the hidden address and asked for more details.
June 13, 2025: We devised a reproducible exploit and submitted a detailed report to Apple. In short: Send a spammy email, hope it bounces, find the hidden email address in the error details. If it doesn't bounce, try something spammier. We also made sure to point out that, while we observed this for a particular kind of rejection, it shouldn't happen for any kind of rejection.
I'd expect that the email address shouldn't ever be included in anything like this. I'm not sure whether there are other types of messages that could be sent by the mail server that could also expose the hidden email address. You might want to make sure that every possible message cannot contain the hidden email address.
June 20, 2025: We submitted more message IDs associated with leaked email addresses, hoping it would help Apple troubleshoot.
July 9, 2025: Still facing bounce issues, we reviewed our bounce logs again. We noticed a similar but different problem: A customer had signed up for EasyOptOuts using Hide My Email and then deleted the hidden email address. When we emailed their @icloud.com address, the bounce message included the hidden email address. We reported the additional vulnerability to Apple.
July 14, 2025: Apple sent their first message acknowledging that the vulnerabilities were under review.
March 3, 2026: Apple reported that the vulnerabilities were fixed and asked us to verify.
March 19, 2026: Using the reproduction instructions from our initial report, we determined that the vulnerability hadn't been fixed. We picked a spam email from our own spam folders and emailed it to a test Hide My Email address. It bounced and the error message included the hidden email address. We provided the email recipient, subject, and body to Apple.
March 20, 2026: We realized that some parts of error messages expose the domain used by a hidden email address even if they don't expose the full email address. We reported the issue to Apple: ... it's probably best to make sure that mail host information is also hidden, or for it to be clearly disclosed that only email usernames (i.e. the part before the @) will be hidden despite hosts being discoverable. For example, one of the previous examples included mail.protonmail.ch[redacted]. I think most people would expect the fact that they're using protonmail to be hidden when using Hide My Email.
March 24, 2026: Apple replied: Thank you for the additional information. We are reviewing it and will follow up if we have any questions or need additional details.
May 21, 2026: We asked for an update and suggested that Apple could limit exposure by limiting new usage of Hide My Email:
Are there any updates? We just tested again and it appears the problem still exists. It's been almost a year since the issue was reported, and in that time, everyone purchasing access to Hide My Email has unknowingly been buying a product that Apple knows is faulty. People relying on Hide My Email's privacy claims to protect their own safety are at risk.

We are still investigating this issue. To avoid placing our customers at risk, we would appreciate you not disclosing this information until our investigation is complete.

We appreciate your assistance in helping us to maintain and improve the security of our products.

It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?
May 22, 2026: We realized that the vulnerabilities may have greater severity and scope than we thought initially and notified Apple: We happen to save our SMTP logs for only a few days, but many senders probably save them for longer. Even if the issue is fixed going forward, people's meant-to-be-hidden addresses will remain in logs all over the place.
May 24, 2026: Apple replied with We are currently working on it and anticipate providing an update soon. Thank you for your patience!
May 24, 2026: Because Apple hadn't addressed our latest concerns about retention, we followed up to re-emphasize the issue:

... it seems especially-important to disclose this to people using Hide My Email ASAP because fixing the issue won't undo the fact that their email addresses are being exposed and kept in third-party logs. As soon as this issue is disclosed, even if it's after it's fixed, anyone with SMTP logs will be able to review their old logs to find leaked email addresses. It won't matter that the bug has been fixed. Even if the issue is never disclosed, anyone could eventually notice and take advantage of the issue by reviewing their old logs despite never having noticed while it was ongoing.

Because I'm not sure my point was clear previously: Does Apple understand that email addresses are being stored in persistent third-party logs, and that fixing the problem won't remove the breached data from third parties' logs? Every day that people aren't notified and are allowed to keep creating new Hide My Email addresses, the breach grows. Please let me know if it seems like I'm mistaken, or if you think I'm mistaken about the severity being greater than we initially realized.
May 26, 2026: Apple replied: We are planning to address this issue in a future security update, expected in the coming weeks. To avoid placing our users at risk, we would appreciate you not disclosing this information until the necessary updates are available.
June 29, 2026: Hoping to make people aware of the risk, we disclosed the vulnerability to Joseph Cox at 404 Media. Joseph contacted Apple for comment.
June 30, 2026: Apple again reported that the vulnerabilities were fixed and asked us to verify. We determined that the vulnerabilities hadn't been fixed.
We asked how Apple was testing because we figured it must be different from the way we were testing. Apple said it was running the command swaks --server redacted:25 --tls --ehlo redacted --from redacted --to redacted --quit-after RCPT 2>&1 | grep 'RCPT TO' and was not observing the hidden email address.

We had some back-and-forth:

I'm not familiar with swaks or very familiar with SMTP at all, so I don't know exactly what that command does or what it's meant to show. It doesn't look like it has a spammy email message, though. Did you leave that part out? Or do you think that the issue should be reproducible even without it? ... We sent the email with a spammy subject and body, like we've always done when testing whether the issue has been fixed yet. We've never tested for the issue without spammy content being part of the email we send.

We've been able to reproduce the behavior on our side, and we're actively working on building and deploying a fix. We don't have a timeline to share at this point, but we'll follow up as soon as we have a meaningful update.

We replied to reiterate that there's not just one exact type of rejection that leaks hidden email addresses. There could be a variety of vulnerabilities:

I guess that time it was 552-5.7.0 instead of 550 5.7.1. But again, I don't know that the distinction matters. I imagine there might be other ways the meant-to-be-hidden address could be returned alongside other error messages I've never encountered. Like the 550 5.1.1 error I reported before for a non-existent account, for example.

And again, if you're trying to hide the fact that someone is using gmail, for example, it's important to make sure things like this don't make it back either:
long error message identifiably from Gmail, redacted for brevity

Someone could be using Hide My Email to mask their personal domain, e.g. me@redacted full name.com, and leaking redacted full name.com even without the me@ could be enough to identify someone.

In practice, some of our customers' leaked hidden email addresses had enough in the domain alone to identify a single person since they were for personal websites.
July 1, 2026: 404 Media disclosed the existence of the vulnerability.
July 2, 2026: Apple reported fixing the exposure of Hide My Email-protected email addresses in bounce messages from third-party MTA servers while noting we are still actively investigating the additional concerns raised relating to the broader third-party MTA servers' error messages. We did limited tests and were unable to cause Hide My Email to leak a complete hidden email address. We noticed that email domains were still being leaked. We didn't test the account deletion issue reported on July 9, 2025.
July 3, 2026: We noticed a Reddit comment by user Alexisredwood describing a similar exploit discovered years ago, based on problematic email attachments, and shared it with Apple for investigation.
July 6, 2026: Apple made another update and asked us to check it.
July 7, 2026: We found that the known exploits had been fixed, but some other theoretical avenues for email addresses to be leaked remained untested. Notably, we tried having a mail server return a variety of custom 5xx error messages, and all of them seem to have been hidden regardless of their content indicating that the issue was probably fixed for all kinds of permanent bounces.
July 13, 2026: We conducted further testing of more scenarios involving temporary bounces and successful deliveries and found no additional problems.
July 14, 2026: Apple confirmed that we believe we have remediated the behavior noted in your report, including across the edge cases mentioned

Here's the complete report, minus redactions for personal information or other potentially sensitive details.

How to check if you're affected

Apple is in the best position to determine who's affected, but we don't know if they'll be able to tell. It probably depends on what they keep track of and how long they keep those records.

Most people probably can't tell on their own. But there are some things you can check and if you're lucky, you might be able to determine whether you were affected.

If you run your own mail server or have access to your mail server's logs, see if any messages were rejected with SMTP return code 550 or 552. Those two types of errors were the easiest to exploit and seem most likely to be the source of leaks. We don't know about other types of errors being a problem, but a code in the range 500 to 599 might have been a problem.
Contact your mail host to ask if they can tell whether you were affected. Even if you can't see the relevant logs, they might be able to.
See how much spam your Hide My Email addresses were getting. If a lot of spam made it through to your inbox or spam folder, it could be a sign that some spam was being rejected by your mail server without being delivered to you, which could mean you’re at a higher chance of having been affected.

The most common rejections that leaked hidden email addresses were sent back with were 550 5.7.1 or with 552 5.7.0. The deleted account error code was 550 5.1.1. We don't know which other types of rejections, e.g. oversized or invalid attachments, recipient inbox full, etc., might have also been problematic.

What to do if you're affected

You probably can't tell if your real email address was leaked, so we recommend acting as if it did, pending more information from Apple or your mail host. If someone knows your real, long-term email address, it's usually possible to figure out where you live, your past addresses, your phone numbers, your other email addresses, the names of your relatives, your employment history, and more.

In the United States, lax privacy laws make lookups easy on people-search sites. Most other countries have stricter data broker regulations, making it harder to link your email address to your other personal details, but the contents of data breaches often make it possible to piece together a complete profile.

Here are some steps that could help you stay safer and preserve your anonymity going forward:

Stop generating new content associated with your existing Hide My Email addresses. For example, if you have a Reddit account associated with a leaked Hide My Email address, and if Reddit happens to have a data breach in the future, it could be possible to link all of your past and future Reddit posts and comments to your real email address. By making new accounts, you can limit the potential damage to just your past content.
Along similar lines, deactivate old Hide My Email addresses that you no longer need, to ensure you don't use them accidentally in the future.
To go a step further, delete accounts and content associated with existing Hide My Email addresses. Content that's publicly attributed to your Hide My Email address could be connected to you. Content that's linked to your Hide My Email address behind the scenes, as in the example of a Reddit account with a non-public account email address, is at risk following a potential data breach in the future.
Remove the easy-to-find links between your real email address and the rest of your personal data to make it harder for someone with your real email address to learn more about you. That's the service we sell for US residents. There are a variety of paid opt-out services. It's also possible to opt out of people-search sites yourself for free. This is a more significant problem in the United States than in most other countries.
Consider using a different email aliasing service. A service whose primary focus is email aliasing and user privacy might be more responsive to bug reports
Some people layer two different email aliasing services, which helps in situations like this. If your Hide My Email address pointed to another email alias that points to your real email address, both email aliasing services would need to be compromised to expose your real email address.

For mail hosts and mail senders

Your logs may contain personal email addresses that you don't know about and that your customers didn't intend to share with you. We recommend deleting any leaked email addresses that were shared with you.

Other email aliasing services

In advance of releasing the exploit details, we did limited testing against many of the major email aliasing services on the market. None of the ones we tested had the same kinds of vulnerabilities. But there are many aliasing services and we weren't able to test all of them. If you use another email aliasing service, we recommend checking with them to make sure you're protected.

If you operate an email aliasing service, the exploit information should be helpful for testing. Let us know if you'd like any input from us.

Our thoughts

This section contains our opinions and speculation, so take it with a grain of salt.

We wouldn't be surprised if someone has been exploiting these vulnerabilities. We have no evidence in either direction. But the way we discovered the bug, and the fact that we thought of an easy, effective exploit immediately despite having no email delivery expertise indicate that anyone else in our position could be capable. Email delivery issues are widespread. Looking at logs to troubleshoot delivery issues is a natural first step, and the most relevant thing in the logs is usually the error message, which is exactly where email addresses were being leaked.

If someone was exploiting the vulnerabilities, we wouldn't have heard about it from them. Even if Apple can't determine who's affected or whether the exploit was used, it might be possible for mail hosts or mail delivery services to look for unusual activity indicating active exploitation. Or, now that the vulnerabilities have been fixed, maybe anonymous reports of exploitation will surface.

Many people are wondering why Apple took so long to fix the vulnerabilities. We are too. We know very little about email delivery or aliasing or SMTP. Without the relevant expertise and without insight into the technical details of how Hide My Email works and Apple's bug fix process, it's hard to say. Maybe the reporting and escalation process put this on a back burner.

We wish there had been more communication throughout the process. We got the impression that Apple didn't really understand the issue until about a year after it had been reported, since there were two incorrect claims that the issue had been fixed. In both cases, we simply used our original reproduction instructions to learn that the supposed fixes weren't actually solving the problem. The issue was a big deal in our minds, but we couldn't tell whether Apple was interpreting it the same way. If we had gotten confirmation one way or the other, it could have helped. We would have had the opportunity to explain better. Or if Apple had shared their testing process sooner, we would have been able to point out what it missed.

When we first reported the issue to Apple, we considered including a disclosure timeline, but decided against it because we thought it was obviously a serious issue that would get fixed as soon as possible. In the future, we won't be so optimistic, and we'll always provide a deadline. We assumed that Apple was taking the issue seriously and that it must just be harder to fix than we imagined. In retrospect, maybe we were wrong.

Some people say this must have an intentional backdoor, or it would have been fixed sooner. Intentional backdoors in software do exist, but we doubt this is one. Apple stores the mapping from Hide My Email addresses to hidden email addresses. They can share that mapping, no backdoor required.

While we doubt any bad intentions, these vulnerabilities do shake our trust in Apple's privacy and security claims. The issue seems so obvious, and all the other email aliasing services we tested were immune. Third party audits of Apple's claims and code could help to reestablish some faith. But either way, we'll continue to be Apple customers.

The (weak) evidence that leaks could have been widespread

Again, this is speculation. We think the bounces that were leaking hidden email addresses might have been more common than one might assume, given normal email delivery patterns.

When we first noticed the issue, it was because customer emails sent to Hide My Email addresses were being rejected as spam at much higher rates than when we sent the same emails to non-hidden addresses, which implies to us that one of the following must be true:

iCloud was rejecting the emails as spam
Destination hosts were rejecting the emails as spam at elevated rates because they came from Hide My Email.

If iCloud was rejecting the emails without trying to deliver them to the hidden email address, then iCloud itself was generating an error message that included the hidden email address, which is a blatant error.

If, instead, emails forwarded from iCloud were treated as spam while nearly identical emails sent to the same mail hosts weren't, it indicates that something about iCloud's forwarding was causing the emails to be rejected as spam, exacerbating the issue.

The exploit process we described to Apple also hints at the idea that Hide My Email causes higher rates of spam bounces not only for legitimate emails, as we saw for our rejected emails to customers, but also for spam emails. We sent copies of spam messages from our personal inboxes for testing. Because they made it to our inboxes, these emails were clearly not rejected by Gmail. But when we sent identical emails to a Hide My Email address connected to Gmail, they did get rejected as spam, leaking the hidden email address.

Things we're wondering about

It'd be helpful for those affected, which includes us as personal Hide My Email users, to know things like:

Did Hide My Email have these vulnerabilities from its inception? If not, when was the regression?
Were we the only ones to report anything about these vulnerabilities? Some people are claiming public knowledge of similar exploits.
Are there logs that make it clear which individual Hide My Email addresses were affected? If not, are there aggregate statistics indicating the issue's prevalence?
Was anyone at Apple working on this with significant effort for the full year it took to fix it? Is it a coincidence that the vulnerabilities were fixed just a few days after they were publicized?
Does Apple plan to notify affected customers?

Feel free to contact us with any questions. We might be able to expand on any FAQs.

We'd like to thank Joseph Cox and 404 Media for safely disclosing the vulnerabilities' existence, as well as Alison, our friends, family, customers, and coworkers for their help and guidance.

We encourage anyone with information helpful for determining the scope of the breach to reach out to Apple.