What Is a Privacy Relay Email?
by EmailGuard Marketing
Share this article
Enjoyed this article?
More notes on building products, infrastructure, and teams.
by EmailGuard Marketing
More notes on building products, infrastructure, and teams.
A privacy relay email is a forwarding alias issued by a vendor so a website never sees the user's real inbox. Mail sent to the alias is delivered to an account the user already owns. They can usually turn the alias off later. It is not a disposable inbox. Disposable domains die. Relays persist until the user or the vendor disables them.
Apple documents this as Hide My Email. Sign in with Apple aliases use @privaterelay.appleid.com (Apple Support, Hide My Email with Sign in with Apple). iCloud+ can mint additional random addresses that forward to a verified Apple Account mailbox (iCloud Hide My Email guide). Firefox Relay, addy.io, SimpleLogin, DuckDuckGo Email Protection, and Proton Pass aliases are the same job on other hosts.
This page is the definition. Policy when it shows up at signup: privacy relay vs disposable email.
| Thing | Lasts | Mail lands | EmailGuard flag |
|---|---|---|---|
| Privacy relay / masked email | Until disabled | User's real inbox | relay_domain (+ relay_provider) |
| Disposable / temp mail | Minutes to days | A public or throwaway host | disposable |
Plus addressing (jane+shop@gmail.com) | As long as the mailbox | Same Gmail inbox | subaddressing + normalized |
Role address (info@) | As long as the domain | Shared mailbox | role_address |
Freemail (gmail.com) | Long-lived consumer host | That provider | public_domain |
If you block relays as disposable, you reject people who chose Hide My Email on purpose. They can still reset a password. A 10-minute inbox cannot.
The local-part looks random. The domain is not the user's company. Support tickets show @privaterelay.appleid.com or @mozmail.com. That looks like abuse if your only tool is a disposable blocklist from 2019.
It is usually a privacy choice. Apple says it does not read Hide My Email message content beyond standard spam filtering, and it deletes relay copies after delivery, usually within seconds (same Support article, 2026 still the live doc). That is Apple's claim about their relay, not a reason to treat the address as fake.
Lead quality is a separate product question. A relay can still be a real customer. A disposable usually is not. Score them differently. Do not merge the flags.
GET /api/v1/emails/detect sets relay_domain when the host (or its mail infrastructure) matches a privacy-forwarding product. relay_provider is a slug such as firefox_relay, simplelogin, addy_io, duckduckgo, or protonmail. Field notes: privacy relay detection. Try an address on the relay domain lookup.
Apple Hide My Email is the case people search first. We still classify it as a relay, not as disposable. If both flags ever fire, treat disposable as the hard block.
mx_present on a relay is expected. The vendor publishes MX so the confirmation message arrives. MX is not a reason to allow a throwaway. See MX vs validation.
Block disposable. Allow or confirm relay_domain unless your threat model is "we must email a stable corporate hostname." That last case is a work-email rule, which uses public_domain, not relay_domain. @privaterelay.appleid.com is not Gmail and not a company domain.
Team exceptions belong in team email policy, not in a hardcoded includes("relay").
A vendor-issued alias that forwards to a mailbox the user already controls. Hide My Email is the Apple version.
No. The alias stays until the user deactivates it. Mail reaches their Apple Account inbox.
Only if the form requires a company hostname or you have a documented abuse pattern on that provider. Default: allow or send a confirmation link.
Classify the address. Do not grep one hostname in the browser. Apple can add hosts. EmailGuard sets relay_domain.
Same job, different operators and domains. Use relay_provider if you need a per-vendor exception.
relay_domain and relay_provider even when you allow the signup.is_bad boolean.