Mailbox providers — Google Workspace vs Microsoft 365 vs the home-court pattern.

The premise

A cold-sending estate sized for a 30-rep SDR team needs roughly 90 to 120 mailboxes across 30 to 40 sending domains. Each lives on a mailbox provider — a hosted SMTP service that issues outbound mail under the domain's authenticated identity. The provider chosen determines five operational variables: recurring per-mailbox cost, the daily external-recipients cap, the inbox-placement reputation the provider's sending IPs carry at major receivers, the admin tooling for bulk provisioning, and the throttling behavior applied to aggressive account-creation.

For the vast majority of production estates, the decision is between Google Workspace and Microsoft 365. A non-trivial minority of operators run alternative IMAP-based providers or self-hosted mail platforms. The differentials between those options are larger than the surface-level marketing suggests, and the operators who pattern-match the decision to whatever the corporate domain uses produce a measurably worse outcome than the operators who treat the sending estate as an independent infrastructure layer.

Google Workspace

Google Workspace publishes four tiers relevant to a sending estate. Business Starter, at $6 per user per month, provides a 30 GB mailbox, the full SMTP and IMAP/POP surface, and the standard admin console. Business Standard, at $12, extends storage to 2 TB and adds shared drive and meeting-recording features that are operationally irrelevant for a cold-sending account. Business Plus, at $18, adds enhanced security controls and Vault for retention and audit. Enterprise tiers add S/MIME, data-loss prevention, and per-domain advanced controls at substantially higher per-seat pricing negotiated through sales.

The variable that constrains the operation is the external-recipients cap. A Workspace mailbox is permitted, in steady state, to send to 2,000 external recipients per 24-hour rolling window. Internal sends — to other users under the same Workspace tenant — do not count against that ceiling. A trial account is throttled at 500 external recipients per day; the production cap activates once payment information is on file and the account is out of its initial provisioning window.

The 2,000-recipients-per-day ceiling is a hard SMTP-layer limit, not a soft reputation throttle. A mailbox that attempts a 2,001st send in the window receives a 550 response with an explicit quota-exceeded code. The ceiling resets on a rolling basis rather than at midnight, which has operational implications for sequencing tools that batch sends in clusters.

The operator-side admin surface is the Workspace Admin Console plus the Admin SDK and Directory API. The console is competent for ten-mailbox estates and increasingly painful past that. The Directory API is the correct integration surface for any operation managing more than 20 mailboxes.

Microsoft 365

Microsoft 365 publishes three business-tier products relevant to a sending estate. Business Basic, at $6 per user per month, provides a 50 GB Exchange Online mailbox and the full SMTP surface but no desktop Office applications. Business Standard, at $12.50, adds the desktop applications. Business Premium, at $22, adds Intune device management, Defender for Office, and enhanced security telemetry that is mostly overhead for the cold-outbound use case.

The Exchange Online external-recipients cap is published at 10,000 per day — five times the Workspace limit on paper. In practice the operative limit is meaningfully lower. Exchange Online applies an internal-reputation-throttling layer on top of the 10,000 ceiling: a new mailbox attempting to send at the published cap will trigger automated tenant-level throttling within 48 to 72 hours and produce a sustained reduction in delivery rate that is difficult to recover from without involving Microsoft support.

The observed steady-state ceiling for an Exchange Online mailbox in a cold-sending context, after a normal warmup curve, is closer to 1,500 to 3,000 external recipients per day depending on recipient quality and the tenant's aggregate reputation. The 10,000 number is a Microsoft-side architectural limit, not a sustained sending budget, and operators who plan capacity against the published number invariably discover the gap by month three.

The Exchange Online admin surface — the Exchange admin center plus Microsoft Graph — is more capable than the Workspace equivalent for fine-grained policy configuration, message-trace forensics, and per-tenant audit. It is also meaningfully heavier as an operational system: the learning curve is steeper, and the failure modes when something is misconfigured are less observable from the console alone.

Workspace deliverability at major receivers

The empirical pattern observed across production estates running both providers in parallel is consistent: Google Workspace mailboxes land in the inbox more reliably at Gmail-hosted recipients, and meaningfully less reliably at Exchange Online-hosted recipients, than Microsoft 365 mailboxes do. The differential is on the order of 8 to 15 percentage points of inbox placement at the receiver class — large enough to be load-bearing in capacity planning.

The mechanism is straightforward. Gmail's spam classifier treats authenticated mail from Workspace-hosted sending IPs as carrying a baseline trust signal that mail from a comparably authenticated Exchange-hosted IP does not. The signal is not infinite — a Workspace mailbox that produces complaints or bounces aggressively still degrades. But the unconditional placement differential, measured against identical authentication posture and identical content, is real and stable across multiple quarters of measurement.

M365 deliverability at major receivers

