Role-Based Email: The Complete Guide + 3 Best Send Rules
By Danila Kozlov·Published August 19, 2026·16 min read·Email Verification & Deliverability·Facts verified August 2026
Somewhere in your list right now sits an info@, a support@, maybe an admin@. They look like perfectly good contacts: real domains, real inboxes, and your verifier even confirms they exist. Then Klaviyo skips them, Mailchimp refuses to import them, and the one campaign that reaches an info@ gets marked as spam by someone who never subscribed.
Welcome to role-based email addresses, the most misunderstood category in list hygiene: technically valid, practically radioactive for marketing, and occasionally exactly the right person to write to. This guide gives you the complete map: what they are, why ESPs block them, the 3-tier send rule that replaces guesswork, how to detect them, and how to find the human behind the alias.
Search intents covered: "role-based email", "what is a role-based email address", "role based email examples", "role account email", "info@ email address", "why do ESPs block role-based emails", "should I email info@", "noreply email", "generic email address", "detect role-based emails", "list of role-based email addresses", "role-based emails in cold outreach"
Quick answer: what is a role-based email? A role-based email address belongs to a function, not a person: info@, sales@, support@, admin@, billing@, noreply@. The inbox is typically shared by a team, a rotation, or an automated system, and nobody in it personally opted in to your list. That is why they hurt marketing deliverability three ways: higher bounce rates (system addresses are dead ends, and stale generic inboxes bounce), spam-trap exposure (abuse@ and spam@ are monitored by anti-spam organizations), and complaint risk (one person in a shared inbox marks spam for everyone). Most major ESPs, including Klaviyo, Mailchimp, and MailPoet, block or skip them automatically on import or send. The working rule has three tiers: never send marketing to system addresses, suppress generic ones from cold campaigns unless they opted in, and treat function-matched addresses like sales@ or press@ as legitimate targets when the function is genuinely who you need. For everyone else: find the actual person.
The direct answer: a role-based email address routes to a job, a department, or a system instead of an individual human being. jane.doe@acme.com reaches Jane. info@acme.com reaches whoever checks that inbox this week: a team, a rotation, a ticketing system, or nobody at all.
The convention is older than most of the web. RFC 2142, published in 1997, standardized the common role mailboxes every domain is expected to maintain: postmaster@ for mail operations, abuse@ for reporting misuse, plus the business set of info@, sales@, and support@. Companies then multiplied the pattern: billing@, hr@, careers@, contact@, hello@, team@, office@, and the one-way noreply@.
The defining trait for a sender is consent, or the absence of it. A personal address can subscribe to your list; a shared function inbox almost never does as a group, which means the people reading it did not ask for your email. Every deliverability problem that follows flows from that single fact:
The damage travels down three distinct paths, and each one hits a different part of your sender reputation. Understanding them separately is what makes the 3-tier rule later in this guide make sense:
Vector 1: bounces. System addresses are dead ends for campaigns: devnull@ discards mail by design, bulk to postmaster@ gets filtered rather than read, and abandoned generic inboxes bounce like any dead address. Every hard rejection counts against the bounce ceiling providers like Google watch, and unlike a typo, these failures cluster: one stale role pattern across a purchased list can spike a whole campaign.
Vector 2: spam traps. Anti-spam organizations and ISPs actively monitor addresses like abuse@ and spam@, because no legitimate marketing list should ever contain them. Emailing one does not bounce; it silently files evidence against your domain with blacklisting services, the most expensive kind of mistake precisely because your dashboard shows nothing wrong.
Vector 3: complaints. A shared inbox multiplies your complaint risk by the number of readers. Your message to info@ lands in front of five people, none of whom subscribed, and it takes exactly one of them pressing "mark as spam" to register a complaint against your domain, on an email four of them never even saw.
3
distinct damage vectors: bounces, spam traps, and complaints
1
reader marking spam in a shared inbox poisons the send for all
< 2%
the bounce ceiling providers expect, and role clusters can breach alone
Why ESPs Block Them (Klaviyo, Mailchimp, and Friends)
The platforms did the math and made the decision for you: most major ESPs block or skip role-based addresses automatically. Their policies are public, remarkably consistent, and worth knowing before an import surprises you:
Platform
The policy
The exception
Klaviyo
Automatically blocks a public list of role addresses; sends are skipped with the reason "Invalid Email"
None: blocks cannot be removed
Mailchimp
Refuses role prefixes (abuse@, admin@, billing@, and more) during bulk imports
Signup-form opt-in is accepted
MailPoet
Does not allow importing role-based addresses at all
Consent-based subscription paths
Omnisend
Blocks them platform-wide; blocked sends appear as Failed Delivery
Support can unblock with explicit consent
Pipedrive
Blocks campaign sends to role prefixes entirely
Individual opt-in workflows
Read the pattern in the exceptions column, because it is the entire philosophy in one line: bulk is blocked, opt-in is allowed. The platforms are not saying role addresses are fake; Klaviyo's own documentation spells out the reasoning: these addresses rarely opt in, complain more, and bounce more. Consent flips every one of those risks, which is what the 3-tier rule below formalizes.
In practice, the blocks surface differently by platform: silently skipped rows in a Klaviyo flow, a rejects report after a bulk upload, Failed Delivery lines in campaign stats. When a list mysteriously shrinks between import and send, the role filter is usually the silent editor, and the rejects report tells you exactly what it removed.
The 3-Tier Send Rule
Not all role addresses are equal, and treating them as one category is how senders lose good contacts and keep bad ones. Sort every role address you meet into one of three tiers, and the decision makes itself:
Tier
Examples
The rule
Why
1. Never
abuse@, postmaster@, spam@, noreply@, devnull@
Suppress from every campaign, permanently
Watchdog and system addresses: trap exposure and guaranteed rejections
2. Risky
info@, contact@, admin@, office@, hello@
Cold and bulk: skip. Confirmed opt-in: send
Shared inboxes with no group consent: complaint multipliers
3. Context
sales@, press@, partnerships@, careers@
Send when the function is genuinely your target, one to one
Writing to sales@ as a buyer is the address doing its job
The tier-3 nuance is what generic advice misses. A journalist writing to press@, a candidate writing to careers@, a buyer writing to sales@: these are not deliverability risks, they are the reason the mailbox exists. The risk was never the role address itself; it was mass-mailing people who never asked. Personalized, relevant, one-to-one outreach to a function-matched address is simply correspondence.
The Complete Role Address Library
Recognition beats memorization: role addresses cluster into four families, and knowing them turns any list scan into a ten-second read. The library below covers the prefixes verification filters and ESP blocklists watch most; keep it as your reference the next time an import needs sorting:
The families also decode the ESP blocklists: Mailchimp's and Pipedrive's refused prefixes read like the first two rows, while the departments row is where human judgment, the tier-3 question, actually lives. When a prefix feels ambiguous, the safe default is one tier stricter than your instinct.
The Workflow: Detect, Segment, Decide, Replace
The complete routine takes four steps, and a whole list clears in minutes. Here is how to handle role addresses in practice:
1
Detect them with a verification pass
Run your list through a verifier: the hygiene filters in a full check flag role-based patterns automatically, alongside disposables and catch-alls. Detection is pattern matching on the local part (info, admin, sales, and dozens more), which is why it works on any domain. Our guide on how to verify an email address covers the full pipeline these flags come from.
2
Segment them out of the main list
Move every flagged address into its own segment before any campaign math happens. Do not delete yet: unlike an invalid email address, a role address is technically deliverable, and some of them are about to earn their place back in the next step. Segmentation first, judgment second.
3
Apply the 3-tier rule
Tier 1 goes to permanent suppression, no exceptions. Tier 2 stays suppressed from cold and bulk sends unless the address demonstrably opted in through your form. Tier 3 moves to your one-to-one outreach track when the function matches your purpose. Ten minutes of sorting, and every future campaign inherits the decision.
4
Replace the alias with the human
For the tier-2 contacts you actually want, do not settle for info@: identify the right person and reach them directly. An email finder turns a name and a domain into a verified personal address in seconds, converting a complaint risk into a real, consenting conversation.
The role-address policy, in six lines
1.Verify every list before sending: the hygiene flags do the detection for you.
2.Suppress tier 1 forever: abuse@, postmaster@, spam@, noreply@ never see a campaign.
3.Hold tier 2 to opt-in proof: no form confirmation, no send.
4.Work tier 3 one to one: function-matched, personalized, never bulk.
5.Upgrade the keepers: swap info@ for the named person via the finder.
6.Re-check at every cleaning: role addresses creep back in with every import.
Sort once, and the policy runs itself in every future campaign.
The trap inside the trap: a role address usually verifies as deliverable, because the mailbox genuinely exists. Senders see the green result, conclude the contact is fine, and ship the campaign. The verification answered "can this receive mail", not "should you send marketing here", which is why serious checkers flag role patterns separately instead of hiding them inside a Valid. Read the flag, not just the color.
How Role Detection Actually Works
Detection is pattern recognition on the local part, the text before the @, and nothing else. The domain is irrelevant: info@ is a role address at a two-person startup and at a Fortune 500 alike, which is why the filter generalizes to any list, from any source, in any market.
A serious filter matches far more than exact words: plural forms (sales, jobs), multilingual equivalents (kontakt, ventes, vendas), compound patterns (customer.service, it-support), and punctuation variants (no-reply, no_reply). That breadth is why automated detection beats scrolling a spreadsheet, and why the library keeps growing as naming conventions evolve.
The edge cases run both directions. mark@ is a person whose name merely resembles marketing; owner@ sits between function and founder at small companies; team-jane@ is a rotation wearing a name. Good filters match whole tokens rather than fragments, so mark@ stays a person, then flag the true ambiguities for your tier rules to arbitrate: machines for recognition, humans for the judgment calls.
The 10-second manual scan: sort any list alphabetically by email address and the role families cluster into predictable neighborhoods: a for abuse and admin, i for info, n for noreply and notifications, s for sales and support. One scroll through those letters catches most of what a missing filter would have flagged.
Role Addresses in Cold Outreach: the B2B Playbook
Cold senders meet role addresses more than anyone, because B2B data sources are saturated with them. Scraped directories list info@ by design, contact pages publish it on purpose, and enrichment tools return it as a consolation prize whenever the actual person cannot be found. Left unfiltered, a cold list quietly fills with shared inboxes.
The math is also crueler in cold. Your domain's reputation is young and unproven, every complaint weighs more, and cold means no opt-in by definition: tier 2 is therefore a hard skip, never a maybe. One info@ complaint early in a domain's life can cost more deliverability than fifty clean sends can rebuild.
The honest exception survives here too: when info@ is the only published channel of a genuinely small business and your message is individual, relevant, and written for that one company, it is correspondence, not a campaign. Keep those out of automated sequences, send them close to by hand, and hold yourself to replies-welcome standards.
Everywhere else, make the upgrade routine your default motion: treat every role address in your pipeline as a to-do, not a contact. Name the person who owns the problem, run the finder, verify the result, and let the sequence reach a human who can actually answer. The role address was never your prospect; it was the arrow pointing at them.
Should Your Company Use Role Addresses?
Yes, for what they were built to do: receive. An info@ on your contact page, a support@ for tickets, a press@ for journalists: these are professional, expected, and continuity-proof, since the inbox survives any employee's departure. RFC 2142 even expects postmaster@ and abuse@ to exist on every mail-handling domain, and keeping them monitored is part of being a good citizen of email.
The recipient-side rules are short. Route each role inbox to real humans with an owner, so nothing rots unanswered. Never subscribe your own role addresses to external lists, because that manufactures the exact complaint scenario this guide warns senders about. And think twice before hiding behind noreply@ for messages people might answer: a one-way address tells customers their reply is unwelcome, rarely the message you want your email list building to send.
Find the role addresses hiding in your list, free MailTester.Ninja flags role-based, disposable, and catch-all addresses in one verification pass, so tier sorting takes minutes, not a spreadsheet weekend. Nothing stored, ever.
spam click in a shared inbox poisons the whole send
abuse@
and spam@ are monitored: trap-grade, tier 1 forever
Valid
but flagged: existing is not consenting
1997
RFC 2142 standardized the role mailboxes
5
major ESPs block or skip them by default
opt-in
flips the rule: consent makes tier 2 sendable
sales@
as a buyer is tier 3: the mailbox doing its job
info@
to a person: the finder turns aliases into contacts
Screenshot this card. Suppress tier 1, prove tier 2, work tier 3.
Key Takeaways
A role-based email belongs to a function, not a person: info@, sales@, admin@ route to teams, rotations, or systems, and nobody in them personally opted in to your list.
The damage travels three ways: bounces from system addresses, spam-trap exposure through monitored inboxes like abuse@, and complaints multiplied by every reader of a shared mailbox.
ESPs already decided: Klaviyo, Mailchimp, MailPoet, Omnisend, and Pipedrive block or skip role addresses by default, with one consistent exception: demonstrated opt-in.
The 3-tier rule replaces guesswork: suppress system and watchdog addresses forever, hold generic inboxes to opt-in proof, and treat function-matched addresses like sales@ and press@ as legitimate one-to-one targets.
Valid is not the same as sendable: role addresses usually pass existence checks, which is exactly why hygiene flags exist. Read the flag, not just the green.
The upgrade path beats the debate: when a tier-2 company matters to you, find the actual person behind the alias and earn a real conversation instead of a complaint.
Glossary
Term
What it means
Role-based email
An address tied to a function or department (info@, sales@) rather than an individual person.
Role account
Another name for the same thing; verification tools use both terms interchangeably.
RFC 2142
The 1997 standard defining the role mailboxes domains are expected to maintain, like postmaster@ and abuse@.
Shared inbox
A mailbox read by multiple people or a rotation; the source of the complaint-multiplier effect.
Watchdog address
Monitored addresses like abuse@ and spam@ used by anti-spam bodies to catch careless senders.
Distribution list
An address that forwards to many individual inboxes; behaves like a role address for consent purposes.
Alias
An address that redirects to another mailbox; info@ is often an alias for one or several people.
noreply@
A one-way sending address that refuses replies; never a marketing target, and a debatable choice to send from.
Hygiene filters
The verification layer that flags role, disposable, and catch-all patterns beyond simple existence.
Suppression list
Your permanent do-not-send registry; tier-1 role addresses live here forever.
Opt-in proof
A recorded, verifiable subscription action; the one thing that makes a tier-2 address sendable.
Complaint rate
The share of recipients marking your mail as spam; shared inboxes inflate it structurally.
Frequently Asked Questions
What is a role-based email address?
A role-based email address is one assigned to a function, department, or system rather than to an individual person: info@, sales@, support@, admin@, billing@, hr@, contact@, and noreply@ are the classic examples. The inbox behind it is typically shared by a team, monitored in rotation, or handled by software, and the convention is formalized in RFC 2142, the 1997 standard that defined the role mailboxes every domain is expected to maintain, such as postmaster@ for mail operations and abuse@ for misuse reports. For senders, the defining trait is consent: an individual can opt in to your list, but a shared function inbox almost never does as a group, so the people reading it did not ask for your message. That is why verification tools flag role-based patterns separately, why most ESPs restrict them, and why this guide sorts them into three tiers instead of treating them as one category.
What are examples of role-based email addresses?
They fall neatly into the three tiers this guide uses. System and watchdog addresses: postmaster@, abuse@, spam@, hostmaster@, webmaster@, devnull@, and the one-way noreply@; these exist for infrastructure and misuse reporting, and marketing mail should never touch them. Generic business addresses: info@, contact@, hello@, office@, admin@, mail@, enquiries@; these route to shared inboxes where nobody personally subscribed to anything. Function-specific addresses: sales@, support@, press@, media@, partnerships@, careers@, billing@, hr@; these name the job they serve, which sometimes makes them the right recipient. The pattern to recognize is always the local part, the text before the @: when it names a role, a department, or a function instead of a human being, you are looking at a role-based address, and the tier it belongs to tells you what to do with it.
Why do ESPs block role-based email addresses?
Because the numbers made the decision easy: role addresses rarely opt in, complain more, and bounce more, and each of those failures lands on the platform's shared sending infrastructure as well as on your domain. Klaviyo automatically blocks a public list of role addresses and skips them at send time with the reason Invalid Email, with no option to remove the block. Mailchimp and Pipedrive refuse role prefixes like abuse@, admin@, and billing@ during bulk imports. MailPoet does not allow importing them at all, and Omnisend blocks them platform-wide, surfacing attempts as Failed Delivery. The consistent exception across platforms is consent: a role address that subscribes itself through your signup form is accepted, and Omnisend's support will even unblock specific addresses when explicit consent is documented. The philosophy in one line: bulk is blocked, opt-in is allowed, which is precisely the logic the 3-tier rule applies.
Should I send cold email to info@ addresses?
As a default, no: info@ is the textbook tier-2 address, a shared inbox where nobody opted in and where a single annoyed reader can file a spam complaint on behalf of the whole company. Cold campaigns to info@ lists combine the worst odds: low reply rates, high complaint exposure, and ESP-level blocks that may silently skip the sends anyway. The two honest exceptions: first, when info@ is genuinely the only published channel of a small business and your message is a relevant, personalized, one-to-one inquiry rather than a campaign, writing to it is ordinary business correspondence. Second, when the address opted in through your form, consent resets the rules entirely. For everyone else, the stronger play is the upgrade path: identify the person who owns the problem you solve, find their direct address, and earn a conversation instead of renting a shared inbox's patience.
Are role-based emails valid?
Usually yes, and that is the trap. A role address like info@ typically points to a real, functioning mailbox, so an existence check comes back positive: the syntax is fine, the domain resolves, the server accepts mail for it. Verification answered the question it was asked, "can this address receive email", and the answer is genuinely yes. What the green result does not say is whether anyone consented, whether the inbox is read by one person or nine, or whether the address is a monitored watchdog like abuse@. That gap is why serious verification tools run hygiene filters on top of existence checks and flag role-based patterns explicitly, the same way they flag disposables and catch-alls. The practical reading discipline: a role flag on a Valid result means "deliverable, but not a marketing contact by default", and the 3-tier rule tells you which exceptions apply.
Can role-based emails be spam traps?
The watchdog subset effectively functions as one, which is why tier 1 exists. Addresses like abuse@ and spam@ are actively monitored by ISPs and anti-spam organizations precisely because no legitimate, consent-based marketing list should ever contain them: their presence proves the list was scraped, purchased, or generated. Emailing them does not produce a bounce or an error; it quietly records evidence against your domain with blacklisting services, and the first visible symptom is usually a slow, unexplained decline in inbox placement. postmaster@ carries similar risk for bulk mail, since it exists for operational correspondence between mail systems, not campaigns. This is the sharpest argument for automatic detection: humans skim lists and miss patterns, while a verification pass flags every watchdog address before a single send. Treat tier 1 as untouchable, suppress it permanently, and the trap-shaped subset of role addresses never gets the chance to testify against you.
How do I detect role-based emails in my list?
Automatically, through a verification pass: detection is pattern matching on the local part, the text before the @, against a maintained library of role terms, info, admin, sales, support, billing, and dozens more, in multiple languages. Because the pattern lives in the address itself, detection works on any domain and any list size, and a full verification bundles it with the existence checks, so one pass returns both "does this mailbox work" and "is this a role account". Manual review can supplement the sweep for edge cases, obvious department names, plural team labels, function words in other languages, but it should never be the primary method: on a few thousand rows, eyes miss what patterns catch. The workflow that sticks: verify every list before sending, segment the flagged addresses immediately, then apply the 3-tier rule, and repeat the pass at every email list cleaning, because role addresses re-enter with every new import.
How many role-based emails is too many in a list?
There is no magic threshold, but the share is a diagnostic. In a typical opt-in B2B list, role addresses settle around a low single-digit percentage: the odd info@ that subscribed itself through the form. When the flagged share climbs noticeably higher, the addresses are a symptom rather than the disease: some collection source is feeding you directories, scraped contact pages, or enrichment fallbacks, and the same source is probably supplying stale and catch-all data too. So read the number twice. Operationally, apply the 3-tier rule and move on, whatever the percentage. Strategically, trace where the role addresses entered and fix the pipe: tighten the enrichment settings that fall back to info@, add detection at the signup form, and re-audit after the next import. A list that stays naturally low on role addresses is usually a list that is healthy everywhere else.
What is the difference between a role address, an alias, and a distribution list?
They describe the plumbing behind the address, and for senders they mostly collapse into one category. A role address names a function (info@, sales@) regardless of what happens behind it. An alias is a forwarding rule: info@ might silently redirect to one founder's personal inbox. A distribution list fans a single address out to many recipients at once: team@ delivering to eight people simultaneously. The plumbing changes the blast radius, an alias to one person carries less complaint risk than a distribution list to eight, but you cannot see the plumbing from outside, and consent is absent in every variant: none of those recipients individually subscribed. That is why the practical rule ignores the mechanics and reads the local part: if the address names a role, treat it by its tier. The one distinction worth acting on is opportunity, since an alias often hides exactly one findable human worth reaching directly.
Is it against GDPR to email role-based addresses?
The address type is not the issue; the legal basis is. GDPR governs personal data, and a generic info@company.com is generally treated as company information rather than personal data, while jane.doe@company.com clearly identifies a person. That distinction gives role addresses slightly simpler footing for legitimate one-to-one B2B correspondence. The complication is practical: consent is the cleanest basis for marketing, and a shared inbox cannot meaningfully consent as a group, which is exactly why platforms like MailPoet cite consent difficulty when refusing role imports. Layer on the ePrivacy rules many EU countries apply to electronic marketing, and bulk campaigns to role addresses sit in the least defensible corner: no consent, no individual, no engagement. The safe posture mirrors the deliverability one: one-to-one relevant correspondence to function-matched addresses is ordinary business; bulk marketing without opt-in is the thing to avoid. For specifics, consult counsel, since member-state rules vary.
Should my company use role-based email addresses?
For receiving, absolutely: that is what they were designed for. An info@ on the contact page, a support@ feeding your ticketing system, a press@ for media, and the RFC 2142 standards postmaster@ and abuse@ kept alive and monitored: these are professional, expected, and resilient, because the mailbox survives any individual's departure. The rules that keep them healthy are short. Give every role inbox a named owner so nothing rots unanswered. Never subscribe your own role addresses to external newsletters or tools, since that manufactures the exact shared-inbox complaint scenario senders fear. And use noreply@ sparingly: a one-way address on messages customers might reasonably answer tells them their reply is unwelcome, and routing responses to a monitored address costs nothing. Receiving on role addresses, sending from monitored human-answerable ones: that split gives you the continuity benefits without the deliverability baggage.
Why is noreply@ a special case?
Because it fails in both directions at once. As a target, noreply@ is tier 1 by definition: the address exists specifically to refuse conversation, so any marketing sent to it is guaranteed waste, and many are configured to reject or discard inbound mail entirely, feeding your bounce count. As a sender identity, it is a strategy choice with real costs: replies are a strong positive engagement signal to mailbox providers, and an address that blocks them forfeits that signal on every send while telling recipients their response is unwelcome. Transactional systems sometimes justify it for pure notifications, but even there, routing replies to a monitored inbox costs little and occasionally catches a customer mid-problem. The compact rule: never send marketing to a noreply@, and think twice before sending from one. If the message could plausibly deserve an answer, give the answer somewhere to land.
How do I find the person behind info@?
Turn the alias into a name, and the name into a verified address. Start by identifying who actually owns the problem you are writing about: the company site, LinkedIn, and press pages usually surface the founder, the head of the relevant department, or the specific operator you need. Then use an email finder: give it the person's name and the company domain, and it returns their direct address by deriving the company's format and verifying the result against the mail server, the same checks a standalone verification runs. The upgrade changes everything downstream: a personal address can genuinely engage, reply, and opt in, while info@ could only ever tolerate you. It also compounds, since one found format (first.last@) typically unlocks every other contact at the same company. The routine takes minutes per account and converts your riskiest segment, generic role addresses at companies you care about, into your highest-quality one.
About the author
Danila Kozlov
COO at MailTester.Ninja
Danila has spent the last few years deep in email deliverability, helping SaaS companies and growth teams fix the infrastructure problems that silently kill their outbound results. As COO of MailTester.Ninja, he oversees product and operations with a single obsession: making email verification fast, accurate, and genuinely useful for the people who need it most.
One verification pass flags every role-based email in your list: suppress tier 1, prove tier 2, work tier 3 one to one, and upgrade the aliases that matter into real people.
The damage travels down three distinct paths, and each one hits a different part of your sender reputation. Understanding them separately is what makes the 3-tier rule later in this guide make sense:
The platforms did the math and made the decision for you: most major ESPs block or skip role-based addresses automatically. Their policies are public, remarkably consistent, and worth knowing before an import surprises you:
Not all role addresses are equal, and treating them as one category is how senders lose good contacts and keep bad ones. Sort every role address you meet into one of three tiers, and the decision makes itself:
Cold senders meet role addresses more than anyone, because B2B data sources are saturated with them. Scraped directories list info@ by design, contact pages publish it on purpose, and enrichment tools return it as a consolation prize whenever the actual person cannot be found. Left unfiltered, a cold list quietly fills with shared inboxes.
Yes, for what they were built to do: receive. An info@ on your contact page, a support@ for tickets, a press@ for journalists: these are professional, expected, and continuity-proof, since the inbox survives any employee's departure. RFC 2142 even expects postmaster@ and abuse@ to exist on every mail-handling domain, and keeping them monitored is part of being a good citizen of email.