Role-Based Emails in Cold Outreach: Why info@ Kills Your Reply Rate

workerslab ·

You’re Emailing a Queue, Not a Person

Last quarter I audited a 12,000-contact Apollo export for an SDR team running three Instantly campaigns. They’d validated the list, filtered hard bounces, handled catch-all domains. Bounce rate was under 2%. But reply rate? 0.9%. Barely a pulse.

The problem wasn’t deliverability. It was destination.

1,400 of those 12,000 contacts were role-based email addresses. Things like info@, sales@, support@, admin@. Every one of them delivered successfully. And almost none of them got a reply. When we pulled those addresses out and resent the same sequence to personal inboxes only, reply rate jumped to 4.1%.

That’s a 4.5x difference from one filter.

What Counts as a Role-Based Email?

A role-based email goes to a function, not a person. The address represents a department, a team, or a system process. Nobody owns it individually.

The most common ones hiding in B2B prospect lists:

  • info@ - The generic front door. Goes to a shared inbox, an admin assistant, or nobody at all.
  • sales@ - Routed to a team queue or round-robin. Your cold email sits behind 40 inbound requests.
  • support@ - Ticketing system. Your outreach literally becomes a support ticket.
  • admin@ - IT or office admin. These people aren’t buying your software.
  • billing@ - Finance department. Wrong audience entirely.
  • help@ - Another ticketing alias. Same problem as support@.
  • webmaster@ - A relic from the 2000s. Often unmonitored.
  • postmaster@ - Required by RFC 5321 but rarely checked by humans. Exists for mail server administration.

Some of these look obvious. But in a CSV with 5,000 rows, they blend right in. Especially when Apollo or ZoomInfo attaches a company name and job title to the row. You see “Acme Corp, VP of Sales, [email protected]” and it feels like a real prospect. It’s not. That email goes to a shared queue.

The Reply Rate Gap Is Massive

How bad is the engagement difference? Worse than most SDRs expect.

Woodpecker analyzed campaign data across their platform and found that emails with advanced personalization averaged a 17% reply rate, while non-personalized emails pulled about 7%. Role-based addresses perform far worse than either group because personalization is impossible when you’re emailing a queue. Industry data from email validation providers like Mailfloss and ZeroBounce shows role-based addresses generate spam complaints at 3-5x the rate of personal addresses. And corporate email gateways apply stricter filtering to role-based inboxes by default, because those addresses receive high volumes of unsolicited mail.

Why the gap? Three structural reasons.

Multiple recipients, zero ownership. When five people share an inbox, nobody feels responsible for responding. Your email sits there until someone deletes it during an inbox cleanup. There’s no personal accountability, no “I should reply to this.”

Spam filter bias. Mailbox providers and corporate email gateways apply stricter filtering to role-based addresses. These inboxes receive high volumes of unsolicited email by design. Google and Microsoft know this. Their algorithms score incoming mail to role-based addresses more aggressively. Your perfectly written cold email gets the same treatment as the 50 vendor pitches that hit info@ before lunch.

No personalization hook. Cold email works because you can reference a person’s role, their company’s recent funding round, a LinkedIn post they wrote. Role-based addresses strip all of that away. You can’t personalize to a queue. “Hey info@” doesn’t hit the same as “Hey Sarah.”

When Role-Based Might Actually Work

There’s one exception worth knowing about. Small companies.

At a 3-person startup, the founder IS info@. They’re checking that inbox themselves between customer calls and product demos. A cold email to [email protected] might land directly in front of a decision-maker because there’s nobody else to check it.

How do you tell the difference? Company size is your best signal. If the company has fewer than 10 employees (check LinkedIn or Apollo’s headcount data), a role-based address might connect you to someone who matters. Above 25 employees, role-based addresses almost always route to a shared queue or ticketing system.

Even in the small-company case, you’re still better off finding the founder’s personal address when possible. But if info@ is all you’ve got for a 5-person company in your ICP, it’s worth the send. Just don’t expect the same reply rate as a direct address.

How Many Role-Based Addresses Are in Your List Right Now?

More than you think.

I’ve audited dozens of Apollo and ZoomInfo exports over the past two years. Role-based addresses typically make up 8-15% of a raw export. The percentage varies by industry. B2B SaaS lists tend to run lower, around 5-8%, because Apollo has better coverage of individual contacts at tech companies. Manufacturing, professional services, and local businesses run higher, sometimes 15-20%, because the available contact data skews toward generic company emails.

