Should your B2B signup form require a work email?

For most B2B products, no: ask for a work email, accept personal ones, and use the email domain to decide what happens next. A hard work-email requirement makes sense in a narrow case: a sales-led product where every signup costs a rep's time and there's no self-serve path. Everywhere else it filters on the wrong thing. It checks the domain, not the intent, and it turns away the founders, freelancers and quiet evaluators who often sign up with Gmail first.

Here's how to decide for your funnel, and how to build the middle option.

What a work-email gate actually filters

A rule like "reject gmail.com, outlook.com, yahoo.com..." looks like a lead-quality filter. In practice it removes several groups that are hard to see in a dashboard:

• Founders, freelancers and agencies who run their business from a personal address. They're often the buyer, not just a user.
• Employees evaluating quietly. Plenty of people try a tool on a personal address before they put their work identity, or their IT team, anywhere near it.
• People whose employer is on a webmail domain they don't consider "work". Lots of small shops, clinics and trades businesses run on Gmail or Outlook.com.
• Academics and public sector staff, if your rule is "company domains only" rather than "not webmail".

And it doesn't stop much. Anyone with a job has a work address, including people who'll never buy. Anyone who wants in badly enough types a colleague's address, registers a cheap domain, or picks a mail.com vanity domain like consultant.com that most free-provider lists don't include (details in free email provider domains).

The gate's real effect is to move people from "signed up with Gmail" to "didn't sign up". You'll never get a support ticket about it, which is why it looks free.

When requiring a work email does make sense

The last row is worth a second look. If your product lets anyone with @acme.com join Acme's workspace, the domain is doing access control, and it must be a company domain the user has verified. That's a rule about joining a workspace, not about creating an account. A person can sign up with Gmail and still be invited into Acme's workspace by an admin.

The middle option: ask, don't require

You can get most of the routing benefit with none of the lost signups. The pattern:

1. Label the field "Work email". Many people will use their work address because you asked.
2. Accept anything that isn't throwaway. Disposable addresses are a separate decision, covered in should you block disposable emails or just flag them.
3. If the address is personal, show one optional field: "Company name or website". Don't make it required. Don't show it to company-domain users, who've already told you.
4. Route on the server by email category, not on the form.
5. Re-route later. When a personal-email account invites someone from a company domain, that domain becomes the account's company. Spotting multiple signups from the same company covers how to detect that.

How to classify the address in the first place (webmail lists, registrable domains, MX checks for personal custom domains) is in how to tell a business email from a personal one in code.

Routing a signup by email category

This sketch uses pingutil's lookup. It runs after the account is created, in a background job, because a full lookup on a never-seen company domain triggers enrichment and can take a few seconds. The fast screening check (with skip_enrichment: true) can run inline on the form if you need to reject throwaway addresses before creating the account.

type Route = 'sales' | 'self_serve' | 'education' | 'public_sector' | 'review';

interface RoutingDecision {
  route: Route;
  reason: string;
  companyName?: string | null;
  employeeSize?: string | null;
  askForCompany?: boolean;
}

export async function routeSignup(email: string, companyHint?: string): Promise<RoutingDecision> {
  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 }), // full lookup: includes company data
  });
  if (!res.ok) return { route: 'self_serve', reason: 'lookup_failed' };
  const data = await res.json();

  if (data.verdict.is_spam) return { route: 'review', reason: data.verdict.reason };

  switch (data.category) {
    case 'company':
      return {
        route: data.verdict.low_trust ? 'review' : 'sales', // e.g. info@ or sales@ addresses
        reason: data.verdict.low_trust ? data.verdict.reason : 'company_domain',
        companyName: data.company?.name ?? null,
        employeeSize: data.company?.employee_size_estimate ?? null,
      };
    case 'educational':
      return { route: 'education', reason: 'educational_domain' };
    case 'government':
      return { route: 'public_sector', reason: 'government_domain' };
    default: // free, isp, unknown
      return { route: 'self_serve', reason: data.category, askForCompany: !companyHint };
  }
}

"Sales" here is a starting point. Most teams then split company-domain signups further by size or industry, using company.employee_size_estimate and company.industry; routing inbound leads by company size and industry goes through that. Treat the company profile as a good guess: it's generated by an LLM, company.confidence is the model's own estimate, and small or new companies get thinner profiles.

If you do require a work email, do it carefully

Sometimes the table above says "require it". In that case:

• Explain the rule in the error. "We only set up accounts for company email addresses. If your company uses Gmail, contact us and we'll get you started." Give a real address or a form, and make sure someone reads it.
• Never say "invalid email". The address is valid, and the user knows it.
• Allow ISP and education addresses deliberately or reject them deliberately. Make it a decision, not an accident of whichever list you copied.
• Enforce on the server. If you use a hosted form builder, check its behaviour. HubSpot, for example, has a Block free email providers option that is set per form, so a new form won't inherit it.
• Keep a manual override for sales to whitelist a domain without an engineer.

Measure it before you decide

If you already accept personal addresses, you have the data to settle this for your product. Tag every signup with its email category (company, free, isp, educational, government), then look at the last two or three quarters:

• What share of paying accounts started with a personal address?
• What share of revenue came from those accounts?
• How long did personal-address accounts take to convert compared with company-domain accounts?

If personal-address signups are a meaningful share of your paying customers, a work-email requirement would have turned many of them away at the form. If they're close to zero and your sales team is drowning in unqualified demos, requiring a work email on the demo form, and only there, is a reasonable call.

The default we'd ship

• Field labelled "Work email", personal addresses accepted.
• Disposable addresses handled by a separate policy.
• Optional "Company name or website" shown only for personal addresses.
• Server-side routing by email category: company to sales or sales-assist, personal to self-serve, education and government to their own tracks.
• Re-route when a personal account invites a company-domain teammate.
• A hard requirement only on demo forms or enterprise-only products, with a human escape hatch.