Skip to main content

Hide My Email and duck.com at signup: allow privacy relay emails?

· 5 min read
Signitize
Signitize
Email checks for signup forms

k7x2m9qp4z@privaterelay.appleid.com, quiet-fox@duck.com, wy3hd8@mozmail.com. These look like throwaway addresses, and many signup forms treat them that way. They are not: each one forwards to a real, long-lived inbox owned by a real person who simply doesn't want to hand out their main address.

So should you block them? Usually not. But they do have one property that matters for free trials, and it's worth handling on purpose.

What a privacy relay is​

A relay service gives the user a random or chosen address on its own domain. Mail sent there is forwarded to the user's real inbox, and the user can switch the address off at any time.

ServiceTypical addressHow people get it
Apple Hide My Email…@privaterelay.appleid.comSign in with Apple, or iCloud+ Hide My Email
DuckDuckGo Email Protection…@duck.comDuckDuckGo browser extension and apps
Firefox Relay…@mozmail.comMozilla account, Firefox extension
SimpleLogin (Proton)…@simplelogin.com, …@aleeas.com and othersProton accounts, browser extension
addy.io (AnonAddy)…@anonaddy.me, …@addy.io and othersBrowser extension, custom domains

The people who use them are privacy-minded, often technical, and often exactly the early adopters a developer tool or SaaS wants.

Relay is not disposable​

The difference matters for your rules:

  • A disposable address (yopmail, mailinator, 10minutemail) is a public inbox anyone can read. It exists to receive one confirmation email and be forgotten. Nobody will ever read your invoice there.
  • A relay address reaches the owner for as long as they keep it. Password resets, receipts and product emails all arrive.

If you block every address that "looks generated", you block both, and you lose real customers to stop fake ones.

If you offer Sign in with Apple, you can't block them​

When a user picks Hide My Email during Sign in with Apple, Apple gives your app an address on privaterelay.appleid.com. That is the only email you receive for that user. Reject relay addresses and every Apple user who chose privacy can't sign up at all, through a button you put on the page yourself.

The same goes, on a smaller scale, for users of the DuckDuckGo and Firefox extensions: their browser fills in the relay address for them, and many never think about it.

The real risk: unlimited addresses that can't be linked​

The one thing that makes relays different from a normal Gmail account is how cheap new addresses are. One person can create a new relay address in two clicks, and nothing in the address links it to their other ones. quiet-fox@duck.com and brave-owl@duck.com may be the same person, and no normalization rule can tell.

With Gmail, john+1@gmail.com and j.o.h.n@gmail.com collapse to one canonical inbox, so a unique column stops the second account (how that works). With relays, the duplicate check has nothing to work with.

That only matters if a new account is worth something on its own: free credits, a trial with real cost to you, a referral bonus.

A practical policy​

  1. Accept relay signups. They are real people with working inboxes.
  2. Require the verification email, as for every signup. It proves the relay works and reaches someone.
  3. Hold back the expensive perks for relay accounts until they show something else: a payment method on file, a phone check, or a few days of normal use.
  4. Don't label them as suspicious in your UI. A message like "Use your real email" drives away exactly the users who chose privacy on purpose.

For a product with a cheap free tier, step 3 is optional. For an AI tool that gives away $5 of compute per account, it isn't.

Detecting relay addresses​

The domain gives most of it away, but the list moves: services add domains, and some let users bring their own domain, whose mail still flows through the relay. Signitize returns a separate relay flag and the service behind it, in the same call as the disposable and duplicate checks:

curl https://api.signitize.io/v1/check \
  -H "Authorization: Bearer $SIGNITIZE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"quiet-fox@duck.com"}'
{
    "email": "quiet-fox@duck.com",
    "disposable": false,
    "deliverable": true,
    "relay": true,
    "provider": "duckduckgo",
    "found": 0,
    "registration": null,
    "alias": []
}

relay and disposable are never both true, so the two rules stay separate:

const result = await checkEmail(email)

if (result.disposable) {
    return reject('Please use a permanent email address.')
}
if (!result.deliverable) {
    return reject('This email address cannot receive mail. Please check it for typos.')
}

const user = await createUser({
    email,
    emailCanonical: result.email,
    // relay users get the account now, the free credits after verification and a second signal
    creditsOnVerify: result.relay ? 0 : FREE_CREDITS,
})

The full field list is in Check an email.

One blind spot to know about​

iCloud+ Hide My Email can also create addresses on plain @icloud.com. Those look exactly like a normal iCloud address and can't be told apart from outside. Only privaterelay.appleid.com is recognizable. Treat that as a reason to build your perks policy around verification and behavior, not around a perfect relay list.

Summary​

  • Relay addresses forward to real inboxes: allow them.
  • Blocking them breaks Sign in with Apple for users who chose Hide My Email.
  • Their risk is unlimited, unlinkable addresses, so hold back valuable free perks, not the account.
  • Keep relay and disposable as two different rules.

Get a free API key (2,500 checks a month, no card) and try your own relay address in the Quickstart. For the wider picture of free-tier abuse, see 7 ways people farm your free tier.