ON THIS PAGE
By Efe Berke Colaker, Founder at GetleadReviewed by the Getlead editorial team for accuracy. Last updated August 2026.
A list comes back from verification at 96% valid and everyone relaxes. Then the campaign runs, the reply rate is a third of the last one, and the complaint rate is up. Nothing was wrong with the verification. The list was full of shared mailboxes.
Role-based addresses are the blind spot in every accuracy claim, because they are genuinely valid. The server accepts mail for info@company.com all day long. What it does not tell you is that the message lands in a queue nobody owns.
This covers what counts as role-based, why they behave the way they do, when they are worth keeping anyway. And how to filter them without hand editing a spreadsheet.
What counts as a role-based address
The test is ownership. A named mailbox belongs to one person who is accountable for reading it. A role-based mailbox belongs to a function, and is usually forwarded to several people or into a ticketing system.
The technical family deserves particular care. Addresses like abuse@ and postmaster@ are required to exist by internet convention. That means they are guaranteed to verify and guaranteed to be the wrong recipient for a sales message. Mailing abuse@ is close to reporting yourself.
Some prefixes are ambiguous in practice. A one person company where the founder reads hello@ is a perfectly good prospect. And a 4,000 person enterprise where sales@ routes into a partner intake queue is not. Company size is the tiebreaker, not the prefix alone.
Why verification cannot warn you
SMTP verification asks the receiving server one question: does this mailbox accept mail. A shared inbox accepts mail, so the answer is yes, and the address is correctly marked as confirmed valid.
That is not a limitation of the technique, it is the boundary of what the technique measures. The question of who reads the mailbox is invisible to the protocol. That is why a list can be 96% verified and still be full of dead ends.
This is the same gap that makes a clean bounce rate a weak health signal. Our verified sends bounce at 0.51%, comfortably safe. And that number would look identical whether the recipients were named decision makers or a wall of shared inboxes.
So role filtering has to be a separate step in the pipeline. Verification tells you an address works. Role filtering tells you whether working matters.
A role-based address is a mailbox owned by a function rather than a person, routed to a shared inbox or a ticketing queue that nobody is individually accountable for reading.
For example, a list of 3,000 records containing 400 shared inboxes will verify at a healthy rate and still underperform. Because those 400 messages reach a queue where a sales pitch is everyone's to ignore and someone's to report.
The real cost, which is complaints rather than bounces
Three things happen when a cold message lands in a shared inbox, and none of them are good for the sender.
- Nobody owns the reply. In a queue read by four people, a sales pitch is everyone's to ignore, so response rates collapse even when the offer is relevant.
- Someone reports it. Shared inboxes accumulate unsolicited mail, and the person on rota clears it with the spam button rather than the delete key.
- The signal is misread. Delivered messages with no replies and occasional complaints look like poor targeting to filters, because that is exactly what it is.
The complaint arithmetic is unforgiving. The published ceiling for bulk senders is 0.3% of delivered messages. And the recommended operating level is 0.1%, which means three complaints per thousand puts a domain at the limit.
A segment where a meaningful share of recipients are shared inboxes can produce that on its own, without a single thing being wrong with the copy, the authentication or the sending domain. That is what makes this category expensive out of proportion to its size.
There is a quieter cost as well. Role addresses are often the ones scraped most easily, because they are published on websites. So a list heavy in them is usually a list assembled from public pages rather than sourced from a database. The prefix is a clue about provenance.
What the reply data looks like
Shared inboxes do reply, just not usefully. The responses that come back are typically a request to send a brochure, a redirect to a web form, or a polite note that the message will be passed on. Almost none of them convert into a conversation with someone who can decide.
That matters for measurement as much as for pipeline. A segment can post a respectable raw reply rate while producing nothing. That is why positive replies and meetings booked are the metrics worth tracking rather than replies alone.
A shared inbox is a mailbox read by several people or a ticketing system, where no individual is accountable for answering a sales message.
When a role address is still worth mailing
Blanket exclusion is wrong for some markets. Three situations where role addresses are the correct target.
The workable rule is a size threshold. Under roughly 20 employees, a general contact address is often a real person and worth including. Above 200, it is a queue and belongs in a separate low priority segment or out of the list entirely.
When you do mail them, write for the actual reader. A message addressed to a first name that lands in a shared inbox reads as automation. While a short note that acknowledges it is a general enquiry reads as a person who understands where they are writing.
How to filter them out of a list
This is a two minute job that saves a campaign. And it belongs at import rather than at send time so the records never enter the database unlabelled.
- Split the address at the @ and lowercase the local part.
- Match it against a prefix list: info, hello, contact, enquiries, sales, marketing, support, help, admin, office, accounts, billing, team, webmaster, postmaster, abuse, noreply.
- Tag matches as role-based rather than deleting them, so the decision stays reversible.
- Route tagged records to a separate segment, and exclude that segment from high volume campaigns by default.
- Apply the company size rule to decide whether the segment gets mailed at all.
Tagging rather than deleting matters more than it sounds. A year later, a small company whose only address is hello@ may be exactly the prospect a new campaign wants. And a deleted record is unrecoverable while a tagged one is one filter away.
Where a role address is the only contact you hold for an account worth pursuing, treat it as a research task rather than a send. Finding the named person at that company is usually a five minute job and converts a low value record into a real prospect.
Run the filter over your existing database too, not just new imports. Most lists that have grown over a couple of years carry a meaningful share of these addresses. And they quietly drag down every aggregate metric you use to judge campaigns.
One exception worth coding for
Some legitimate personal addresses look role-based by accident. A person actually named Bill at a company using first name addressing produces bill@, and a designer named Art produces art@. A prefix list will flag both.
Cross check flagged records against the contact first name before excluding them. If the local part matches the person's name, it is a named mailbox that happens to collide with a role word, and it belongs in the main segment.
Tagging is marking a record rather than deleting it, which keeps the decision reversible when a segment later becomes relevant.
Sources and method
First-party data (Getlead, 2026): the verification split of 43.4% confirmed valid, 23.9% invalid, 16.7% catch-all and 16.0% unknown comes from 383,368 addresses analyzed through live SMTP verification. And the 0.51% bounce rate comes from 34,973 tracked sends, aggregated and anonymized at campaign level. Full method in our cold email benchmark study.
External sources: the 0.3% spam complaint ceiling and the 0.1% recommended operating level come from the Google Workspace sender guidelines, 2026; the convention that certain role mailboxes such as postmaster and abuse must exist is set out in RFC 2142.
US commercial email obligations, including accurate headers, a physical postal address and a working opt-out honored within 10 business days, come from the FTC CAN-SPAM compliance guide.
Figures were checked in August 2026.
Frequently asked questions
What is a role-based email address?
An address that belongs to a function rather than a person, such as info@, sales@, support@ or admin@. It is usually forwarded to several people or into a ticketing system, so no individual is accountable for reading or answering it.
Why do role-based emails pass verification?
Because they exist and accept mail. SMTP verification asks the receiving server whether a mailbox accepts messages, not whether a decision maker reads it. So a shared inbox is correctly reported as confirmed valid.
Are role-based emails bad for deliverability?
Indirectly, and the mechanism is complaints rather than bounces. Shared inboxes accumulate unsolicited mail and get cleared with the spam button. And the complaint ceiling for bulk senders is 0.3% of delivered messages with 0.1% as the recommended level.
Should I ever email info@ or sales@?
Sometimes. At companies under roughly 20 employees a general address is often read by the founder. And for local service businesses it may be the only published route. At larger companies it is a triage queue and belongs in a separate low priority segment or out of the list.
How do I filter role-based addresses from a list?
Split each address at the @, lowercase the local part. And match it against a prefix list covering info, hello, contact, sales, support, admin, billing, webmaster, postmaster and abuse. Tag matches rather than deleting them so the decision stays reversible.
What should I do when a role address is my only contact?
Treat it as a research task rather than a send. Finding the named decision maker at that company usually takes a few minutes and converts a low value shared inbox record into a prospect worth a personalised message.