How to name your cold-outbound mailboxes.

TL;DR

• Named addresses outperform role-based ones at every step of the funnel. Better inbox placement, higher open rates, higher reply rates.
• Role-based emails (info@, hello@, team@, sales@) are scored more aggressively by Google, Microsoft, and corporate gateways. They’re designed to receive blasts, so receivers assume that’s what they’re seeing.
• Send from the founder where you can. Founder-name addresses carry social signal, real-person trust, and the lowest spam-classification risk.
• For high-volume cold, use real-name variations on burner domains — phil@allstonlabs.live, jamie@alpinehq.co. Same person, multiple local-parts, consistent across the estate.
• Don’t send TO role-based addresses either. Cold mail to info@ or support@ gets marked as spam at roughly 4× the normal rate, which damages your sender reputation in both directions.

The team@ trap

Most founders, when staffing up cold outbound, instinctively want a “neutral” sending address. team@yourcompany.com sounds professional. outreach@yourcompany.com sounds organized. sales@yourcompany.com sounds like there’s a real sales motion behind it. Each is wrong for the same reason: the local-part is doing work you don’t want it to do.

To a recipient: team@reads as a blast. They’ve gotten fifty of these this month. The mental model is “marketing email,” and the open-rate decision is made before they read your subject line.

To a spam classifier: team@is a literal feature in the model. Gmail, Outlook, and most enterprise gateways have specific rules that downweight role-based local-parts on cold inbound. You’re not just losing the trust signal — you’re actively triggering filters built to catch exactly your pattern.

To your sender reputation: every spam complaint from a recipient who marked your team@message as bulk gets attributed to your domain. A role-based address typically produces 3-5× the complaint rate of a named sender on identical content. That compounds across a sequence and burns the reputation pool you’d otherwise spend on warm-network outreach, customer mail, and invoices.

If you’re tempted to set up a “neutral” address, the right answer is a named one instead. Pick a real person on your team — founder, head of sales, head of operations, anyone with a real first name and a real LinkedIn. Send cold from their mailbox or a real-name variation (covered in Pattern 1 and Pattern 2 below). The same content lands materially better from vrinda@ than from team@, and the rest of this chapter covers how to think about the named-address decision in detail.

What “role-based” means and why it matters

A role-based email address points to a function rather than a person. info@, hello@, contact@, team@, sales@, support@, admin@, billing@, noreply@ — all role-based. They’re typically routed to shared inboxes or ticketing systems, monitored by multiple people, and they exist precisely because the business expects high-volume, unsolicited contact at them.

That last bit is the whole problem. The major mailbox providers — Google, Microsoft, Yahoo — know exactly what role-based inboxes are for. They tune their spam classifiers accordingly. A cold message landing at info@target.com is graded against an inbox that already filters 50 vendor pitches before lunch; a cold message from info@yours.com arrives wearing the same uniform as those 50 vendor pitches.

Why the named address wins on three different axes

1. Spam classification

Google and Microsoft’s spam algorithms treat the local-part of the sending address as a signal. phillip@allstonlabs.com looks like a real person sending one-to-one mail. hello@allstonlabs.com looks like a brand sending a blast. The same content, the same recipient, the same domain reputation — different classification scores, materially different inbox placement.

The differential isn’t hypothetical. Apollo, Mailshake, and every other outbound platform’s deliverability team reports the same pattern: identical campaigns sent from phillip@ versus sales@ show inbox-placement gaps of 15-30 percentage points at scale.

2. Receiver trust

A human looking at their inbox makes a split-second decision about whether to open, ignore, or report. “Phillip An” reads as a person. “Team Allston” or “Allston Sales” reads as marketing. Open rates on named senders run 5-15 points higher than on role-based senders for matched content.

The reply-rate gap is larger. Recipients who do open a role-based message are more likely to dismiss it as bulk and move on. Replies skew heavily toward named senders, particularly when the named sender carries job-title social signal (founder, head of sales, CTO).

3. The complaint feedback loop

When a cold email lands in a shared inbox that multiple people monitor, the easiest action for any of them is to mark it as spam — not because the message is bad, but because it’s irrelevant to them personally. Multiple monitors means multiple chances for a spam complaint.

Spam complaints compound. A 0.3% complaint rate is enough to get a sending domain throttled at Gmail; sustained 0.5%+ produces an outright block. Sending from a role-based address inflates complaint rate at both ends — yours and the recipient’s — and that compounds over a sequence in a way that’s slow to detect and slow to recover from.

The naming patterns that actually work

For cold outbound, three patterns hold sender reputation. In rough order of trust signal:

Pattern 1: Founder name from the corporate domain

phillip@allstonlabs.com. Best inbox placement, highest reply rate, strongest social signal. Use this for high-value prospects, warm-network outreach, and anywhere you’re willing to spend your corporate-domain reputation budget. It’s also the right address for replying TO inbound — your champion at the prospect company will copy your real address into their internal pitch.

The constraint: corporate-domain reputation is finite. If you blast 1,000 cold emails per week from phillip@allstonlabs.com, you’re burning the same reputation pool that your invoices and customer correspondence run on. That’s the case for separate sending domains (covered in chapter 02 of this cluster).

