Skip to main content

Why Blocking Apple Hide My Email Is a Mistake

Published Updated 8 minute readGuidesRichelo Killian

Blocking Apple Hide My Email is a mistake because relay addresses are not disposable: they forward permanently to a real person's real inbox, and the person behind one is, by definition, a paying Apple customer. A signup filter that blocks relays stops no abuse, because abuse runs on throwaway domains that cost nothing and vanish, and instead it filters your audience for exactly one trait: caring about privacy. After fifteen years in deliverability, I will defend plenty of blocking decisions, but this one fails on pure mechanics, and this article walks through them.

What is Apple Hide My Email actually doing?

Mechanically, it is a forwarding service with Apple in the middle. When an iCloud+ subscriber uses Hide My Email, Apple generates a unique random address on its relay domain, the privaterelay.appleid.com that merchants see in their signup logs, and every message sent to that address is forwarded to the subscriber's real inbox. Replies route back through the relay so the alias holds. The subscriber can deactivate any individual alias whenever a sender abuses it, which is the entire point: one alias per service, revocable per service. The same relay domain also appears through Sign in with Apple, where users choosing the Hide My Email option arrive at your app with a privaterelay.appleid.com address that Apple manages for as long as the account relationship exists.

The siblings work the same way with different logos. Firefox Relay masks forward through mozmail.com to the user's inbox. DuckDuckGo Email Protection forwards through duck.com and strips trackers on the way. SimpleLogin, addy.io, and Proton's aliases offer the same per-sender alias model, several with custom domain support and paid tiers. Different vendors, one mechanism: a stable masked address, a real monitored inbox behind it, and per-sender revocation instead of address abandonment.

Why do people use relay addresses?

To stay in control of their inbox, not to escape yours. The searches that lead people to these tools, including the perennial iCloud Hide My Email spam queries, are overwhelmingly people trying to stop spam from reaching them, not people trying to send it or scam anyone. An alias lets them compartmentalize: if a service leaks or sells their address, exactly one alias burns, they deactivate it, and the other ninety-nine relationships continue untouched.

Here is the reframe worth sitting with: a relay signup is one of the most intentional subscriptions you will ever receive. That person performed a deliberate extra step, generating an alias specifically for you, precisely so that your mail would reach the inbox they actually read. They are not hiding from you; they are letting you in on their terms, with a door they control. Compare that with the drive-by signup typing any address to get past your form, and ask which one sounds like a subscriber. The relay user did more work to receive your email than most of your list ever will.

Are relay emails disposable?

No, and the two categories are opposites on every axis that matters to a signup form. A disposable address is an unowned, short-lived inbox on a domain built to be abandoned. A relay address is an owned, durable pointer to a real mailbox. Put them side by side:

Axis Relay address (Hide My Email and siblings) Disposable address
Ownership One accountable person, tied to a real account, often a paid one Nobody; public or throwaway inboxes anyone can claim
Permanence Persists until the owner deliberately deactivates it Minutes to hours by design; the domain itself often dies
Deliverability Forwards reliably to a monitored real inbox Mailbox vanishes; domains go dark and hard bounce
Abuse risk Low: one identity per person, revocation is per sender High: unlimited fresh identities from one provider

The scale difference makes the point numerically. As of the September 2026 State of Disposable Email report, the dataset tracked 217,847 disposable domains, with 10,223 genuinely new ones arriving in a single 36 day window, against exactly 12 relay domains across 6 provider families. Twelve stable, documented, publicly operated domains versus ten thousand new throwaways in five weeks. These categories are not neighbors, and any filter that treats them as one category has misunderstood both.

What does blocking relay addresses actually cost you?

It costs you a customer segment that selects for the traits you want, described without inventing a single statistic. Every Hide My Email address belongs to an iCloud+ subscriber, which means every one of them is an Apple customer with an active paid subscription and a payment method on file. Firefox Relay's premium tier, SimpleLogin, addy.io, and Proton's plans mean many of the sibling addresses likewise belong to people who pay money for email tooling, which is to say people who take email seriously. That is the population a relay block excludes, and it excludes them with precision, because the block triggers on the privacy behavior itself.

It costs you flows, not just individuals. Reject privaterelay.appleid.com signups and you have quietly broken Sign in with Apple for everyone choosing its privacy option, a flow the user reasonably believes is standard. And it costs you credibility at the exact moment of first contact: your form tells a person using a real, working, deliberately created address to "use a real email." Search for firefox relay blocked and you will find those people, annoyed, naming the services that turned them away. Meanwhile the abuse you were aiming at is untouched, because code farmers and trial abusers do not pay Apple for aliases; they use throwaway domains that cost nothing, and those were always the correct target. One more mechanical point, since deliverability is my trade: relays do not even contribute to the real risk disposables create. The list quality damage that gets senders flagged at Mailchimp or SendGrid comes from dead throwaways hard bouncing in batches, and a relay address, forwarding faithfully to a monitored inbox, produces none of it.

But what about multi-account abuse?

This is the one honest argument for blocking relays, so it deserves a straight answer: yes, alias services make it easier for one person to create several accounts, and no, blanket-blocking the relay category is still the wrong tool. If your product genuinely requires one account per person, that constraint is an identity problem, and email format was never going to enforce it; determined multi-accounters have endless plus-addressed, free-provider, and throwaway options regardless. The proportionate response is to use the relay signal as information: allow the signup, and apply your existing dedupe controls, payment method on file, phone verification, manual review for accounts claiming promotions, knowingly. Dedupe policy is an application decision, and a good detection layer's job is to hand you the flag so you can make that decision precisely, instead of amputating a customer segment to avoid making it.

What is the correct way to handle relay addresses?

Detect them, flag them, and never block them by default, which is exactly how the check behind this article expresses it. The API returns relay as its own signal, fully separate from the disposable verdict, so a relay address is never marked disposable and never swept into a throwaway block. Under the default policy a relay arrives as a warn, a gentle nudge you can act on or ignore, and if you want different handling, tagging relays in your CRM, adding friction only on promotional signups, the policy is yours to change in the dashboard while the block verdict stays reserved for actual throwaways. The full treatment of where relays fit in a detection strategy is in the relay section of The Complete Guide to Disposable Email Detection, and it is the link to put in front of anyone, colleague, client, or plugin vendor, who proposes treating Hide My Email as spam.

The one-sentence version to die on: block the addresses that will not exist next month, welcome the people who built a door just for you. isitdisposable.com draws that line for you on every check, a live dataset of 217,847 disposable domains per the September report from multiple upstream sources, MX-validated and refreshed daily, with relay as a first-class separate signal and fail-open behavior throughout. The free plan's 250 lookups a month and the 14-day full-access trial, no credit card, are enough to see how many relay users your forms have been turning away.

About the author

Richelo Killian

Founder

Founder of isitdisposable.com and the SenderWorx email tool suite. Builds email infrastructure and anti-abuse tooling.