Email relay addresses: privaterelay.appleid.com, mozmail.com and duck.com explained

A relay address is a unique alias, such as x7k2p9@privaterelay.appleid.com, that forwards mail to a person’s real inbox without revealing it. Apple Hide My Email uses privaterelay.appleid.com, Firefox Relay uses mozmail.com, and DuckDuckGo Email Protection uses duck.com. A real person reads that mail, so a relay isn’t a disposable inbox. But the address says nothing about where the person works, and for B2B products that’s the part that matters.

How email relays work

A relay service sits between your product and someone’s inbox. The flow is the same for every provider:

1. The person creates an alias for your site. Often their browser, password manager or phone offers one right in your sign-up form, so it takes a single click.
2. You send mail to the alias. Confirmation emails, password resets, receipts and newsletters all go to x7k2p9@privaterelay.appleid.com.
3. The relay forwards it to the real inbox, which can be Gmail, Outlook.com, a work mailbox or anything else. Some relays also strip email trackers on the way.
4. Replies go back through the relay. When the person answers, the relay rewrites the sender, so you see the alias and never the real address. Not every service or plan supports replies.
5. The person can switch the alias off at any time. From then on your mail stops reaching them, much as if they had unsubscribed.

Because each alias is unique to one site, it also tells the person who shared or leaked their address. That’s why people use relays: less spam, and control over who can reach them.

The relay services you’ll see

These are the providers on the isBusinessEmail relay list, with the shared domains they hand out addresses on:

Service	Domains	How people get an address
Apple Hide My Email	privaterelay.appleid.com	iCloud+ on Apple devices, and Sign in with Apple for any Apple account
Firefox Relay (Mozilla)	mozmail.com, older masks on relay.firefox.com	The Relay website and browser extension; paid users can add their own subdomain of mozmail.com
DuckDuckGo Email Protection	duck.com	A personal @duck.com address, plus generated private addresses
SimpleLogin (Proton)	simplelogin.com, simplelogin.co, simplelogin.fr, aleeas.com, slmail.me, slmails.com, silomails.com	Open-source alias service, also usable with your own domain
addy.io (formerly AnonAddy)	addy.io, addymail.com, anonaddy.com, anonaddy.me	Open-source alias service with shared domains, username subdomains and custom domains
Proton Pass	passmail.net, passmail.com, passinbox.com	Aliases created in the password manager

The list also covers smaller services such as 33mail, Burner Mail, spamgourmet and erine.email. To see how a relay domain looks in a live check, open the page for duck.com.

Relay vs disposable: not the same thing

Relays often get lumped in with throwaway inboxes. They differ in every way that matters for deliverability and trust:

	Relay	Disposable
Who reads the mail	The account owner, in their real inbox	Often anyone who types the address into a public site
How long it works	Until the owner turns it off	Minutes to days
Confirmation and password-reset emails	Keep arriving	Arrive once, then the inbox is gone
Why people use it	Privacy and spam control	Avoiding giving any real address
Examples	privaterelay.appleid.com, mozmail.com, duck.com	Temporary-mail services, see the disposable domains list

A relay user is a real, reachable person who prefers not to share their address. A disposable user usually never intends to come back. The disposable email problem covers that side of the line.

Open-source disposable lists don’t always draw this line. isBusinessEmail keeps its own curated relay list, removes those domains from the upstream disposable data when it builds its lists, and gives relays a category of their own. That’s why the policies treat the two differently: disposable is blocked under every policy, while relay is allowed under lenient.

Why B2B products still care

If relays are legitimate, why not accept them everywhere? Because for a B2B product the domain is the first and cheapest piece of company information you get, and a relay removes it.

• No employer signal. jane@acme.io tells you Jane works at Acme. x7k2p9@privaterelay.appleid.com tells you she has an Apple account. You can’t enrich the lead, match it to an existing customer or score it, as lead scoring by email domain describes.
• No Google Workspace or Microsoft 365 detection. Workspace detection reads the company domain’s DNS and Microsoft’s public discovery documents. A relay domain belongs to Apple, Mozilla or DuckDuckGo, so there’s no company tenant to find, and you can’t pre-select the right connector during onboarding.
• No routing. Sales can’t assign the lead to an account owner, and features that group colleagues by domain (“three people from acme.io are already here”) have nothing to match.
• Weaker contact over time. If the person turns the alias off, your emails stop arriving, and your CRM won’t know why.

None of this makes the person suspicious. It just means the address can’t answer the questions a B2B funnel asks.

Sign in with Apple hands out relay addresses

