How to require a work email at sign-up (without losing good users)

To require a work email at sign-up, check the address when the form is submitted, block or flag the kinds of address you don’t want (personal providers such as gmail.com, disposable inboxes, privacy relays), and show a short message next to the field that explains why. The check is the easy part. The real work is keeping the people you want: buyers who typed their personal address out of habit, founders without a company domain yet, and anyone who mistyped gmail.com.

This post is about the how. If you are still deciding whether to require a work email at all, read Should B2B SaaS block free email signups? first.

Decide what happens to each kind of address

“Require a work email” sounds like one rule. It’s really a decision per category, with three possible outcomes: allow, review (let them in, but look again) and block (stop the sign-up and explain).

What signed up	Lenient	Standard B2B	Strict
Business: the company’s own domain	allow	allow	allow
Education or government	allow	allow	allow
Role account (info@, sales@) on an allowed domain	allow	review	block
Unknown: too little evidence, such as a brand-new domain	allow	review	block
Personal: gmail.com, outlook.com, ISP mail	allow	block	block
Relay: Hide My Email, Firefox Relay, DuckDuckGo	allow	block	block
Disposable or invalid	block	block	block

The middle column suits most B2B products. Move right if your product can’t work without a company tenant, such as an integration that needs Microsoft 365 admin consent, or if free trials carry real abuse costs. Move left if individuals are a real way into the companies you sell to.

If you use isBusinessEmail, the three columns are the lenient, b2b (default) and strict policies, and the API returns the outcome as recommendation. Categories and policies has the exact mapping, and business email vs personal email explains why the line sits between custom and shared domains.

What review looks like in practice

Review is the lane that protects you from false positives. Role accounts and unknown domains are probably fine, so don’t block them. Pick one of these instead:

1. Let them in and flag the account in your admin.
2. Require the confirmation email before the trial starts.
3. Hold back expensive features, or shorten the trial, until someone has looked.
4. Ask one extra question, such as the company website.

Check twice: a hint in the browser, the decision on the server

A good setup checks in two places, for different reasons.

In the browser, check when the field loses focus (on blur), not on every keystroke, and show a hint right under the field. This is a courtesy. People see the problem before they submit, and many switch to their work address on the spot. With isBusinessEmail, use a publishable key restricted to your sign-up page’s origin; it gets a reduced response that includes category, recommendation and did_you_mean.

On the server, check again at submit with a secret key. That is the real decision. Anyone can skip your JavaScript, so the browser hint never enforces anything.

// Decide at submit. If the check is slow or down, let the sign-up through.
async function checkWorkEmail(email) {
  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: 'b2b' }),
      signal: AbortSignal.timeout(2500),
    });
    if (!res.ok) return { recommendation: 'allow', failOpen: true };
    return await res.json();
  } catch {
    return { recommendation: 'allow', failOpen: true };
  }
}

Return a field-level error for block, flag the account for review (and for failOpen), and store category on the user either way. The signup form guide has the complete browser and server code, and checking for a business email in code has the same check in JavaScript, Python and PHP.

If sign-up runs through an auth provider, put the check in its pre-registration step or in front of its sign-up call. See Auth0, Clerk or Firebase Auth. “Sign in with Google” can be a personal @gmail.com account, so social sign-ups need the same check.

Write error messages people accept

The message decides whether a blocked person switches address or leaves. Four rules:

1. Label the field “Work email” before anyone types. Many people switch without ever seeing an error.
2. Explain why, in terms of what they get: “so we can connect your Google Workspace”, “so your teammates can join automatically”.
3. Don’t accuse. “Please use your work email” beats “Personal emails are not allowed”.
4. Keep it next to the field. Keep what they typed, and announce the message to screen readers with aria-live="polite".

Copy you can adapt:

Category	Message
personal	Please use your work email so we can connect your company account.
disposable	Temporary inboxes can’t receive our setup emails. Please use your work email.
relay	Relay addresses can’t be linked to your company. Please use your work email.
invalid	This address can’t receive email. Please check it for typos.
Role account (review)	No error. Optional hint: “Using a shared inbox? Your own work address keeps the account yours.”

Offer typo fixes: “Did you mean gmail.com?”

Some rejected addresses are just typos: jane@gmial.com, jane@hotmail.con, jane@outlok.com. Rejecting them is unhelpful. Accepting them is worse: the confirmation email never arrives, and the person assumes your product is broken.

Typo suggestions usually work like this:

