Every B2B list has them: info@, sales@, support@, hello@, admin@. They're called role-based addresses (or role accounts), and they sit in an odd spot. They're real, working inboxes, so they don't bounce. But they don't belong to one person, and that changes how you should treat them.
When I designed MailRambo's reason codes, role accounts were the one case where I had to decide whether "deliverable" and "a good idea to email" should be the same answer. They aren't, so role accounts get their own reason. This post is about what to do with them.
What counts as a role-based address
A role address is tied to a function, team or position rather than a person. The mailbox often forwards to several people, a ticketing system or a shared inbox that rotates between staff.
| Type | Examples |
|---|---|
| General contact | info@, hello@, contact@, office@ |
| Sales and business | sales@, partners@, marketing@, press@ |
| Support | support@, help@, service@, customercare@ |
| Technical | admin@, webmaster@, postmaster@, hostmaster@, abuse@ |
| Finance and HR | billing@, accounts@, invoices@, jobs@, careers@ |
| No-reply | noreply@, no-reply@, donotreply@ |
Some of these have special status. postmaster@ and abuse@ are expected to exist on mail domains by long-standing convention (RFC 2142), and they're read by the people who handle spam complaints. Mailing them with marketing is a quick way to get noticed for the wrong reasons.
You can check whether an address is a role account with the free role email checker.
Why role addresses are different
Nobody opted in personally
With a personal address, one person decided to give it to you. With info@, the person who filled in your form may have left the company, or the address may have come from a website footer. Several people read that inbox, and none of them asked for your newsletter. That's how you end up with spam complaints from people who never heard of you.
Complaints come from more people
Because the mailbox is shared, a message is seen by more recipients, and any one of them can click "Report spam". Complaint rates matter more than ever: Gmail and Yahoo ask senders to keep them below 0.3%. I covered the rest of those rules in Gmail and Yahoo sender requirements.
Some ESPs restrict them
Several email service providers restrict or discourage importing role addresses into marketing lists, especially for new accounts, because of the complaint risk. Check your ESP's acceptable use policy before a big import.
Engagement is harder to read
Opens and clicks on a shared inbox can come from anyone, or from a ticketing system that renders every message. That makes role addresses look more engaged, or less, than they really are.
Compliance
Whether you may email a role address without consent depends on the law where the recipient is, not where you are. In the US, CAN-SPAM allows commercial email to business addresses as long as you follow its rules (accurate headers, a physical address, a working opt-out). In the EU and UK, rules differ by country and by whether the address identifies a person; generic company addresses are often treated differently from firstname@. I'm not a lawyer, so if you send to Europe at volume, check the specific rules.
What MailRambo returns
A full verification of a role address returns:
{
"email": "sales@acme.com",
"deliverable": true,
"reason": "role_account",
"credits_remaining": 482
}
deliverable is true because the mailbox accepts mail and won't bounce. The reason tells you it's a role inbox so you can decide what to do. This is one of only two reasons that come with true; the other is mailbox_exists.
In the free mode=fast check, role accounts show up as a flag instead of a verdict, since fast mode never confirms a mailbox:
"checks": { "mx": true, "disposable": false, "role_account": true, "free_email": false }
And with ?detail=full, the flags.role_account field is there alongside the lead grade. The developer docs list every field.
Send, skip or segment: by use case
The right answer depends on what you're sending:
| Use case | Recommendation | Why |
|---|---|---|
| Cold outreach | Skip by default; segment if the role matches your offer | No one person opted in; higher complaint risk |
| Newsletter (opted in) | Send | Someone on that team signed up on purpose |
| Transactional (receipts, resets) | Send | The user asked for it; teams often want billing mail shared |
| Signup form | Allow, maybe flag | Small companies often sign up with hello@ or admin@ |
| Imported / purchased list | Remove | Highest risk of complaints and spam traps |
| B2B partnership or press outreach | Send, carefully | partners@ and press@ exist for exactly that |
Cold outreach
For cold email, I'd exclude role addresses from the main sequence. The whole point of cold outreach is reaching a specific person with a relevant message; info@ is the opposite. The exception is when the role matches your offer. Pitching an integration to partners@ or a story to press@ is fine, because that's what those inboxes are for. Send those as a separate, small segment with a message written for the role, not a person.
The clean email list for cold outreach post covers the rest of the list-cleaning steps.
Transactional email
Always send. A customer who uses billing@theircompany.com for invoices chose that address so the whole finance team gets them. Blocking it would be a support ticket waiting to happen.
Signup forms
Don't block role addresses at signup. Plenty of solo founders and small teams sign up with hello@ or admin@, and they're real customers. If you run a free tier that gets abused, role accounts aren't the problem; disposable addresses are, and those do get blocked. What I'd do is flag role signups in your data so you can treat them differently in lifecycle marketing.
Marketing newsletters
If the address came through a real opt-in, send. If it came from a scraped list or a trade show badge scanner, it doesn't have consent, role address or not.
A simple filter in code
With the full check result, segmenting is a two-line decision. In Python:
res = call("POST", "/verify", json={"email": email})
if not res["deliverable"]:
bucket = "remove"
elif res["reason"] == "role_account":
bucket = "role" # separate segment, or skip for cold outreach
else:
bucket = "send"
Here call is the small helper from the API docs. For lists, the batch endpoint (POST /v1/verify/batch, up to 200 addresses per call) returns the same reason per address, so you can split a CSV into send, role and remove buckets in one pass.
Checklist
- [ ] Role addresses identified on every list (API
reason: "role_account"or the role checker) - [ ] Excluded from cold sequences by default
- [ ]
partners@/press@style outreach sent as its own segment with role-appropriate copy - [ ] Never mailing
postmaster@orabuse@with marketing - [ ] Allowed at signup and for transactional mail
- [ ] Role addresses from imported or purchased lists removed
- [ ] Opt-out honored for the whole address, not per person
Try it
Paste an address into the free role email checker or the email verifier to see how it's classified. The MailRambo API gives you 100 free checks a month with the same reason codes, and fast checks are free on every plan. The developer docs have SDKs for Node and Python.