If you offer Sign in with Apple, you’ll see relay addresses whether you planned for them or not. When someone signs in, Apple lets them share their real email or choose Hide My Email. If they hide it, your app receives a privaterelay.appleid.com address instead.

Two practical consequences:

1. Register your sending domains with Apple. Apple’s private relay only forwards mail from senders you’ve registered in your Apple Developer account. Skip this step and confirmation and password-reset emails to these users won’t arrive.
2. Check social sign-ups like any other sign-up. A B2B app that offers Apple sign-in needs the same work-email logic as “Sign in with Google”, which can just as easily return a personal @gmail.com account. Run the check in your auth provider’s sign-up hook, for example with Auth0 or Clerk.

How isBusinessEmail classifies relays

A relay address gets its own category, relay, with is_relay: true and the reason code relay_service. A trimmed response:

{
  "email": "x7k2p9@privaterelay.appleid.com",
  "domain": "privaterelay.appleid.com",
  "category": "relay",
  "is_business": false,
  "is_free_provider": false,
  "is_disposable": false,
  "is_relay": true,
  "recommendation": "block",
  "reasons": ["relay_service"],
  "workspace": {
    "google_workspace": { "detected": false },
    "microsoft_365": { "detected": false }
  }
}

A few details behind that answer:

• Precedence. When lists disagree, the order is admin override, blocked, disposable, relay, shared, education and government, then custom domain. Relay beats shared, so a relay domain is never reported as personal.
• Subdomains. The most specific domain is checked first, then its parents, so a personal subdomain such as jane.mozmail.com still matches mozmail.com.
• Custom domains. Some relays let people use their own domain. If that domain’s MX records point straight at SimpleLogin or addy.io, DNS shows it and the check still returns relay. If the domain forwards to a relay some other way, it looks like any other small custom domain and is judged on its DNS. Detection is dependable for the shared relay domains above, not for every private setup.
• No DNS needed. A relay list match is answered from the lists alone, so it’s fast, and the workspace fields stay false.

The policy you choose turns the category into a recommendation:

Category	b2b (default)	strict	lenient
relay	block	block	allow
personal	block	block	allow
disposable	block	block	block

Categories and policies has the full table, and reason codes lists every code the API returns.

What to do with relay sign-ups

The right answer depends on what your product needs from the address.

Consumer and freemium products: allow them

If you don’t need to know the person’s company, use the lenient policy. Relay users get in, and disposable and invalid addresses are still blocked. Relay users are often your most privacy-aware customers, and turning them away buys you nothing.

B2B products: ask for a work address, kindly

If your product needs a company domain, ask for a work email and say why, in terms of what the person gets:

Relay addresses can’t be linked to your company. Please use your work email so we can connect your team’s account.

Don’t call the address fake, and don’t imply they did something wrong. Many people use a relay out of habit, the same way others type their personal Gmail address. How to require a work email at sign-up covers the wording, the browser hint and the server-side check.

A softer option is to let relay users in and ask for the work address later, at the moment it matters: creating a team workspace, inviting colleagues or connecting Google Workspace. You keep the sign-up and still learn the company when you need it.

Your own rule: decide from the category

Policies are deliberately simple. If you want something in between, such as “accept relays on the personal plan, ask for a work email on team plans”, call the API and decide from the flags yourself:

async function signupDecision(email, plan) {
  try {
    const res = await fetch('https://api.isbusinessemail.com/v1/check', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${process.env.IBE_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ email, policy: 'lenient' }),
      signal: AbortSignal.timeout(2500),
    });
    if (!res.ok) return 'allow'; // fail open, re-check later
    const r = await res.json();
    if (r.recommendation === 'block') return 'block'; // disposable, invalid or blocked
    if (r.is_relay && plan === 'team') return 'ask_for_work_email';
    return 'allow';
  } catch {
    return 'allow';
  }
}

Never treat a relay as fraud by default

A relay hides an address, not an identity. The person can receive your mail and confirm their account like anyone else. If you’re fighting trial abuse, look at signals that actually point to it: disposable domains, brand-new domains, repeated sign-ups and usage patterns. The email signals behind free-trial abuse goes through them. And keep in mind that a classifier tells you what kind of address it is, not whether the mailbox exists; email verification vs classification explains the difference.

Next steps

1. Decide what a relay gets in your product: allow, ask for a work email at sign-up, or allow now and ask later.
2. If you offer Sign in with Apple, register your sending domains with Apple and run the same check on Apple sign-ups.
3. Store category on every account, so you can see how relay sign-ups activate and convert before you tighten anything.
4. Test the branch with relay@test.isbusinessemail.com, one of the reserved test addresses that return fixed answers and never count against your quota.

Then get a free API key and add the check to your sign-up flow.