Apple Hide My Email, Firefox Relay and SimpleLogin are not disposable email

Email relay services like Apple Hide My Email, Firefox Relay, DuckDuckGo Email Protection and SimpleLogin are not disposable email. A relay address forwards to a real inbox that belongs to a real, identified account holder, it stays active until that person turns it off, and it can usually receive your password resets for years. A disposable address is a public or throwaway inbox with no owner you could ever reach again. Treat relay addresses like any other personal email address, and be aware that many signup filters, including naive randomness checks, will wrongly flag them.

The confusion is understandable. Both produce addresses you've never seen at domains that aren't Gmail, and relay addresses often look like a cat walked across a keyboard. But the property you care about at signup is "can I reach this person later?", and for relays the answer is yes.

What each relay service actually is

A few specifics from the vendors' own documentation:

• Apple's support page on Sign in with Apple says Hide My Email addresses created there use the domain @privaterelay.appleid.com, and that "only the app or website you created the account with can use this unique email address to communicate with you." Mail from any other sender won't get through.
• Apple's iCloud+ Hide My Email guide says subscribers can "create as many addresses as you need" and "deactivate or delete addresses you no longer use."
• DuckDuckGo's help pages describe deactivating and reactivating private Duck Addresses, and note that older private addresses used a randomized-characters format such as avtzqdr@duck.com, which still works.
• SimpleLogin is now "SimpleLogin by Proton" and offers several shared alias domains plus bring-your-own domains. The set of shared domains has changed over time, so pull the current list from your own SimpleLogin account rather than hard-coding one from a blog post (including this one).

Why relays are not disposable

Disposable services like Mailinator or 10 Minute Mail give anyone an inbox with no sign-up, or one that expires after a few minutes. Our explainer on disposable email addresses goes through how they work. Three differences matter for your signup policy:

Ownership. A relay address maps to exactly one account at Apple, Mozilla, DuckDuckGo or Proton. A disposable inbox maps to nobody; often anyone who types the same name can read it.

Lifetime. A relay address lives until the user deactivates it. Disposable addresses are designed to vanish.

Reachability. Your onboarding emails, receipts and password resets land in the user's real inbox. With disposable email, they land somewhere nobody will ever check again.

The community disposable-email-domains blocklist reflects this: at the time of writing, privaterelay.appleid.com, mozmail.com and duck.com are not on it. Our own lists agree. duck.com sits in our free email provider category alongside Gmail and Proton, since it's a personal address that reaches a real person.

Why filters still misfire on relays

Category lists get relays right. Heuristics on the local part often get them wrong, and we'll be specific about our own behavior here.

Relay services generate addresses designed to be unguessable. dpdcnf87nb@privaterelay.appleid.com has no vowels in sensible places, a digit run in the middle and a long consonant cluster. Any randomness detector built to catch bot-generated addresses will score that as machine-generated, because it is. A machine generated it on behalf of a human.

When we ran that exact address through pingutil's fast mode, the result was:

{
  "domain": "appleid.com",
  "category": "company",
  "email_signals": { "is_randomized": true, "randomness_score": 100 },
  "verdict": { "is_spam": true, "low_trust": false, "reason": "randomized_local_part" }
}

Two things to notice. The registrable domain collapses privaterelay.appleid.com to appleid.com (that's the eTLD+1 rule, explained in why mail.stripe.com is stripe.com), so a filter keyed on the registrable domain can't distinguish relay mail from anything else at Apple. And verdict.is_spam is true because of the randomized local part. A random-looking @mozmail.com mask gets the same verdict.

That's a false positive you should handle in your code. The fix is to check for relay hosts before you act on the verdict. How the randomness check works and where else it misfires is covered in detecting machine-generated email addresses.

Allow relays explicitly

Match on the full hostname, not the registrable domain, and run the relay check first:

const RELAY_HOSTS = ['privaterelay.appleid.com', 'mozmail.com', 'duck.com'];
// Add your SimpleLogin shared domains here after checking your account's list.

function isRelayAddress(email: string): boolean {
  const host = email.trim().toLowerCase().split('@')[1] ?? '';
  return RELAY_HOSTS.some((r) => host === r || host.endsWith(`.${r}`));
}

export async function screenSignupEmail(email: string) {
  const res = await fetch('https://pingutil.com/v1/lookup', {
    method: 'POST',
    headers: {
      authorization: `Bearer ${process.env.PINGUTIL_KEY}`,
      'content-type': 'application/json',
    },
    body: JSON.stringify({ input: email, skip_enrichment: true }),
  });
  if (!res.ok) return { allow: true, relay: isRelayAddress(email), reason: null };
  const data = await res.json();

  if (isRelayAddress(email)) {
    // A relay forwards to a real inbox. Ignore randomness, keep the relay flag.
    return { allow: true, relay: true, reason: null };
  }
  if (data.verdict.is_spam) {
    return { allow: false, relay: false, reason: data.verdict.reason };
  }
  return { allow: true, relay: false, reason: data.verdict.reason };
}

The endsWith check covers Firefox Relay premium subdomains like shop@yourname.mozmail.com. Keep the relay flag on the user record. You'll want it later.

What relays do change

Relay addresses are legitimate, and they still change a few things you should plan for.

Multiple accounts are cheap. A user with iCloud+ can create as many addresses as they want, and a Firefox Relay or DuckDuckGo user can make a new one in a click. That's the same problem as Gmail plus addressing, and you can't normalize your way out of it because each relay address is a distinct, opaque string. If one account per person matters (free trials, referral bonuses), enforce it with something other than the email: a payment fingerprint, a phone number for high-value actions, or usage caps. Stopping free-trial abuse covers that approach.

Addresses can go dark. If the user deactivates the address, your mail stops arriving, and depending on the service, it may be silently dropped rather than bounced. Watch engagement on relay users rather than relying only on bounces, and let users change their email address easily. For Sign in with Apple, register the server-to-server notification endpoint described in the same Apple guide: it fires when a user changes their email forwarding preferences.

Sign in with Apple addresses are scoped to you. Apple's relay only forwards mail from senders you've registered. Apple's guide to configuring your environment for Sign in with Apple covers registering your outbound email domains as sources for the Private Email Relay Service. If your email provider sends from a domain or return-path you didn't register, mail to these users isn't delivered, and Apple emails your developer team about the undelivered messages. Fix that in your Apple developer settings; the user did nothing wrong.

Company enrichment won't work. A relay hides the user's employer by design. Don't treat appleid.com or mozmail.com as a company lead, and don't run enrichment on them. If B2B qualification matters, ask for a company name in onboarding.

The policy we'd recommend

1. Never block relay hosts at signup.
2. Check relay hosts before acting on any randomness-based verdict.
3. Store an is_relay flag and exclude relay users from company enrichment and lead scoring.
4. Enforce one-trial-per-person limits with signals other than the email address.
5. Make changing the account email easy, because relay addresses do get turned off.

If you want to see how a specific address is classified before deciding, run it through the live demo.