• Compare the domain with popular providers. One edit away (a missing, extra, swapped or wrong letter) is a likely typo. Longer names with the same ending can allow two edits.
• Fix common ending slips, such as .con or .cmo for .com.
• Catch lookalikes separately: domains that imitate a provider with confusable characters, such as a Cyrillic о in place of a Latin o, or a 0 for an o.
• Skip the suggestion for real organizations. Some company domains are one letter away from a provider, and their DNS shows it, for example Google Workspace or Microsoft 365 mail.

isBusinessEmail does all of this. did_you_mean holds the suggested domain (gmail.com for jane@gmial.com) with the reason typo_suspected, or lookalike_domain with is_lookalike: true for confusable characters. Under the b2b policy, an address flagged as a typo or lookalike never gets a plain allow.

Then show it the right way:

1. Show the suggestion as a button: “Did you mean gmail.com?”
2. Never correct silently. The person may have typed exactly what they meant.
3. Check again after they accept. On a work-email form, jane@gmail.com then gets the personal-address hint, which still beats an account nobody can reach.

Typos in a company domain, such as acme.oi, aren’t covered by provider lists. They usually come back invalid, because the mistyped domain doesn’t exist or can’t receive mail, and the “check it for typos” message handles them. Typos in the name part (jnae@acme.io) look valid to any classifier; only a confirmation email catches those, as email verification vs email classification explains.

Plan the exceptions

Every rule has legitimate exceptions. Plan them up front, or support will invent them one ticket at a time.

• An escape hatch. Under the error, add “No work email? Request access.” Send it to a person or a waitlist. You keep founders, freelancers and researchers, and abuse doesn’t scale through a manual form.
• Invitations. When a teammate invites someone, the inviter vouches for them. Consider skipping the work-email rule for invite links.
• Your own allow-list. Keep a short list of approved domains and addresses (partners, agencies, customers with unusual setups) in your own database, and check it before any API call. Keep your own blocklist there too.
• Education and government. .edu, .ac.uk, .gov and similar are institutions’ own domains, and every isBusinessEmail policy allows them. Decide whether that fits your product.
• Freelancers on their own domain already pass. A one-person consultancy on jane-consulting.com is a business address.
• Gate features, not sign-up. Let anyone in, but require a work account to create a team workspace or connect Microsoft 365. The onboarding integrations playbook uses Workspace and Microsoft 365 detection to pre-select the right connector.
• Sign in with Apple can hand you a relay address (…@privaterelay.appleid.com) by design. If you offer it on a B2B product, decide whether relays are acceptable there.

If a verdict is wrong for a domain, report it. isBusinessEmail has a feedback endpoint, and a person reviews every report before any list changes.

Fail open

Your sign-up must never depend on a third party being up. If the check is slow, rate-limited or failing, let the person in, flag the account and check again later.

Situation	What to do
Timeout (2–3 s) or network error	Allow, flag the account, re-check in a background job
429 (rate limit or daily quota)	Allow and flag; alert if it keeps happening
5xx	Allow and flag
401 or 403	Allow, and alert your on-call: it’s a key or configuration problem
degraded: true in the response	Trust block for list matches; treat review as allow and re-check later

The background job is short: re-run the check for flagged accounts and act on the result, for example by routing them to sales or limiting the trial. Limits and quotas per tier are in rate limits.

Measure the impact

A work-email rule is a product change, so measure it like one.

1. Store the verdict on every account: category, the recommendation, and the workspace result if you sell integrations.
2. Track the field itself: how often the hint appears, how often people then switch to a work address, how often they abandon the form, and how many access requests arrive.
3. Compare by category after a few weeks: activation, retention, conversion to paid, support tickets and abuse incidents.
4. Test one change at a time. A hint versus no hint, or a soft hint versus a hard block, tells you more than a before-and-after comparison, because campaigns and seasons move sign-ups too.
5. Look again after pricing or product changes. The right policy can move.

If personal-address sign-ups rarely convert and cost support time, tighten toward strict. If they convert nearly as well as business addresses, stay on b2b or lenient and use the category for routing instead, as in the B2B lead qualification playbook.

Putting it together

1. Label the field “Work email”.
2. Pick an outcome per category: allow, review or block.
3. Hint in the browser on blur; decide on the server with a secret key.
4. Offer did_you_mean as a one-click fix, and never auto-correct.
5. Explain the benefit in every message, and add a request-access link.
6. Fail open, flag the account, re-check in the background.
7. Store the category and compare cohorts before tightening.

Before you ship, test every branch with the reserved test addresses: personal@test.isbusinessemail.com should show your personal-address message, role@test.isbusinessemail.com should land in review, and business@test.isbusinessemail.com should go straight through. Then get a free API key, or read the block free emails at signup playbook for the short version.