Apple's Hide My Email has functioned, for the past few years, as something close to silent infrastructure for a specific class of user: the privacy-aware freelancer, the SaaS-heavy startup founder, the agency operations manager who signs up for seventeen tools a quarter and doesn't want their real inbox turned into a spam landfill. A developer named Arseniy Shestakov posted a detailed technical breakdown on June 16, 2026, documenting how an upcoming Apple change will fundamentally undermine the feature's core value proposition. The post landed on Hacker News with 354 upvotes and 217 comments — the kind of traction that signals this isn't a niche complaint from a power user, but a substantive shift that's going to affect a lot of people who may not realize it yet. My take: this is less about one feature degrading and more about Apple repeating a pattern that small teams who've built workflows around Apple privacy services should have seen coming — and now need to respond to with urgency.
What Is This Actually?
To understand why this change matters, you need to understand what Hide My Email actually does at a technical level, not just the marketing framing Apple has put around it.
Hide My Email, launched as part of iCloud+ in September 2021, generates random email alias addresses in the @icloud.com or @privaterelay.appleid.com domain namespace. When you sign up for a service using one of these aliases, the service sends mail to that alias. Apple's relay infrastructure intercepts that mail and forwards it to your real inbox. The third-party service — whether that's a newsletter platform, a SaaS vendor, or a random e-commerce site — never sees your actual email address. From their side, they're talking to an opaque iCloud relay endpoint. From your side, everything lands in your normal inbox.
The feature works in two distinct modes. The first is the Sign in with Apple integration, where HME addresses are generated automatically during the OAuth-style login flow. The second is standalone alias creation, where you manually generate a random alias through Apple's Settings or iCloud.com interface and use it anywhere — not just with Apple-mediated logins. This second mode is what most power users care about. It's the equivalent of what SimpleLogin or AnonAddy have offered for years, but baked into the Apple subscription most iPhone users already pay for.
What's changing, according to Shestakov's analysis, is that Apple is modifying the way the relay behaves in a way that removes or degrades the guarantees users have relied on. The details of the mechanism involve how Apple now processes the content flowing through the relay in conjunction with Apple Intelligence features — the AI capabilities Apple has been aggressively rolling out across its platforms. The practical effect is that the strict separation between your real identity and your alias addresses — the core privacy property that makes the feature useful — is being compromised. In some scenarios, the relay will no longer maintain the information barrier that gave Hide My Email its name.
There's also a parallel set of changes involving how email authentication protocols interact with the relay. SPF, DKIM, and DMARC — the trio of standards that major receiving mail servers use to decide whether to accept, reject, or spam-bin incoming messages — have become dramatically more strictly enforced in 2025 and 2026, largely driven by Google and Yahoo's enforcement actions. Apple's relay modifies the sending path of forwarded email in ways that can break DKIM alignment, causing forwarded messages to arrive at your inbox having failed authentication checks. This is increasingly getting those forwarded emails routed to spam folders or rejected outright — which is its own form of "useless," distinct from the identity-leakage concern but equally fatal in practice.
The net result is that users who have built their inbox hygiene and privacy practices around Hide My Email are facing two simultaneous failure modes: their aliases may start leaking identity information, and the emails forwarded through those aliases may start disappearing into spam or getting rejected entirely. Neither is acceptable if you're depending on the tool for real work.
Why This Matters Right Now
The timing here is not accidental, and understanding why this is happening in mid-2026 specifically explains a lot about the broader risk landscape for small teams that depend on platform-native privacy features.
Twelve months ago, the combination of Apple's relay infrastructure and HME's information isolation was genuinely impressive. Apple had invested in making the relay robust, and the email authentication issues — while present — were manageable. The service was working well enough that recommending it to iCloud+ subscribers as a SimpleLogin alternative was reasonable advice. It wasn't as configurable or powerful as dedicated alias services, but it was good enough, it was free with an existing subscription, and it worked smoothly within Apple's ecosystem.
Several things have shifted simultaneously to break that equilibrium. First, the major email providers — Google, Microsoft, and to a lesser extent Yahoo — have dramatically tightened their DMARC enforcement. In 2025, Google and Yahoo began rejecting mail from bulk senders that failed DMARC checks; in 2026, those policies have propagated further and are now affecting individual forwarding relays like Apple's. The forwarding model that relays depend on is inherently in tension with modern email authentication, and the workarounds (SRS — Sender Rewriting Scheme — and other header manipulations) require ongoing maintenance to keep current. It's not clear Apple has prioritized that maintenance.
Second, Apple Intelligence changed the company's internal incentives around email data. To power AI features like email prioritization, summarization, and smart replies, Apple's systems need to process mail. When that mail is flowing through a relay, the processing necessarily occurs in a context where the relay knows both the alias and the real recipient. The architectural separation that made HME's privacy promise credible is increasingly at odds with the AI processing pipeline Apple is building. Apple's on-device AI claims provide some cover here, but the relay itself is inherently a server-side operation — and server-side AI processing doesn't carry the same privacy guarantees Apple markets with on-device features.
Third, regulatory pressure in the EU under the Digital Markets Act and in other jurisdictions has created scenarios where Apple may be compelled to provide information about relay addresses to third parties under certain circumstances. The legal framework around email relay services and user identity has become significantly more complex, and Apple's ability to maintain absolute separation between alias and identity has eroded from a legal standpoint even if the technical infrastructure remained intact.
What this means for small teams is that the "free, good enough, Apple-native" option that worked for the past three years is no longer a safe default. The window for complacent reliance on platform privacy features has closed.
Practical Implications for Small Teams
Let me walk through how this plays out in concrete operational terms for the kinds of teams Opsvoro covers — freelancers managing their own inbox, small agencies running client work, solo founders operating multiple products.
SaaS trial and tool evaluation workflows. This is probably the single most common use case for HME among technically sophisticated small-team operators. When you're evaluating three competing project management tools, five different AI writing assistants, and two accounting platforms in the same quarter, using your real email address for all of those signups means those vendors have your email, will put it in their CRM, will send you their newsletters, and will sell or share it with their partners. Many small teams have developed a workflow where every new SaaS evaluation gets a unique HME alias, allowing clean separation between "active vendor" and "vendor we tried once in 2024." If HME degrades, this workflow breaks — the alias either starts leaking identity information or the vendor's onboarding emails start going to spam, making the evaluation itself impossible.
Newsletter subscriptions and content research. Freelancers and agency operators consume a lot of written content — newsletters, research reports, industry publications. Subscribing to twenty newsletters with your real email address turns your primary inbox into a disaster zone. HME aliases have functioned as a clean subscription layer: subscribe with an alias, and if the newsletter goes downhill or sells your address, you delete the alias. If this forwarding becomes unreliable due to authentication failures, those newsletters may simply stop arriving — which is an invisible failure mode. You don't know you're missing content; it's just not there.
Client intake and project communication. Some agency operators create HME aliases for specific client relationships or project types, using them as lightweight project-specific inboxes that forward to their main address. This gives clients a consistent point of contact while allowing the operator to manage message flow. If alias reliability degrades, this workflow creates a support problem: clients send emails that don't arrive, the operator doesn't know what they're missing, and the professional relationship suffers.
Multi-brand or multi-product operations. Solo founders running two or three products frequently use alias email addresses to create distinct identities for each product's inbound communications without maintaining separate email accounts. HME was a convenient way to do this inside the Apple ecosystem. The degradation of this use case pushes these operators toward maintaining full separate email accounts or domains, which has real operational overhead.
Privacy as a client deliverable. Agencies working with privacy-sensitive clients — legal, medical, financial, HR — sometimes use alias email addresses specifically because they're communicating with people who haven't formally consented to be in the agency's CRM. Using an alias maintains a degree of operational separation. If that alias's privacy properties are compromised, the agency may actually have a compliance problem, not just an inbox management problem.
In my view, the most immediately impactful failure mode for small teams isn't the identity leakage issue — that's serious but abstract. It's the deliverability degradation. If your aliases are routing legitimate business email to spam folders, you're losing real information and real opportunities silently. That's the problem you need to solve first.
How to Respond and Act on This
The right response depends on how deeply embedded HME is in your current workflows, but there's a general sequence that makes sense for most small-team operators.
Step 1: Audit your active HME aliases immediately. Go to iCloud.com or Settings → iCloud → Hide My Email on your Apple device and get a complete picture of how many aliases you have and what they're connected to. Apple's interface shows you the alias, the label you gave it, and the date it was created. Export or document this list. Many users set up aliases and forget about them; this audit will reveal both active aliases you care about and dormant ones that represent historical risk.
Step 2: Categorize by criticality. Divide your aliases into three buckets: (a) aliases tied to services you actively use and depend on, where email deliverability is business-critical; (b) aliases tied to services you care about but could re-subscribe with a different address if needed; and (c) aliases tied to things you don't really need. The third category you can let go. The first category is where you need to act now.
Step 3: Migrate critical aliases to a dedicated alias service before the change fully lands. For everything in bucket (a), create a corresponding alias in whatever service you choose (more on options below), update the email address on the relevant accounts, and confirm that email is flowing correctly before you delete the HME alias. This is tedious but not technically difficult. The risk of waiting is that a deliverability failure strands you mid-workflow — you can't receive a password reset email, for instance, because the alias is broken.
Step 4: Seriously consider owning your own domain for email aliases. This is the architectural move that solves the "platform dependency" problem permanently. If you own yourname.com or youragency.com, you can route email aliases through that domain using Cloudflare Email Routing (free), ImprovMX, or Fastmail's custom domain support. This means your alias addresses are [email protected] — and if one relay service degrades, you can change the underlying infrastructure without changing any of the addresses you've given to external services. This is the play that makes you permanently immune to any future "Apple is breaking X" news cycle.
Step 5: Update your standard operating procedures for new SaaS signups. Whatever service you move to, build the alias-creation step into your workflow for new tool evaluations and subscriptions. The behavior pattern matters more than the specific tool. If you have teammates or a VA handling SaaS signups, document the new process.
What to avoid: Don't panic-migrate everything in one sitting without verifying deliverability. Don't use the migration as a reason to clean up your alias list so aggressively that you lose access to something important. And don't assume that just because this change is "coming" it means everything is already broken — audit first, then move deliberately.
Alternatives Comparison
| Tool | Best For | Free Plan | Starting Price | Key Differentiator |
|---|---|---|---|---|
| SimpleLogin | Power users, open-source advocates | Yes (10 aliases) | ~$4/mo or ~$30/yr | Open source, self-hostable, acquired by Proton — excellent deliverability |
| addy.io (AnonAddy) | Privacy purists, high-volume alias users | Yes (unlimited aliases, bandwidth limits) | ~$1/mo | Cheapest paid tier with solid features; fully open source |
| Firefox Relay | Firefox ecosystem users | Yes (5 aliases) | ~$2/mo | Mozilla brand trust; tight browser integration |
| Fastmail Masked Email | Users who want email hosting + alias management together | No (requires Fastmail subscription) | ~$5/mo | Best-in-class email client, excellent deliverability, seamless alias UX |
| Cloudflare Email Routing | Own-domain users who want free forwarding | Yes (free, unlimited) | Free | Requires a domain on Cloudflare; no alias management UI, just DNS rules |
| ImprovMX | Agencies managing multiple client domains | Yes (1 domain, limited) | ~$9/mo (multi-domain) | Best option for managing email routing across multiple owned domains |
| Apple Hide My Email | iCloud+ subscribers in Apple ecosystem | No (requires iCloud+) | ~$1/mo bundled | Native Apple integration — actively degrading per this story |
In my view, the right choice for most small teams and freelancers reading this is either SimpleLogin (if you're already in the Proton ecosystem or care about open source) or Fastmail with custom domain (if you want to combine your email hosting and alias management into one reliable service). Both have demonstrated genuine commitment to email deliverability — including actively working on DKIM alignment issues that plague relay services — in a way that Apple simply has not prioritized.
For agencies managing multiple client domains or running multi-brand operations, ImprovMX at the paid tier is worth serious evaluation. It handles the multi-domain complexity cleanly and has a professional-grade management interface.
The Cloudflare Email Routing path is the most technically resilient option if you own a domain and are comfortable with some DNS configuration. Cloudflare's infrastructure is extremely reliable, the price is zero, and the architecture means you're not dependent on any single vendor's relay service. The tradeoff is that it requires domain ownership and some setup investment.
What the HN Community Is Saying
The Hacker News thread on this story is unusually substantive — 217 comments with a lot of actual signal rather than the usual noise. A few distinct perspectives crystallized in the discussion.
The "I told you so" camp is prominent and not entirely wrong. Several veteran HN commenters pointed out that building critical privacy workflows on top of a bundled, opaque, vendor-controlled feature has always carried this risk. The argument: Apple's incentives have never aligned with being a neutral privacy relay; their interest is in selling hardware and services, not in maintaining infrastructure that keeps third-party data out of Apple's own analytics. This critique has merit. The users who built on SimpleLogin, addy.io, or self-hosted solutions years ago are not affected by this change.
Deliverability is the real story for many practitioners in the thread. Multiple people with experience running email infrastructure pointed out that the DKIM/DMARC issue is arguably more immediately impactful than the identity-leakage concern. If your forwarded emails are ending up in spam or being rejected outright, the privacy properties of the relay are irrelevant — the feature is already functionally broken. Several people reported this has been happening sporadically for months already.
The lock-in concern is generating thoughtful discussion. People who have given HME aliases to dozens of services face a genuine migration pain: you have to update your email address on each of those services individually, which requires being able to log in (sometimes itself dependent on the HME-relayed email address for password resets). This creates circular dependency traps. The thread has some practical advice for breaking those loops, but it's not clean.
Skeptics of the original article are present too — some commenters argue that the author is overstating the changes, or that Apple's privacy protections remain stronger than the alternatives at a systemic level even if HME specifically is degrading. This minority view isn't persuasive to me. Whether or not Apple's overall privacy posture is strong is a separate question from whether HME as a specific feature is becoming unreliable. The deliverability data alone justifies migration.
A recurring practical thread involves people recommending the custom-domain path, which is the right recommendation. If you own your domain, you control your email namespace permanently. That's the architecture that survives any individual vendor's product decisions.
Risks and Things to Watch
The migration complexity trap. If you've used HME actively for two or three years, you may have dozens of aliases connected to services across your professional and personal life. Migrating all of them is a project, not a task. The risk is that you start the migration, complete it for the services you actively think about, and miss the ones you've forgotten — which then become stranded. Conduct a genuinely comprehensive audit before you start, not a quick scan.
Vendor lock-in repeating itself. Moving from HME to SimpleLogin or addy.io solves the immediate problem but recreates the same structural risk if you don't own your own domain. If SimpleLogin's business model changes (it was acquired by Proton in 2022, which is generally a positive signal, but acquisitions create uncertainty), or if addy.io's solo developer behind the service moves on, you face the same migration problem. The permanent solution is a combination of: a dedicated alias service for active use plus a custom domain for the addresses you care most about.
Email authentication getting harder. The email ecosystem is moving toward stricter authentication requirements, not looser ones. The problems that are making HME's relay unreliable today will affect any relay-based alias service that doesn't actively maintain its DKIM/DMARC handling. When evaluating alternatives, ask specifically: how do they handle DKIM alignment for forwarded mail? SimpleLogin and Fastmail both have documented, maintained approaches to this. Some smaller services don't.
Apple may partially reverse or mitigate. It's possible that the community response to this story, combined with developer and enterprise pushback, prompts Apple to walk back some of the changes or implement workarounds. Apple has done this before with features under pressure. I wouldn't count on it, and I wouldn't delay migration waiting for it, but it's worth monitoring Apple's developer documentation and iCloud release notes over the next few months.
Cost creep at scale. If you're running an agency with multiple team members each maintaining alias sets, the paid tiers of dedicated alias services add up. SimpleLogin's team plans, Fastmail's multi-user accounts, and addy.io's higher tiers all have per-seat or per-alias costs. Budget for this as you plan your migration, and evaluate whether consolidating on Cloudflare Email Routing with a custom domain for the team might be more cost-effective at your scale.
Privacy theater risk. There's a failure mode where teams do a superficial migration — move from HME to another service without really understanding the threat model — and end up with the same false sense of security. Email alias services do not make you anonymous. They protect your real email address from direct disclosure. They do not hide your behavior patterns, your purchasing history, your IP address, or any of the other data points that advertisers and data brokers use. Be clear about what you're protecting and what you're not.
Frequently Asked Questions
What exactly is changing about Hide My Email, and when does it take effect? Based on Shestakov's analysis, Apple is modifying how the relay infrastructure handles forwarded mail in ways that compromise the information barrier between alias addresses and real user identities, particularly as Apple Intelligence features are integrated into mail processing. The changes are described as "about to" land, suggesting they're imminent as of mid-2026. Apple has not published a specific timeline or migration notice for HME users, which is itself part of the problem — affected users are not being proactively informed.
Will my existing HME aliases stop working completely? Probably not immediately and not all at once. The degradation is likely to be gradual — some aliases may experience deliverability issues before others, and the identity-isolation compromise may affect some use cases more than others. This is actually more dangerous than a clean shutdown, because gradual degradation is harder to detect. You may not notice for weeks that emails from a critical vendor are going to spam or being rejected.
Can I export my HME aliases to another service? Not directly. Apple doesn't provide a data export format for HME aliases, and the aliases themselves (the @icloud.com or @privaterelay.appleid.com addresses) are owned by Apple — you cannot port them to another service. What you can do is document all your aliases, then create equivalent aliases in your new service, and update the email address on each third-party account to point to the new alias. This is the migration work that needs to happen.
Is Sign in with Apple also affected by these changes? This is worth watching carefully. The Sign in with Apple OAuth flow generates similar relay addresses, and the underlying infrastructure is shared. If the relay changes affect HME, they likely affect Sign in with Apple relay addresses as well, though the integration may have different characteristics. For apps where you've used Sign in with Apple specifically to avoid sharing your email, I'd recommend auditing those relationships too.
Are third-party alias services actually more private than Hide My Email? It depends what you mean by "more private." From an infrastructure standpoint, services like SimpleLogin and addy.io have more transparent, documented privacy practices than Apple's opaque relay. SimpleLogin in particular is open source, meaning the privacy properties are auditable in a way that Apple's never will be. From a practical deliverability standpoint, services that actively maintain DKIM alignment handling are significantly more reliable today than Apple's relay. In my view, SimpleLogin via Proton or Fastmail are meaningfully better on both dimensions right now.
What's the best option if I want to spend as little money as possible?
Cloudflare Email Routing combined with a cheap domain is the highest-value option. A domain costs roughly $10-15 per year from Namecheap or Cloudflare Registrar. Email routing through Cloudflare is free. You can create unlimited *@yourdomain.com catch-all addresses or specific named aliases, all forwarding to your real inbox. The setup takes about 30 minutes if you're comfortable with DNS configuration. The tradeoff is that you don't get a management UI for aliases — it's infrastructure-level, not a polished product.
Should I just stop using email aliases altogether and accept the spam? No. The email alias pattern is one of the most effective practical privacy and inbox management tools available to small teams. The right response to one implementation of the pattern degrading is to move to a better implementation, not to abandon the practice. The underlying value proposition — decoupling your real identity from your communication endpoints with third parties — is real and worth maintaining. The HME situation is a vendor problem, not a pattern problem.
Will this affect Apple's "Sign in with Apple" feature's privacy protections more broadly? Sign in with Apple's primary privacy value is the email relay component — which is the same infrastructure being changed here. The OAuth/SSO component (not sharing your Apple ID password with third parties, requiring biometric confirmation, etc.) is separate and not affected by these changes. So "Sign in with Apple" still has value as a secure authentication mechanism, but the privacy benefit of hiding your email from the third-party app is the part that's degrading.
Final Verdict
Here's the bottom line for small teams, freelancers, and agencies: Hide My Email has been useful infrastructure, and it's now unreliable infrastructure. Treat it accordingly.
The impulse to wait and see whether Apple fully follows through, whether the community backlash prompts a reversal, or whether the degradation is as bad in practice as the technical analysis suggests — that impulse is reasonable but wrong. The cost of proactive migration is some hours of work and possibly a small monthly fee for a dedicated alias service. The cost of waiting until the feature definitively breaks is dealing with missed emails, stranded accounts, and emergency migration under pressure. The asymmetry is clear.
Who should act immediately: Anyone using HME aliases for business-critical email — vendor onboarding, client communications, SaaS accounts where you'd be locked out without email access. If you've given an HME alias to your bank, your primary SaaS tools, or any service where losing email access means losing access to the service, migrate those addresses to a reliable alternative today.
Who should act this week: Freelancers and agency operators using HME for newsletter subscriptions, SaaS evaluations, and general inbox hygiene. Do the alias audit, pick a service (my recommendation is SimpleLogin if you're privacy-oriented, Fastmail if you want everything in one place), and work through the migration systematically.
Who can wait a bit: Users who have only used HME casually for a handful of low-stakes signups can afford to monitor the situation for another few weeks to see how the change actually manifests. But "monitor" means actively checking — subscribe to a tech news feed or check Shestakov's site for updates, don't just assume nothing has changed.
The meta-lesson here, and I want to be direct about this because I've seen small teams make this mistake repeatedly: don't build your operational privacy infrastructure on bundled features from vendors whose core business is something else. Apple's core business is selling hardware and premium software services. Privacy features like Hide My Email are differentiators that support that core business — they're not the business. When maintaining a privacy feature conflicts with Apple's other priorities (in this case, Apple Intelligence's data processing requirements and the complexity of maintaining relay deliverability), the feature loses.
The vendors whose core business is email privacy — Proton (which owns SimpleLogin), addy.io's team, Fastmail with its long-term commitment to email as infrastructure — have aligned incentives with keeping these features working. That alignment matters. It's the difference between a feature that exists as long as it's convenient and a feature that exists because the vendor's survival depends on it.
One final thought: owning your own domain for email purposes is no longer optional infrastructure for any serious professional operating in 2026. The cost is trivial — under $20 per year. The control it provides over your professional identity is permanent and vendor-independent. If you take one action from this piece beyond the immediate HME migration, make it registering yourname.com or youragency.com and routing email through it. Fifteen years ago this was a "power user" move. Today it's basic professional hygiene. Apple just made the case for it more forcefully than I ever could.