Shared inbox vs group email: how to tell from the address

A shared inbox is one mailbox that several people read and reply from, such as a Microsoft 365 shared mailbox behind support@acme.io. A group is an address that copies every message to many members, such as a Google Group at team@acme.io. On a company’s own domain neither one looks any different from a person’s mailbox in DNS, and the only way to be sure is to ask Google or Microsoft about the address, which is account probing. So the name is the evidence: support@ and team@ are low-confidence hints, and only @googlegroups.com is a certain group.

Shared inbox vs group: what each one is

Both are addresses that more than one person reads. The difference is where a message ends up.

Shared inboxes

A shared inbox is one mailbox with several readers. One copy of each message arrives, the team works through it, and replies go out from the shared address. Common forms:

• Microsoft 365 shared mailbox. A mailbox nobody signs in to directly. Members get permission to open it next to their own mailbox in Outlook and to send as it. It usually needs no license of its own.
• Google collaborative inbox. In Google Workspace this is a Google Group with collaborative features turned on: members can assign conversations to each other and mark them done. Technically a group, used like a shared inbox.
• Helpdesk address. support@ forwards into a helpdesk tool, where agents answer it as tickets.

Groups

A group is one address, many inboxes. Each member gets their own copy, and replies usually come from the member’s own address. Common forms:

• Google Group on the company domain, such as team@acme.io or engineering@acme.io, created by the Workspace admin. Anyone with a Google account can also create a group at googlegroups.com.
• Microsoft 365 group, which comes with a group mailbox, a calendar and shared files; members can follow its conversations in their own inbox.
• Distribution list, which fans each message out to its members and keeps no mailbox of its own.

	Shared inbox	Group
Where a message lands	One mailbox, read by the team	A copy for every member (or a group mailbox)
Replies come from	The shared address	Usually the member’s own address
Typical names	support@, info@, billing@, orders@	team@, all@, everyone@, engineering@
Microsoft 365	Shared mailbox	Microsoft 365 group, distribution list
Google Workspace	Collaborative inbox	Google Group

Some names are commonly either. sales@ can be a shared mailbox the sales team answers from or a list that copies every rep. The same goes for projects@ and marketing@.

Why DNS can’t tell them apart

Mail routing is decided per domain, not per address. The MX records for acme.io name the servers that accept mail for every address on acme.io: jane@, support@ and team@ alike. The provider decides what happens next only after the message has arrived: deliver it to Jane, drop it into the shared mailbox, or copy it to forty members.

The same holds for every other public record:

• MX names the mail host for the whole domain. See detecting business emails with MX records, or look up any domain with the MX lookup tool.
• SPF, DKIM and DMARC describe how the domain sends and authenticates mail, not what kind of mailbox an address is.
• Google Workspace and Microsoft 365 detection also works per company domain. It tells you Acme runs Microsoft 365, which is useful for sales routing and integrations, but nothing about support@ itself. Workspace detection explains what it can and can’t see.

So support@acme.io, team@acme.io and jane@acme.io produce identical DNS answers.

The only certain answer is account probing

You could try asking the provider: connect to the mail server and see which recipients it accepts, or query sign-in pages to see whether the address is a user account. That is account probing, also called user enumeration. It breaks provider terms, gets the prober’s servers throttled or blocked, and tells a third party that someone gave you this address.

isBusinessEmail never does it. It doesn’t connect to your users’ mail servers, doesn’t send probes, and doesn’t ask Google or Microsoft whether a particular address exists. Microsoft tenant discovery uses the domain with a placeholder username, never the real address. Privacy and data handling has the details, and email verification vs email classification explains why classification stops short of the mailbox.

Probing wouldn’t even settle the question. Plenty of small companies run support@ as an ordinary user mailbox that three people share a password for. To the provider that’s a person; in practice it’s a shared inbox.

The name is the only honest evidence

That leaves the part before the @. isBusinessEmail keeps two curated word lists, one for shared inbox names and one for group names, and matches the local part against each with four rules:

Rule	Shared inbox examples	Group examples
The whole local part is a list word	support@, info@, billing@	team@, all@, everyone@
A list word of 4+ letters, then 1–3 digits	support2@, orders01@	team1@
A list word of 4+ letters starts a dotted, dashed or underscored local part	sales-eu@, support.uk@	team_berlin@, staff.london@
A word from a short suffix list ends a dotted or dashed local part	eu.support@, de-billing@	berlin-team@, all-staff@, emea-dept@

The rules are narrow on purpose, because many of these words are also people’s names:

• anna.sales@, john.press@ and steve.jobs@ are people. A word at the end only counts if it’s on a short suffix list (support, billing, team, staff and a few more), not the full list.
• dev.patel@ and it.smith@ are people too. That’s why a word needs at least four letters to count at the start of a longer local part; it@ and dev@ still match on their own.
• salesforce@ and teammate@ don’t match: a word inside a longer word isn’t a match.
• jane.doe@ matches nothing.

Names that are commonly either, such as sales, projects, marketing, finance and hr, are on both lists and score low on both.

The hints only apply when the category is business, education, government or unknown. support@gmail.com is someone’s personal Gmail account that happens to be called support, so both hints are 0. Domain-only checks return 0 too.

Google Groups are the exception

Every address at googlegroups.com is a Google Group, so there the answer is certain: group.confidence is 1, match is googlegroups.com, and reasons includes google_group. But googlegroups.com is also a shared domain anyone with a Google account can use, so its category is personal and the b2b policy recommends block. That comes from the category, not from the group hint.

What the API returns

Every email check returns two objects, shared_inbox and group, each shaped { confidence, match }:

confidence	Meaning	Reason code
0	No sign, or not an organization’s domain	none
0.3	Low: the name matched one of the rules above; match is the word	shared_inbox_name or group_name
1	group only: the address is at googlegroups.com	google_group

A trimmed response for sales@acme.io on a domain that runs Google Workspace:

{
  "email": "sales@acme.io",
  "category": "business",
  "recommendation": "review",
  "is_role_account": true,
  "shared_inbox": { "confidence": 0.3, "match": "sales" },
  "group": { "confidence": 0.3, "match": "sales" },
  "reasons": ["custom_domain", "mx_google_workspace", "spf_present", "dmarc_reject",
              "role_account", "shared_inbox_name", "group_name"]
}

Neither hint changes recommendation. sales@acme.io lands in review because sales is also a role name. Exact role names such as info@, support@, sales@ and team@ set is_role_account, which the b2b policy sends to review and strict blocks; role-based email addresses covers that flag. Variants that aren’t exact role names get the hint and nothing else:

Address	shared_inbox	group	is_role_account	b2b
support@acme.io	0.3 support	0	true	review
team@acme.io	0	0.3 team	true	review
projects@acme.io	0.3 projects	0.3 projects	false	allow
sales-eu@acme.io	0.3 sales	0.3 sales	false	allow
eu.support@acme.io	0.3 support	0	false	allow
berlin-team@acme.io	0	0.3 team	false	allow
jane.doe@acme.io	0	0	false	allow
support@gmail.com	0	0	true	block (personal)
book-club@googlegroups.com	0	1 googlegroups.com	false	block (personal)

The field reference is in response fields: shared inboxes and groups, and every code is listed under reason codes.

What to do with the hints

A 0.3 means “this name is often used for a team address”. Use it to decide who should handle the contact, not whether to let it in.

At sign-up

Never block on a 0.3. If your product needs a named account owner for billing, security notices or admin rights, ask for one without making it an error:

Using a team inbox? Add your own work address so the account stays yours. You can invite the team next.

Keep the team address as a billing or notification contact if they want one. How to require a work email at sign-up covers the rest of the form: messages, typo fixes and failing open.

In sales

A lead from team@ or sales-eu@ is a real company with no named person. Route it to a team queue or an SDR who finds the right contact, instead of a one-to-one sequence that opens with “Hi Sales”. In a lead score, a small adjustment is plenty; the company signals still count in full. The B2B lead qualification playbook has a scoring example.

In your CRM

Store the hints on the contact, for example as a contact type of person, shared inbox or group, and use it to:

• keep group addresses out of personal nurture sequences, where one send reaches every member;
• avoid merging a team address into a person’s record during de-duplication;
• look for a named contact at the same company before the next campaign.

For an existing database, batch checks take up to 100 addresses per request, and the CRM hygiene playbook shows the clean-up flow.

// Label a contact from a /v1/check result. The hints never decide allow or block.
function contactType(v) {
  if (v.group.confidence === 1) return 'group'; // @googlegroups.com
  const inbox = v.shared_inbox.confidence > 0;
  const group = v.group.confidence > 0;
  if (inbox && group) return 'team_address'; // sales@, projects@
  if (inbox) return 'shared_inbox';
  if (group) return 'group';
  return 'person';
}

Next steps

• Try support@ and team@ on your own domain in the checker on the home page, which shows both hints.
• Read the field reference and decide where each hint goes: sign-up, lead routing or CRM.
• Get a free API key and add the two fields to your sign-up handler or CRM sync.