Mailbox naming conventions for cold email: what looks personable and what looks spammy
Mailbox names are a 0.5-second trust signal. first.last@yourdomain.com wins over team@. Here is the full naming hierarchy.
Rejwan Nirob·May 23, 2026·5 min readThe local part of an email address (the part before @) is a small but real trust signal. A message from first.last@yourcompany.com reads as a real person. A message from team@ or info@ or sales@ reads as bulk. The cost to provision under different naming conventions is identical; the placement and reply-rate difference is meaningful.
The naming hierarchy from best to worst for cold email
- first.last@ - reads as a real human, highest reply rate
- first@ - personal but less formal, second-best
- flast@ - first initial + last name, third-best, common at larger companies
- firstl@ - first name + last initial, similar to flast
- firstmiddle@ - rare but readable, varies by region
- first-last@ - hyphenated, slightly more unusual
- firstlast@ (no separator) - works but reads as casual
- team@, sales@, hello@, info@ - role-based, lowest cold-email reply rate
Why role-based addresses lose for cold
team@, sales@, hello@, info@, contact@ are all role-based addresses that signal "this is a bulk-sent message, not from a specific person." Recipients pattern-match them as automation. Cold-email reply rate from role-based addresses runs 30-50 percent lower than first.last in our partner-program telemetry.
There is also a deliverability angle - some email validation services flag role-based addresses as "low quality" and suppress them automatically, even when the sender is healthy. Avoiding role-based sender addresses keeps you out of that filter category.
When role-based actually works
Transactional or relationship-based mail (signup confirmations, receipts, support replies) is fine from role-based addresses. Newsletters can use newsletter@. Customer-success outreach to an existing relationship can use cs@. The "role-based loses" rule is specifically about COLD outreach to recipients who have no prior contact with the sender.
Naming consistency across the cohort
Pick one convention and use it consistently across the mailbox cohort. A mix of first.last@, flast@, and team@ on the same domain looks structurally inconsistent and adds a small negative signal. Decide on first.last (or your second-best alternative) and apply it across every mailbox under the domain.
“first.last@yourdomain.com wins. team@ loses. Everything else is a small margin. Pick first.last unless your real human team has a different convention.”
What about fictional names
Some cold-email teams use fictional sender names (Mike Johnson, Sarah Chen) instead of real team members. This works at small scale but creates obvious problems if the recipient replies and tries to escalate. Best practice: use real team members' names. If you do not have enough real team members, use real names of team members who agreed to have their identity attached to cold outreach. Never use fake identities at scale - the risk of reputation damage when discovered is real.
On Inboxlee
MagicLee defaults to first.last@yourdomain.com naming during mailbox provisioning, with the option to override per mailbox if your team has a different convention. The wizard prompts for real team-member names so the mailbox identities match real people from day one.
Default to first.last@. Override only when your real team uses a different convention. Avoid role-based for cold sending under any circumstance.
Provision a mailboxFrequently asked
What is the best email-address format for cold email?
first.last@yourdomain.com is the operator-grade default. It reads as a real human, has the highest cold-email reply rate, and avoids the role-based filter category that some email validation services apply. Alternatives in order of preference: first@, flast@ (first-initial + last), firstl@ (first + last-initial), firstmiddle@. All of these significantly outperform role-based addresses like team@ or info@.
Should I use team@ or sales@ as the sender for cold email?
No. Role-based addresses (team@, sales@, hello@, info@, contact@) signal "this is bulk-sent, not from a specific person" and recipients pattern-match them as automation. Cold-email reply rate from role-based addresses runs 30-50 percent lower than first.last in partner-program telemetry. Some validation services also auto-flag role-based addresses as "low quality."
Can I use fake or fictional sender names for cold email?
Technically yes, but the risk-adjusted answer is no. Fictional names work at small scale but create obvious problems if a recipient replies and tries to escalate, or if your fake identity is discovered later. Best practice: use real team members' names with their agreement to have their identity attached to cold outreach. Never use fake identities at scale.
Does the email address local part affect deliverability?
Slightly, in two ways. (1) Some validation services flag role-based addresses as low quality and suppress them automatically. (2) Recipients pattern-match the local part as a trust signal - first.last reads as human, info@ reads as bulk. The deliverability impact is small compared to DNS auth or list quality, but the cumulative effect on reply rate is meaningful.
Should all mailboxes on the same domain use the same naming convention?
Yes. Naming consistency across the mailbox cohort matters. A mix of first.last, flast, and team@ on the same domain looks structurally inconsistent to mailbox providers and adds a small negative signal. Decide on first.last (or your second-best alternative) and apply it across every mailbox under the domain. Inboxlee MagicLee defaults to first.last for the whole cohort.