Role-based email addresses (info@, sales@): what to do with them

Role-based addresses like info@, support@ and sales@ belong to a function, not a person: they deliver to a shared inbox or a group, and whoever reads them changes over time. Don't block them by default. Accept them at signup, flag them for review on B2B lead forms, keep them off imported marketing lists unless they opted in themselves, and be strict only with system addresses like noreply@ that nobody reads.

The rest of this post explains why each context gets a different rule, and how to detect role addresses without the substring bugs that flag half your real users.

Where the names come from

Many of these names were standardized decades ago. RFC 2142 (1997) lists mailbox names organizations are expected to support: INFO, MARKETING, SALES and SUPPORT for business functions, ABUSE, NOC and SECURITY for network operations, and service mailboxes like POSTMASTER, HOSTMASTER and WEBMASTER. postmaster is mandatory for any mail server that accepts mail, per RFC 5321 section 4.5.1.

Everything else (hello@, team@, careers@, billing@) is convention. That matters for detection: there is no authoritative list, so every tool's list is somebody's judgment call.

Three kinds of non-personal address

Lumping them together causes bad policy. In practice there are three groups, and they deserve different treatment.

The third group is worth separating. When sales@somevendor.com requests a demo of your product, there's a decent chance the request is the start of a cold pitch. That's not abuse, but it shouldn't be routed to your best account executive either.

What to do with them, by context

Product signups

Accept role addresses. A three-person agency running everything from hello@agency.com is a real customer, and for a lot of small businesses that address is the only one they have. Blocking it fails them for no gain.

What you should do is think about account security. A shared inbox means anyone with access to it can reset the password. If your product holds sensitive data, nudge the user toward a personal login: "You signed up with a shared address. Invite teammates with their own emails so each person has their own login." That's a product improvement, not a block.

System addresses are different. If someone signs up as noreply@company.com, either the confirmation email goes nowhere, or a script is doing the signing up. Reject or require extra verification.

B2B lead and demo forms

Accept, then route. A demo request from info@ is a real lead with an unclear contact, so the useful move is to ask for a name and direct email in the follow-up, or add an optional "your direct email" field when a role address is detected. Send sales@ and marketing@ requests to a lower-priority queue. If you route by company size or industry, do that on the domain as normal; the role local part doesn't change who the company is. See routing inbound leads by company size.

Marketing lists

This is where role addresses hurt you. Many ESPs restrict them because, in Mailchimp's words, they're "associated with high bounce rates and spam complaints". Mailchimp's policy blocks a specific list of role prefixes (abuse@, admin@, noreply@, postmaster@, support@, webmaster@ and others) on import, but lets those addresses subscribe through a signup form. Notably, info@ and sales@ are not on that list.

The logic is sound and worth copying: a role address that opted in itself is fine; a role address you bought, scraped or imported is someone else's inbox you're mailing without consent. Use double opt-in for role addresses on newsletters, even if you use single opt-in elsewhere.

Transactional email

Send it. Invoices to billing@ and alerts to ops@ are exactly what those inboxes are for. The only thing to avoid is sending password reset links for a personal account to a shared inbox, which brings us back to the signup advice.

Detecting role addresses without false positives

The common bug is substring matching. Check whether the local part contains hr and you flag chris@ and shreya@. Check for sales and you flag rosales@. Check for admin and you flag badminton.fan@. Substring rules on short tokens are wrong for real names in most languages.

Use exact matching after a little normalization:

1. Lowercase the local part.
2. Drop any +tag (support+zendesk@ is still support@).
3. Compare the result against a set, keeping separators, so no-reply and noreply are both listed explicitly.
4. Optionally allow a role word followed by a separator (support.eu@, jobs-uk@), but never a role word followed by letters.

const ROLE = new Set([
  'info', 'admin', 'support', 'contact', 'hello', 'help', 'team', 'office',
  'mail', 'enquiries', 'inquiries', 'feedback', 'webmaster', 'hr', 'billing',
  'careers', 'jobs', 'recruiting', 'abuse', 'security',
]);
const SYSTEM = new Set([
  'noreply', 'no-reply', 'donotreply', 'do-not-reply', 'mailer-daemon',
  'postmaster', 'bounce', 'bounces', 'notifications', 'hostmaster',
]);
const SALES = new Set(['sales', 'marketing', 'outreach', 'leads', 'partnerships', 'bd']);

export function classifyLocalPart(email) {
  const local = email.slice(0, email.lastIndexOf('@')).toLowerCase();
  const base = local.split('+')[0];
  // "support.eu" or "jobs-uk" -> check the first segment too, never a bare prefix
  const head = base.split(/[._-]/)[0];
  const hit = (set) => set.has(base) || (head !== base && set.has(head));

  if (hit(SYSTEM)) return 'system';
  if (hit(SALES)) return 'sales';
  if (hit(ROLE)) return 'role';
  return 'personal';
}

classifyLocalPart('Support+Zendesk@acme.com'); // 'role'
classifyLocalPart('chris@acme.com');           // 'personal'
classifyLocalPart('no-reply@acme.com');        // 'system'
classifyLocalPart('rosales@acme.com');         // 'personal'

The head rule has one known cost: mail.room@ becomes a role address. Decide whether that trade is worth it for your data; if you're unsure, drop the head check and match only exact bases.

Give role detection less weight on free webmail domains. On gmail.com, a handle like support.jane@ is one person's username, not a team inbox.

How pingutil reports it

pingutil runs the same kind of exact-match check and returns it in two places. email_signals has three booleans: is_role_based, is_system_generated and is_sales_outreach. verdict turns them into a decision: any of the three sets low_trust: true with reason set to role_based, system_generated or sales_outreach, and is_spam stays false. Separately, meta.local_part_role gives a normalized label (careers@ comes back as hr, no-reply@ as noreply) for routing.

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, skip_enrichment: true }),
});
const { verdict } = await res.json();

if (verdict.is_spam) return reject();                       // disposable or randomized
if (verdict.reason === 'system_generated') return requireExtraVerification();
if (verdict.reason === 'sales_outreach') return accept({ queue: 'low-priority' });
if (verdict.reason === 'role_based') return accept({ askForDirectContact: true });
return accept();

skip_enrichment: true keeps this to a fast, LLM-free check. You can try addresses in the live demo before wiring it up, and the full field list is in the API reference.

Like any word list, ours is incomplete in both directions. ops@ and accounts@ aren't on it; a person who genuinely goes by Jobs would be flagged. That's why it sets low_trust and never is_spam. If you're combining this with other signals into a score, building a simple email risk score from free signals shows how much weight it deserves (not much).

The policy, in five lines

• Product signup: accept role addresses, nudge toward personal logins, reject or challenge system addresses.
• B2B forms: accept, ask for a direct contact, send sales/outreach addresses to a separate queue.
• Marketing: only mail role addresses that opted in themselves, with double opt-in.
• Transactional: send normally, but keep personal password resets out of shared inboxes where you can.
• Detection: exact match after stripping +tags, never substrings.

If a role address shows up alongside other red flags, it's the other flags that matter. On its own, info@ is just a small business answering its email.