- Role-based email, defined
- A role-based address belongs to a function rather than a person, such as info@, sales@ or support@, and is usually read by several people or none.
Detection is a list lookup rather than a protocol test, so it is cheap and certain. The address either matches a known role prefix or it does not.
The reason to care is complaint risk in marketing sends. Shared inboxes attract unsubscribes and spam reports at higher rates, because whoever opens it did not personally sign up.
In transactional and support contexts the same address is entirely legitimate. The verdict is about suitability for the send, not about validity, and a verifier should label it rather than remove it.
How ZapBounce reports it
Role comes back as a boolean flag beside the result, never as a result of its own. A role address has role set to true and still carries one of the four results, so you keep both facts. The mailbox may be perfectly valid and still be a poor target for a marketing send.
Six hundred badge scans from a trade show
Say your team comes back from a logistics expo with 5,000 scanned badges. A quick sort shows 600 of the addresses start with a function name: 310 are info@, 140 are sales@, and the rest are a spread of office@, accounts@ and dispatch@. They all pass verification, because the mailboxes exist.
Look at who's behind them before deciding. For a 12-truck haulage company, dispatch@ is read by the owner's daughter every morning and is the best address you'll ever get. At a 4,000-person freight group, info@ feeds a ticket queue where your newsletter gets closed as noise, or reported by an intern who never met you at the booth.
A reasonable split is to keep role addresses at small companies in a separate segment, send them a personal follow-up that mentions the show, and leave them off the automated sequence. Company size does the sorting that the prefix can't.
Two prefixes you should never market to
Not every role address is a shared sales inbox. An old internet standard, RFC 2142, reserves a set of mailbox names for running a domain. Two of them deserve special handling: postmaster@, which mail servers are required to accept, and abuse@, which is where spam reports about that domain get sent.
Both are read by administrators, often the same people who decide what their company's filter blocks. Marketing mail arriving at abuse@ is about the quickest way to earn a manual block for your whole sending domain at that organization. These addresses end up on lists through scraping, since they appear in WHOIS records and on contact pages.
Drop those two outright, along with hostmaster@, webmaster@ and noc@. Nobody ever signed up for a newsletter as the abuse desk. If your form does receive one, treat it as a test or a prank and don't add it.
Role-based email: common questions
Should I remove role addresses from a marketing list?
Usually yes for cold marketing, because shared inboxes generate more complaints. For support and transactional mail they are often the right address.
Which prefixes count as role addresses?
info, sales, support, admin, billing, contact, help, office, team and similar function names. The check is a prefix match, not a guess.
Do role addresses bounce more often?
Not particularly. The risk they carry is complaints and unsubscribes, not deliverability.