Here’s what makes it tricky: Apollo doesn’t flag role-based addresses as a separate status. They’re mixed in with “Verified” and “Likely to Engage” contacts. A sales@ address at a company can carry Apollo’s “Verified” tag because the address does exist and does accept mail. It just won’t reply to your cold email.

That’s a deliverability green light with an engagement red flag. Two very different things.

How to Detect and Filter Role-Based Emails

Catching role-based addresses takes two passes.

Pass one: prefix matching. Before you even validate, scan the local part of every email (everything before the @) against a known list of role-based prefixes. The common ones: info, sales, support, admin, billing, help, contact, hello, office, team, hr, careers, jobs, press, media, marketing, legal, compliance, abuse, postmaster, webmaster, noreply, no-reply, mailer-daemon, security, privacy, and feedback.

That’s a text operation. Any spreadsheet or script handles it in seconds. A simple filter in Google Sheets or a Python one-liner catches the obvious ones.

Pass two: validation-level detection. MailCop’s verification flags role-based addresses automatically during bulk validation. When you upload your CSV, each address gets tagged with its type. Role-based addresses get called out so you don’t have to maintain your own prefix list or worry about missing edge cases like “enquiries@” or “reception@” that wouldn’t be on a standard blocklist.

After both passes, you’ve got a clean decision. Move role-based addresses into a separate segment or remove them entirely. For most cold outreach campaigns, removing them is the right call. Your cold email deliverability playbook should treat role-based filtering as a standard step, right alongside bounce removal and catch-all segmentation.

The Filtering Workflow

Here’s the exact process I run on every Apollo export before it hits Instantly.

Step 1. Export from Apollo. Download your CSV with all contacts.

Step 2. Run bulk validation through MailCop. This catches hard bounces, flags catch-all domains, and identifies role-based addresses in one pass.

Step 3. Remove hard bounces. No exceptions.

Step 4. Remove role-based addresses. Pull them into a separate file if you want to revisit the small-company exceptions later, but get them out of your primary campaign list.

Step 5. Segment catch-all domains into their own campaign with lower daily volume and separate monitoring.

Step 6. Import your cleaned list into Instantly. Only deliverable, personal addresses go into your main sequences.

This workflow adds maybe 15 minutes to your list prep. The payoff is a reply rate that’s 3-5x higher than sending to an unfiltered export. For a step-by-step walkthrough of the full cleaning process, see the guide on how to clean Apollo export for Instantly.

The Math on Removing Role-Based Addresses

SDRs sometimes push back on filtering. “I’m cutting 10% of my list. That’s fewer emails sent. Fewer chances to book meetings.”

Run the numbers.

Take a 5,000-contact list with 500 role-based addresses. Send to all 5,000 at a 1.5% blended reply rate (dragged down by the role-based zeros). That’s 75 replies.

Now remove the 500 role-based addresses. Send to 4,500 personal addresses at a 4% reply rate. That’s 180 replies.

Fewer emails. More than double the replies. And you didn’t burn any sender reputation on spam complaints from shared inboxes.

The volume argument doesn’t hold up. You’re not losing pipeline by filtering role-based addresses. You’re concentrating your sends on the contacts who actually reply.

Role-Based Filtering Protects Your Domain Too

Reply rate isn’t the only reason to filter. Role-based addresses carry disproportionate domain risk.

Industry data consistently shows role-based emails generate spam complaints at 3-5x the rate of personal addresses. When multiple people monitor an inbox, the odds that someone hits “Report Spam” go up with every additional reader. One person on the support team marks you as spam and that complaint counts against your sender domain.

Google’s Postmaster Tools threshold is 0.3% spam complaint rate. Above that, you lose eligibility for deliverability mitigation. If role-based addresses make up 10% of your sends and generate complaints at 4x the normal rate, they’re contributing 40% of your complaint volume from just a tenth of your list.

Remove them and your complaint rate drops. Your domain reputation stays healthy. Your verified personal contacts keep landing in the primary inbox instead of spam. Everyone wins except the SDR who insists on emailing info@.

Stop Emailing Queues

Role-based emails are a hidden tax on cold outreach campaigns. They deliver fine. They just don’t convert. And they quietly erode your sender reputation while producing nothing.

The fix takes minutes. Scan for role-based prefixes. Use validation tools that flag them automatically. Pull them out before your sequence starts.

Your list gets smaller. Your reply rate gets bigger. That’s the trade every time.