Google Workspace Aliases vs Real Mailboxes for Cold Email (Don't Use Aliases)

The Confusion, Untangled: Alias vs User vs Domain

• •User, a real mailbox with its own login, quota (~2,000/day Workspace ceiling, of which cold email should use ~30), storage, and crucially its own behavioral reputation: Google tracks each mailbox's sending patterns, reply rates, and complaint history individually.
• •Alias, a free alternate address bolted onto a user. sales@ and alex.m@ can both deliver to alex@; alex can even "send as" them. Underneath: same mailbox, same quota, same reputation, same everything.
• •Domain / secondary domain, the reputation unit above both. Multiple domains in one Workspace still share billing and admin; sending isolation between them exists but is weaker than fully separate setups (the subdomain/domain piece covers that layer).

Why Alias-Sending Fails: The Math and the Pattern

The appeal is obvious, ten sending identities for one $7 seat. But run the numbers: those ten aliases share ONE mailbox's capacity, so you've added exactly zero sends/day. Worse, you've concentrated risk instead of spreading it: one complaint spike now damages every identity at once, because there's only ever been one reputation under the hood. And the pattern itself, a single authenticated mailbox rotating From-names at volume, is a signature Google's systems have seen from every spammer who had the same idea first. You're not diversifying; you're wearing ten name tags on one body.

The Setup That Actually Scales

• •Real users only for sending: human-looking names (alex@, sarah@, not sales01@), 2-3 per domain.
• •~30 cold sends/user/day ceiling, warmup running continuously alongside.
• •Scale horizontally: more volume = more domains × 2-3 users, never more identities per mailbox. 300/day ≈ 10-11 users across 4-5 domains, the Inbox Planner does this math for any target.
• •Full auth per domain, SPF, custom DKIM (not the shared default), staged DMARC; verify in one pass with the Deliverability Checker.
• •Match providers: these Google users should be mailing Google-hosted recipients; Microsoft recipients get Microsoft senders (segment your list first, and see the Outlook piece for why).
• •Where aliases DO belong: reply consolidation (team@ collecting responses), continuity when reps change, receiving jobs, not sending jobs.

The Cost Objection, Answered Honestly

Yes, real users cost money, ten users across four domains runs ~$70/month plus domains, versus "free" aliases. But the alias route doesn't actually produce a cheaper operation; it produces a single point of failure with extra steps, and its first bad week costs more than a year of proper seats. If setup time is the real objection rather than the seats themselves, that's exactly the gap prewarmed inboxes exist to close, real users on real domains, authenticated and aged, without the buildout. Either way: the unit of cold email capacity is the mailbox, and there are no free mailboxes, only borrowed reputations.