Role-Based Emails: Send or Skip?

Skip role-based emails when you are writing to a named buyer. Send to them only when the role itself is the buyer, and keep that send small.

A role-based address such as info@acme.com belongs to a function, not a person. That one fact drives every rule below.

Key takeaways

• Skip role addresses in cold sequences that open with "Hi Jane". Nobody named Jane reads that inbox.
• Send only when the shared mailbox is the real route in: a tiny company, a procurement desk, or a partnership alias.
• Never mix role addresses into a list you score for deliverability. They distort bounce and complaint numbers.
• LeadOcean tags them with email_status: role, and its default count already leaves them out.

What it is

A role-based email address is a mailbox named for a job function or service, such as info@, sales@ or support@, that several people can read.

RFC 2142 (checked September 2026) reserves standard mailbox names for common services and roles, such as postmaster@, abuse@, info@, sales@ and support@. That is why these addresses exist at almost every domain.

Companies run them on purpose. A shared inbox lets a team cover absences and keeps customer mail out of one person's account.

How it works

A role address is routed, not owned. The steps below show what happens to a cold email sent to one.

1. Your email reaches the mail server for the domain and is accepted, because the mailbox exists.
2. The server delivers it to a shared inbox, a ticketing tool or a forwarding list.
3. Whoever is on rotation, or a filter, sees a subject line from a stranger.
4. The message gets archived, marked as spam, or forwarded to the wrong team.
5. The mark-as-spam action is the costly one. It trains the filter against your sending domain.

Here is a worked example. You email jane.doe@acme.com and info@acme.com with the same pitch.

The first lands in one person's inbox, and she can reply or ignore it. The second lands in a queue read by five people, and any one of them can hit the spam button.

You can spot most role addresses by the part before the @. Common local parts are info, sales, support, admin, contact, hello, office, billing, jobs and marketing. A name with a dot or an initial, such as jane.doe, is almost always personal.

Pattern matching misses some. A mailbox called team@ or press@ is a role address too, and a person can have a first name that looks like a function. Use a status field from your data source when you can, and a local-part list as a backstop.

A verifier will usually pass both. The mailbox exists in each case, so "deliverable" tells you nothing about who reads it.

Role-based vs personal work email

A personal work address maps to one person, while a role address maps to a function. The table sets out the differences that matter for outbound.

People confuse a role address with a catch-all domain. They are different. A catch-all domain accepts any address, so the check proves nothing. A role address is a real mailbox that has no single owner.

When it matters

Three situations decide whether a role address is worth a send. Outside them, skip.

Small companies with no named contact

At a five-person company, info@ may reach the founder. If your search finds no person at the domain, a role address is a fair last resort.

Send one short email and no follow-up chain. Say who you are in the first line, because nobody will recognise the sender.

Procurement, partnerships and vendor desks

Some functions publish a shared alias on purpose, such as partners@ or vendors@. The company wants mail there.

These are the only cases where a role address can beat a personal one. A named person in the wrong team may ignore you, while the alias is the sanctioned door.

Deliverability and compliance

Role addresses carry more risk for your sender reputation and for sequences that scale. A list heavy with them gives you less control over who reads your mail and who can report it.

On law, CAN-SPAM defines a commercial message by its primary purpose and makes no exception for business recipients (15 U.S.C. 7702, checked September 2026). See CAN-SPAM for cold email. A role mailbox gets the same opt-out and postal address rules as any other. This is not legal advice. Check with counsel for your markets.

How LeadOcean handles it

LeadOcean marks a person's best email as role in the email_status field and as a value of the emailStatus filter. The OpenAPI spec (checked September 2026) describes role as a shared mailbox like info@, to use with care.

The free MCP count, count_leads, covers only verified, catch_all_valid and catch_all addresses by default. So role is out of that count unless you ask for it.

Two counts show the scale. On 2026-10-02, count_leads returned 124,786,586 people at the mailable default, and 332,561 people whose email status is role. The second number is a count with an emailStatus filter, so it is not a mailable count.

Counts are free and spend no records. To keep role addresses out of a pull, name the statuses you accept. The request below sizes a list with count=true as a query parameter and limit 1.

curl -X POST "https://api.leadocean.io/v1/people/search?count=true" \
  -H "x-api-key: $LEADOCEAN_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "title": ["Head of Sales"],
    "emailStatus": ["verified", "catch_all_valid", "catch_all"],
    "limit": 1
  }'

Change emailStatus to ["role"] to size the shared-mailbox group instead. A real pull then costs one record per person returned, so size first.

Read email_status on each record before you send. LeadOcean does not refund or credit bounces, so the filter is your protection. Test the plan on the Free plan first.

FAQ