The mirror-image pattern holds at Exchange Online recipients. A Microsoft 365 mailbox sending to a recipient hosted on Exchange Online lands in the inbox at materially higher rates than an identically configured Workspace mailbox. The differential at this receiver class is similar in magnitude, 8 to 12 percentage points.

The implication for B2B-targeting estates is operationally significant. The recipient distribution at most US enterprise targeting lists is heavily skewed toward Exchange Online — the majority of Fortune 1000 corporate mail is hosted on Microsoft 365, with a smaller Workspace minority concentrated in technology and media verticals. An estate running exclusively on Workspace is, by construction, accepting a 5 to 10 percentage point deliverability tax at the largest segment of its recipient base.

The provisioning workflow at scale

Bulk-provisioning 90 mailboxes across 30 domains is, at the manual-console tier, between 12 and 20 hours of operator time on either platform. At the API tier, it compresses to two to four hours of script-writing and roughly an hour of supervised execution.

The Google Workspace Admin SDK is the more mature surface for bulk operations. The Directory API exposes user-creation, group-membership, and domain-verification endpoints with clean idempotency semantics and consistent error responses. The Workspace approach to multi-domain tenancy — secondary domains attached to a single customer ID — is operationally cleaner than the Microsoft equivalent for an operator managing 30+ sending domains under a single billing relationship.

Microsoft Graph is more powerful in absolute capability but harder to script against for the specific bulk-creation workflow. The multi-tenant model is built around accepted domains attached to an Exchange Online tenant, with provisioning paths that vary depending on whether the operator wants the sending domain to function as a primary, alias, or shared domain. The decision tree adds maybe two hours of upfront design work that the Workspace path does not require.

The bulk-mailbox-creation throttling

Both platforms throttle aggressive account-creation patterns. The thresholds are not published but are observable through repeated provisioning runs. Google Workspace soft-limits at approximately 50 users created per day per superadmin. Past that ceiling, provisioning calls succeed but new mailboxes enter a delayed-activation state, and aggressive over-provisioning produces an automated review hold that can take 24 to 72 hours to clear. Splitting provisioning across multiple superadmin identities raises the practical ceiling but compounds audit-trail complexity.

Microsoft 365 throttles at a similar volume but with more headroom on Premium tiers — the practical ceiling for a Business Premium tenant is closer to 75 to 100 users per day before automated review triggers. The downside is that when M365 does throttle, the failure mode is less observable: the user-creation calls return success, the mailboxes appear in the admin center, but the SMTP layer applies a sustained outbound throttle only diagnosable through message-trace analysis.

Alternative providers

A non-trivial minority of operators run alternative IMAP-based mailbox providers, self-hosted Postfix/Dovecot stacks, or hosted mail platforms outside the Workspace/M365 duopoly. The tradeoff is consistent: meaningfully lower per-mailbox cost, in some configurations approaching $1 to $2 per mailbox per month, traded against a substantially higher operational floor and a measurable inbox-placement penalty at the major receivers.

The operational tradeoffs are not subtle. A self-hosted mail platform has no managed admin console, no first-party bulk-provisioning tooling, no built-in audit log, and no support escalation path when something breaks. The operator is responsible for IP reputation, the SMTP daemon's patching schedule, DKIM key rotation, abuse-mailbox monitoring, and the gradual warmup of every sending IP from cold. The cost-per-mailbox advantage evaporates against the operator-time cost. Hosted alternative IMAP-based providers occupy a middle ground — they handle the SMTP daemon and IP reputation, but typically lack the bulk-provisioning API surface and admin-tooling depth of the major providers, and they vary widely in the quality of sending-IP reputation they carry at major receivers.

The provider-reputation-floor question

Whether using a non-major provider impacts deliverability is one of the most-debated questions in the operator community. The empirical answer is yes, on average, by 10 to 20 percentage points of inbox placement at Gmail and Exchange Online, but the magnitude depends almost entirely on the specific provider's IP reputation. A well-run alternative provider with clean IP space and a sane abuse-handling policy delivers within 5 percentage points of Workspace at major receivers. A poorly-run provider with shared IP space and a mixed customer base delivers 25 to 30 percentage points worse and can be effectively unusable. The cost of choosing a non-major provider is not a single number — it is a distribution whose shape depends on the operator's ability to evaluate the provider's IP reputation in advance, a capability most operators do not have access to.

Mixed-provider architectures

A meaningful pattern observed at the more sophisticated cold-sending operations is the deliberate split of the estate across both Google Workspace and Microsoft 365 — running roughly half of the sending domains under Workspace and half under M365. The operational lift is non-trivial: two billing relationships, two admin consoles, two provisioning APIs, two warmup curves, two distinct sets of throttling failure modes, two audit logs to reconcile.

The rationale is reputation diversification. An estate concentrated on a single provider is exposed to provider-side disruption — a tenant-level reputation incident, a regulatory action, a billing relationship that goes sideways — that takes the entire estate offline simultaneously. Splitting across two providers caps maximum incident impact at half the capacity. For revenue-load-bearing outbound operations, the operational overhead is, in our observation, justified by the resilience gain. The split also exploits the home-court pattern directly: domains targeting Gmail-heavy recipient distributions run on Workspace, domains targeting Exchange-heavy distributions run on M365, with routing determined at the sequencing-tool layer based on the recipient's MX records.