What carries over when you add a new mailbox to an existing well-warmed domain: if your corporate domain has years of clean sending history, a brand-new mailbox on it (say, a fresh vrinda@ alongside your existing phillip@) inherits most of the trust signal immediately. Domain reputation, IP reputation at Google/Microsoft, and DKIM/SPF/DMARC alignment all transfer. What doesn’t transfer: per-sender engagement history at receivers that track it (Microsoft 365 SmartScreen especially). The practical effect is you can safely send ~10/day from day one and ramp to 30/day over the first week, versus the 2-3 week ramp a brand-new burner domain requires. The vast majority of the warmup work is done by the domain, not the individual mailbox.

Pattern 2: Real-name variations on burner sending domains

This is the production pattern for high-volume cold outbound. Procure 10-30 sending domains that look like your brand but aren’t your corporate domain (allstonlabs.live, tryallston.com, getallston.co). On each, provision two or three mailboxes named after a real person at your company:

phillip@allstonlabs.live    phil@allstonlabs.live    p.an@allstonlabs.live
jamie@alpinehq.co          j.an@alpinehq.co        jan@alpinehq.co
alex@tryallston.com        a.smith@tryallston.com  alex.smith@tryallston.com

Each variation is still a real human’s name. Receivers treat the local-part as an identity signal, so consistency matters: phillip@ at allstonlabs.live and phillip@ at tryallston.com read to a receiver as the same operator wearing two name tags. That’s good. phillip1@, phillip2@, phillip3@ reads as automated and triggers the bulk-sender signature.

The display name on each mailbox should match: Phillip An <phillip@allstonlabs.live>. Most spam classifiers weight the display name; an empty display name renders the bare email address in most mail clients and tanks open rates by 10-20 points on its own.

Pattern 3: Persona names on burner domains

If you’re running multiple SDR personas (and don’t want to use your real team’s names), invent named personas that read as real people: jamie@alpinehq.co, alex@altonpartners.co. The persona shows up in display name, signature, and (where possible) a LinkedIn profile. Avoid generic first names that read as fake (no john@, jane@, sarah@ with no further context).

This pattern is more legally sensitive than the first two — most jurisdictions allow personas in commercial communication, but some regulators (and prospects) view it dimly. If you go this route, make sure the personas have a path to a real reply: the inbox is monitored, replies come back from someone who can speak for the company, and the LinkedIn profile (if any) doesn’t fall apart under a 30-second background check.

The addresses you should never send cold from

Skip every role-based local-part:

• info@, hello@, contact@, team@, support@
• sales@, outbound@, outreach@, marketing@, partnerships@
• admin@, billing@, noreply@, no-reply@
• Numbered names (phillip1@, sales02@) — these pattern-match as bulk-sender infrastructure immediately
• Random-string mailboxes (xkj42@) — same problem, plus they look like compromised accounts

Each of these will score worse with spam filters than a named address sending identical copy. The remediation is identical too: provision new named mailboxes and move the sending volume over. There’s no email-copy fix for a bad sender address.

The reverse rule: don’t send TO role-based addresses either

Role-based recipients deserve their own paragraph because most teams overlook them. A cold email landing at info@target.com hits an inbox monitored by multiple people, each of whom has the spam button one click away. Spam complaint rates on cold mail to role-based recipients run 3-5× higher than on cold mail to named recipients.

That complaint rate isn’t the recipient’s problem — it’s yours. Every spam complaint is a signal to Google and Microsoft that your sending domain is producing unwanted mail. If 10% of your sends go to role-based recipients and produce 4× the complaint rate, those 10% are contributing roughly 40% of your reputation damage.

Scrub role-based recipients before your sequence starts. Most modern list-validation tools flag them automatically. If yours doesn’t, a regex for the local-part prefixes above will catch 95% of them: ^(info|hello|contact|team|sales|support|admin|billing|noreply|no-reply)$.

What about reply-to?

A common question: if you send from phillip@allstonlabs.live (burner domain) but want replies to land in phillip@allstonlabs.com (corporate), can you just set a different reply-to address?

You can, but be careful. Mismatched From: and Reply-To: headers are a known phishing signal. Spam classifiers at the receiver side flag them, and some corporate gateways block them outright. The cleaner pattern is to let replies land at the burner domain and forward them: provision an inbox-forwarding rule at the mailbox provider that pushes any inbound mail from the burner inbox into your corporate inbox automatically.

That gives you a single place to read and reply to mail (your corporate inbox), without triggering the From/Reply-To mismatch penalty.

Quick reference: what to use for what

Where this fits

This chapter sits between the procurement and authentication layers of the domain cluster. Chapters 01-06 cover what to buy and how to host it; chapter 07 (multi-mailbox setup) covers the per-domain mailbox provisioning. This chapter covers the naming decision that runs across all of them — and the decision is identical for every mailbox in the estate, so it’s worth standing alone.

Next up: the authentication record set (SPF, DKIM, DMARC) in the cold email infrastructure cluster, which references this naming pattern when it specifies which local-parts the records should authorize.