Privacy Relay vs Disposable Email: Apple Hide My Email and Signup Policy
by EmailGuard Marketing
August 11, 2026engineering5 min read
Share this article
Enjoyed this article?
More notes on building products, infrastructure, and teams.
A privacy relay hides a user’s real inbox behind a forwarding alias; a disposable address is a throwaway inbox. Treat them as different signals. Blocking relay_domain the same way you block disposable will reject Apple Hide My Email, Firefox Relay, and similar tools that real customers use on purpose.
This guide explains the difference, what Apple changed with @private.icloud.com, and how to set policy without confusing privacy with abuse. For throwaway domains specifically, see block disposable emails at signup and blocklist vs validation API.
Relay vs disposable in one table
| Privacy relay | Disposable / burner | |
|---|---|---|
| Purpose | Hide identity; forward to a real mailbox | One-time inbox; often abandoned |
| User intent | Ongoing use, often privacy-conscious | Avoid verification, spam, or bans |
| Delivery | Forwards to the user’s real address | Temporary mailbox UI |
| Account recovery | Possible (user controls the relay) | Fragile or impossible after expiry |
| Typical domains | private.icloud.com, mozmail.com, duck.com, … | Guerrilla, TempMail clones, rotating hostnames |
| EmailGuard field | relay_domain / relay_provider | disposable / disposable_provider |
Relays are not “invalid” under RFC 5322. They are valid addresses with different risk and support characteristics.
Apple Hide My Email (2026)
Apple’s Hide My Email and Sign in with Apple private addresses are privacy relays. On June 15, 2026, Apple announced that later that summer it would unify new addresses onto @private.icloud.com (Apple Developer news; MacRumors):
| Feature | Legacy domain (existing addresses keep working) | New addresses (after the switch) |
|---|---|---|
| Sign in with Apple | privaterelay.appleid.com | private.icloud.com |
| iCloud+ Hide My Email | icloud.com (looked like a normal iCloud inbox) | private.icloud.com |
Practical implications for signup code:
- Allowlist / validation must accept
private.icloud.complus the legacy domains. Apple’s notice calls this out for Sign in with Apple apps and for email providers’ filters. - Do not treat Apple relays as disposable. Users who enable Hide My Email are often high-intent customers—not bots spinning burners. The new domain makes relays easier to identify; that is a reason to classify them correctly, not to conflate them with throwaways.
- Prefer an API classification (
relay_domain+relay_provider) over maintaining your own Apple domain table. Domains and MX fingerprints change; your policy should not.
EmailGuard’s privacy relay detection covers Apple Hide My Email via domain and DNS signals alongside Firefox Relay, SimpleLogin, DuckDuckGo Email Protection, Proton Pass aliases, Addy.io, and similar products. Try a live check with the relay domain lookup tool.
Other relays you will see
Representative domains (not exhaustive—EmailGuard’s list updates continuously):
| Domain examples | Provider slug (EmailGuard) |
|---|---|
mozmail.com, relay.firefox.com | firefox_relay |
simplelogin.com, slmail.me | simplelogin |
duck.com | duckduckgo |
passmail.net | protonmail |
anonaddy.com, addy.io | anonaddy / addy_io |
Custom domains that route through relay infrastructure can still classify as relays when MX/DNS fingerprints match. That is why string-matching a short denylist is a weak substitute for detect email characteristics.
Policy matrix (recommended defaults)
| Product surface | Disposable (disposable) | Relay (relay_domain) |
|---|---|---|
| Open signup / freemium | Block | Allow; store provider for support |
| Paid B2B trial | Block | Allow; optional step-up (verify phone / SSO) |
| High-trust / money movement | Block | Step-up or require corporate domain |
| Newsletter / waitlist | Block or soft-flag | Allow |
| Abuse + velocity limits | Block disposable; rate-limit relays | Relays alone ≠ abuse |
The anti-pattern: one boolean named is_suspicious_email that ORs disposable and relay. That collapses two different decisions and will show up as “Apple users can’t sign up” tickets.
Implementation sketch
async function classifySignupEmail(email, apiKey) {
const res = await fetch(
`https://emailguard.co/api/v1/emails/detect?email=${encodeURIComponent(email)}`,
{ headers: { Authorization: `Bearer ${apiKey}` } },
);
if (!res.ok) {
return { allow: true, failOpen: true };
}
const { data } = await res.json();
if (!data.syntax_validation) {
return { allow: false, reason: "syntax" };
}
if (data.disposable) {
return {
allow: false,
reason: "disposable",
provider: data.disposable_provider,
source: data.detection_source,
};
}
if (data.relay_domain) {
return {
allow: true,
reason: "relay_allowed",
relayProvider: data.relay_provider,
// Optional: requireMfa: true for high-trust products
};
}
return { allow: true, reason: "ok" };
}Use an API key with email:detect (scopes). Client libraries: EmailGuard SDK guide.
Support and product notes
- Password reset still goes to the relay address; the provider forwards to the user. That is expected.
- Support identity is harder when the visible address is an alias—store
relay_providerand teach support not to treat it as a typo. - “One account per person” is not solved by blocking relays. Relays reduce address reuse across sites; they do not prove unique humans. Use MFA, device signals, or billing identity for that problem.
FAQ
Is @private.icloud.com a disposable domain?
No. It is Apple’s privacy relay namespace. Classify it as a relay, not a burner.
Should I block all relay_domain addresses for compliance?
Only if your policy requires a recoverable corporate or personal mailbox you can prove ownership of beyond email. Most consumer and mid-market SaaS products should allow relays and block disposables.
Can a domain be both relay and disposable?
In practice you should treat the fields as separate. Your policy table should check disposable first for hard blocks, then apply relay rules. See disposable detection and relay detection.
How is this different from a public mailbox (Gmail)?
Public domains (gmail.com, etc.) are shared consumer hosts. Relays are forwarding aliases. EmailGuard exposes both: public_domain and relay_domain. Allow-lists for “corporate only” should use your own domain allowlist or SSO—not “block every non-corporate host,” which also blocks Gmail.
Next steps
- Read privacy relay detection for field semantics.
- Keep disposable blocking separate with the signup blocking guide.
- Try a live check in the API playground or create an API key.