Should you email role addresses?
Role addresses are shared inboxes, not people: info@, sales@, support@, admin@, noreply@, postmaster@. They rarely bounce, which is why they survive list cleaning — and they rarely open, which is why they hurt you.
The test is simple: if the address cannot plausibly belong to one person who chose to hear from you, it should not be in a nurture or cold sequence.
Why they are worse than a bounce
A bounce tells you to stop. A role address says nothing: it accepts the message, nobody reads it, no one opens, and some fraction of them report it as spam because the inbox is monitored by a shared team that did not ask for your email. Providers weigh complaints and engagement, so a list padded with role addresses lowers your effective reputation while looking clean on paper.
Google's published guidance is a spam complaint rate below 0.3% in Postmaster Tools. Role addresses are a direct path to that number going up.
Where role addresses belong
- Keep them for transactional mail, billing, and account notices — the shared inbox is the correct destination for those.
- Keep them for a genuinely one-to-one sales conversation where you would otherwise call the main line.
- Drop them from newsletters, nurture sequences and any campaign where "engagement" is the metric.
Don't confuse them with personal addresses at work
jane@acme.com is not a role address, even if it is a company domain. The rule is about the local part naming a function rather than a person. Over-filtering removes your best B2B contacts; under-filtering wastes your sends.
Check your own list in about 30 seconds. Paste or drop a CSV — duplicates, typos, role addresses and dead domains, all handled in your browser. Free for the first 100 addresses, $19 once for unlimited.
Open the toolCommon questions
Do role addresses cause bounces?
Almost never. postmaster@ and abuse@ are required to exist by convention. They cost you engagement and complaints, not delivery.
What about catch-all domains?
A catch-all accepts every address on the domain, real or not, so you cannot tell a valid mailbox from a fabricated one without sending. Treat catch-all acceptance as unverified.
Last updated 2026-10-23.