How role-based addresses are detected
Detection relies on matching the local part of the address (the portion before the @) against a known list of common role-based prefixes — info, support, sales, admin, contact, hello, billing, noreply, and similar — rather than anything about the domain or SMTP behavior. This is a pattern match, not a deliverability check, so it’s typically run alongside (not instead of) SMTP verification.
Why role-based matters for B2B lead quality
A list of “leads” that’s heavily populated with info@ and sales@ addresses scraped from company websites represents company-level interest at best, not individual buyer intent — there’s no specific person to follow up with, and messages sent to a shared inbox are easy to ignore since no one person feels ownership of responding. This is a common issue with scraped or purchased B2B lists specifically.
When role-based addresses are the right target
For support tickets, invoices, compliance notices, or any communication genuinely meant for “whoever handles this at the company,” a role-based address is the correct and intended recipient — the classification is a signal for marketing/outreach list quality, not a universal red flag to avoid.
Role-based vs. personal-but-shared addresses
Some personal-looking addresses are still effectively shared — a former employee’s address that now auto-forwards to a team, for instance. These won’t be caught by role-based pattern matching since the local part looks like a person’s name, which is a reminder that role-based detection is a useful heuristic, not a complete solution to “who actually reads this inbox.”