The sending-platform-vs-direct-SMTP decision

A second-order decision sitting on top of the provider choice: whether the sequencing tool sends through the mailbox provider's native SMTP layer, or through the sequencing platform's own relay infrastructure with the mailbox provider acting only as the authenticated identity.

Direct SMTP — the default for most sequencing tools that integrate with Workspace and M365 — sends the message through the mailbox provider's outbound infrastructure, which means the message inherits the provider's IP reputation. This is the configuration that produces the home-court placement pattern described above. Relayed sending — where the sequencing platform performs the outbound SMTP transaction from its own infrastructure and signs the message under the mailbox's authenticated identity — sacrifices the home-court advantage in exchange for the platform's own IP reputation, which varies widely and is generally worse than either major provider's. The relayed path is appropriate where per-mailbox sending cap is the binding constraint, but it is not the default and should not be selected without an explicit reason.

License-vs-mailbox economics

The per-user license cost is the visible expense. The hidden expense is the operational floor of administering a 90-mailbox estate — password rotation, recovery-email management, two-factor enrollment, MX-record validation, periodic re-authentication of the integration with the sequencing tool. At a per-mailbox burden of roughly 6 to 10 minutes per month, a 90-mailbox estate consumes 9 to 15 hours of operator time monthly before any incident response. The tier-selection decision often gets handled lazily: an operator who provisions 90 mailboxes on Workspace Business Standard at $12 each is spending $1,080 per month for a feature set the sending estate does not use. The same 90 mailboxes on Business Starter at $6 is $540 per month — a $6,480 annual delta for zero functional difference at the cold-sending use case.

Admin-tooling depth

The per-platform difference in admin tooling at the depth required for a 90-mailbox estate is meaningful. Google Workspace produces audit logs accessible through the Reports API with reasonable latency and a stable schema; the alerting surface is functional but requires external integration to be useful for sending-estate-specific signals. Microsoft 365 produces audit logs through the Unified Audit Log with a richer schema and deeper forensic detail, but with a steeper learning curve. The multi-tenant management surface is more mature on the Microsoft side, where Exchange Online's architecture was built around partner and reseller use cases; Workspace's multi-customer management is workable but feels grafted on.

Common operator failures observed in production

• Single-tier license across the entire estate. The operator selects the middle tier by default, paying for features the sending estate does not use and leaving five figures of annual spend on the table.
• No API automation. The operator provisions 90 mailboxes through the admin console manually, burning 15 to 20 hours and producing inconsistent configuration that surfaces as deliverability anomalies six weeks later.
• No monitoring. The operator deploys without external monitoring of per-mailbox send volume, bounce rate, or quota-exceeded events. The first signal of a throttled mailbox is a sequencing-tool dashboard showing reduced reply rate three weeks after the throttle activated.
• Treating Workspace and M365 as deliverability-equivalent. The operator selects the provider based on existing vendor relationship or per-seat price, ignoring the home-court pattern, and produces a measurable inbox-placement penalty at the dominant recipient class.
• Provisioning past the throttling threshold. The operator attempts to stand up 90 mailboxes in 48 hours, triggers the automated provisioning hold, and loses three to seven days to support-ticket resolution.
• Co-locating with the corporate tenant. The operator runs the sending estate on the corporate mailbox provider, blurring the audit boundary and exposing the corporate identity to any reputation incident on the sending side.

Pre-procurement checklist

• Recipient-distribution analysis: what fraction of the list is Gmail-hosted, Exchange Online-hosted, and other
• Per-mailbox tier selected against the actual feature requirement, not the default
• Bulk-provisioning script written and tested against a staging tenant before production rollout
• Provisioning schedule that respects the per-day throttling threshold of the chosen platform
• Mixed-provider architecture evaluated against the operational lift for the estate's revenue load
• Monitoring configured for per-mailbox send volume, bounce rate, and quota-exceeded events before warmup begins
• Sending-estate tenant separated from the corporate-mail tenant — distinct billing, admin identities, audit log
• Documented escalation path for tenant-level reputation incidents

Where this fits

The mailbox provider is the SMTP layer underneath every authentication record the next chapters configure. The decision constrains per-mailbox cost, the daily volume ceiling, the inbox-placement floor at the major receivers, and the operational complexity of the provisioning workflow that bridges into the multi-mailbox setup of Chapter 07.

The operators who treat this decision as a default — whichever vendor relationship already exists, whichever tier the procurement form pre-selected — produce an estate with a measurable deliverability tax baked into the infrastructure from day one. The operators who treat it as load-bearing produce an estate with a reputation floor that compounds in their favor over the lifetime of the operation.