Role-based email addresses: should you accept info@ at sign-up?

A role-based email address belongs to a job or a function rather than a person: info@, sales@, support@, admin@, billing@, noreply@. It sits on a real company domain, so it passes a work-email check, but nobody in particular owns it. For most B2B products the right default is to let role accounts in after a second look, ask for a personal work address, and keep them out of one-to-one sales and marketing sequences.

What counts as a role address

Some role names are older than most company websites. RFC 2142, from 1997, lists standard mailbox names for common functions, among them info, sales, support, abuse, security, postmaster, hostmaster and webmaster. RFC 5321 requires every domain that accepts mail to have a postmaster address. The rest is convention: companies create billing@ because finance wants one place for invoices, and careers@ because job applications shouldn’t land in someone’s personal inbox.

The role names isBusinessEmail recognizes fall into a few groups:

Kind	Examples
Contact	info, contact, hello, enquiries, inquiries, feedback, help, mail
Sales and marketing	sales, marketing, press, media, news, newsletter
Support and service	support, helpdesk, service, customerservice
Money	billing, accounts, accounting, finance, invoices, payments, procurement
People and front office	hr, jobs, careers, reception, office
Commerce	orders, shop, store, bookings, reservations
Technical	admin, administrator, root, postmaster, hostmaster, webmaster, abuse, security, it, dev, ops
Legal and privacy	legal, privacy, gdpr, dpo, compliance
Everyone	team, all, everyone, staff
Send-only	noreply, no-reply, donotreply, do-not-reply

A role address is still a business address. info@acme.io is on Acme’s own domain, as what is a business email explains: the domain tells you the company, and the local part tells you there’s no particular person behind it. Sometimes there is one. At a two-person studio, hello@ is often the founder. That’s why a role account is a reason to look again, not a reason to reject.

Why role accounts matter at sign-up

A sign-up creates an account that someone is supposed to own. A role address blurs that in four ways.

1. No named owner. Who accepted your terms? Who gets security alerts, renewal notices and the “your trial ends tomorrow” email? With info@acme.io, the answer is whoever reads the inbox that day.
2. Shared credentials. Anyone who can read the inbox can reset the password. Teams that sign up with a role address often share one login, which makes per-person audit logs and two-factor sign-in awkward.
3. Churn when the person leaves. Onboarding emails land in a queue next to supplier invoices and job applications. The colleague who signed up knows the account exists; when they move on, nobody else does, and the account goes quiet before renewal.
4. Trials farmed by teams. One trial shared by a whole team through sales@ avoids paying for seats. A company can also start trial after trial with info@, hello@ and sales@ on the same domain. Count trials per domain, not per address; the free trial abuse playbook shows how.

A send-only address such as noreply@ is the extreme case. It exists to send mail, so your confirmation email may land somewhere nobody looks.

Why they matter in marketing

Role addresses are a known problem on marketing lists:

• Consent is unclear. One person typed marketing@acme.io into a form. Several others receive what follows and never asked for it.
• More readers, more complaints. Every reader can mark your message as spam, and complaints count against your sender reputation no matter how many others liked it.
• Some readers handle spam for a living. abuse@ and postmaster@ are read by the people who deal with spam complaints and mail problems. They’re the worst possible place to send an unsolicited newsletter.
• Platforms push back. Several email marketing platforms discourage role addresses, and some refuse them on import. Check your provider’s rules before you import a list full of info@.

Transactional mail is different. Sending invoices to billing@ or system alerts to it@ is exactly what those addresses are for. A pattern that works: a named person owns the account, and a role address is added as the billing or notification contact.

Why they matter in sales

A lead from info@acme.io gives you a real company and no person. You know the domain, its mail host and whether it runs Google Workspace or Microsoft 365, but not the person’s seniority, team or intent, and you can’t write to them by name.

That doesn’t make the lead worthless. Score it a little lower than a named contact at the same company, route it to someone who will find the right person, and use the company signals as usual. Lead scoring by email domain uses a small penalty for role accounts in its example weights, and sales routing by workspace shows how Google Workspace or Microsoft 365 detection still steers the lead.

How isBusinessEmail flags role accounts

Every email check returns is_role_account. When it’s true, reasons includes role_account. The check compares the local part, lowercased and without a +tag, with the role list. A trimmed response for a company on Google Workspace:

{
  "email": "info@acme.io",
  "category": "business",
  "is_business": true,
  "recommendation": "review",
  "is_role_account": true,
  "reasons": ["custom_domain", "mx_google_workspace", "spf_present", "dmarc_reject",
              "role_account", "shared_inbox_name"]
}

A few details worth knowing:

• It’s an exact match. Info+promo@acme.io is a role account (info once the tag is removed). sales1@, sales-eu@ and anna.sales@ are not.
• It’s set on any domain, but policies only act on it for organizations. info@gmail.com has is_role_account: true, but it’s already personal, which b2b blocks for its own reason.
• Domain-only checks return false, because there’s no local part to look at.

What each policy does

Policy	Role account on a business, education or government domain
b2b (default)	review
strict	block
lenient	allow

b2b suits most products: the company is real, so look again rather than lose it. strict fits products that need a named admin from day one, such as an integration that asks for Microsoft 365 admin consent. lenient lets role accounts through. The full mapping is in categories and policies, and every code is explained in reason codes.

How to handle review

Under b2b, review also covers unknown domains and suspected typos, so branch on is_role_account when you want role-specific handling. Two approaches work well, and you can combine them.

Ask for a personal work address. Show a hint next to the field, not an error:

This looks like a team inbox. Use your own work address so the account stays yours; you can add the team inbox for billing later.

Many people switch on the spot. The ones who don’t still get in.

Allow, but flag. Let the account in, mark it in your admin, require the confirmation email before the trial starts, and ask for a named owner during onboarding, for example as the first teammate invite.

// Server-side, with the result of POST /v1/check (secret key; fail open on errors).
function handleSignup(v) {
  if (v.recommendation === 'block') {
    return { error: 'Please use your work email so we can set up your company account.' };
  }
  if (v.is_role_account) {
    // Real company, no named person: let them in, flag it, ask for an owner.
    return { ok: true, flags: ['role_account'], ask: 'named_owner' };
  }
  if (v.recommendation === 'review') return { ok: true, flags: ['review'] };
  return { ok: true };
}

The signup form guide has the complete browser and server code, including failing open, and how to require a work email at sign-up covers the wording of every message. Test this branch with role@test.isbusinessemail.com, one of the reserved test addresses: it always returns business, is_role_account: true and review under b2b.

Role accounts vs shared inboxes and groups

isBusinessEmail also returns two related hints, shared_inbox and group. They answer a different question:

	is_role_account	shared_inbox and group
Question	Is this a function rather than a person?	Is it one mailbox a team answers from, or a list that forwards to members?
Match	Exact role name	Name rules, including variants such as support2@, sales-eu@, berlin-team@
Value	true or false	Confidence 0, 0.3 (low) or 1 (only for @googlegroups.com)
Changes recommendation	Yes, under b2b and strict	Never

They often overlap: support@acme.io is a role account and a likely shared inbox. They also differ: noreply@ is a role account without a shared-inbox hint, and berlin-team@ is a likely group but not a role account. Shared inboxes and Google Groups explains why those hints can only be low confidence, and the field reference lists every value.

Next steps

1. Decide what a role account means for your product: a named owner from day one (strict), a second look (b2b), or fine as it is (lenient).
2. Write the hint copy and the admin flag before you ship, so review has somewhere to go.
3. Test the branch with role@test.isbusinessemail.com, then get a free API key and run it against real sign-ups.