What Is a Role-based Email Address?

A role-based email address is a mailbox named for a function, such as info@, sales@ or support@, that a team shares instead of one person owning it.

The local part (the text before the @) describes a job, not a human. Mail sent there goes to whoever staffs that function, which can be one person, a whole team or a ticketing system.

Some of these names are not a habit but a convention. RFC 2142 (Internet Mail Consortium, May 1997) lists INFO, MARKETING, SALES and SUPPORT as business mailbox names, and also names POSTMASTER, ABUSE and WEBMASTER for operations.

Why it matters for outbound

A role address reaches a group, so nobody feels the message is theirs. Cold email to info@ rarely gets a reply from a decision maker, and several people may see it and mark it as spam.

Complaints land on your sender reputation, not just on that one message. Many role inboxes also run filters or ticket queues that discard unsolicited mail. Skip them for cold outreach and use a named contact at the same company.

There are exceptions. If you sell to a team that publishes a sales@ or partners@ inbox for inbound pitches, writing there can be fine. Treat it as a deliberate choice, not a default.

Example

A company list holds two rows for acme.com:

info@acme.com          role address, shared by a team
jane.doe@acme.com      personal work address, one owner

Both rows are well formed and both can accept mail. A syntax check passes them equally. The difference is the local part, so detection needs a maintained list of role names, plus a verifier that applies it.

The first row sends a pitch to a shared queue. The second reaches Jane Doe, who can say yes or no.

In LeadOcean data

LeadOcean marks these addresses with the role value of email_status. It is one of 13 values, labelled "Role address" in the API (openapi.json, September 2026). The docs describe it as a shared mailbox like info@ and file it under "Use with care", next to risky and derived.

The default count_leads MCP count covers only verified, catch_all_valid and catch_all, so role addresses are never in it. You can filter with emailStatus on /v1/people/search to find them, or to exclude them.

The v2 contact endpoints (/v2/people/email/work and /v2/people/email/personal) withhold role addresses and do not return them. Read email_status on every row before you send. Plans are on /pricing, and the full send-or-skip argument is in Role-based emails: send or skip.

Related terms

• Disposable email address
• Temporary email address
• Email address syntax