Microsoft 365 Mailboxes for Cold Email at Scale

The default cold email stack for the last five years has been Google Workspace, full stop. Gmail dominates B2B inboxes, the Workspace admin console is friendlier than Microsoft's, and the IP reputation infrastructure is more forgiving for new senders. So why bother with Microsoft 365 at all?

The honest answer is provider risk. Anyone running cold email at any meaningful scale has watched Google tighten its policies in waves — the 2024 sender-requirements update for bulk senders, the ongoing Postmaster Tools sensitivity tuning, the periodic Workspace-tenant suspension sweeps. When Google flags your sending pattern across the IP range your tenants share with thousands of other senders, you lose capacity instantly. If 100% of your fleet is Google Workspace, that is a business-down event. If 30-40% is on Microsoft 365, your campaigns keep firing.

The second reason is recipient-side reputation. Outlook's spam-filtering stack (Exchange Online Protection, plus Defender for Office 365 on most enterprise tenants) evaluates senders independently of Gmail's grader. A mailbox that has earned Outlook trust through warmup is a different asset from a mailbox that has earned Gmail trust. On B2B lists where 30-50% of recipients are on Microsoft 365 themselves — which is most enterprise-heavy lists — sending from M365 picks up a small same-platform deliverability lift. It is not magical and it is not the dominant factor, but it compounds over a 90-day program.

The third reason is IP diversification at the network level. Microsoft 365 outbound flows through Microsoft-owned IP ranges in datacenters operated by Microsoft, with completely separate blocklist correlation from Google's outbound space. A spam-trap hit on Gmail does not propagate to your Outlook mailboxes. A blocklist listing for a Google range does not affect Outlook delivery. The two surfaces fail independently, which is the entire point of running them in parallel.

The cost argument used to be that Microsoft 365 mailboxes were more expensive to provision and harder to automate. That is no longer true. With CSP-tier automation, an M365 tenant takes 8-15 minutes to spin up, DNS publishes automatically, and the per-mailbox cost is the same as Google Workspace at $2.50/mailbox/month. There is no economic reason not to run both.

Microsoft publishes a hard limit of 10,000 external recipients per mailbox per 24-hour rolling window, with a per-minute throttle around 30 messages and an Exchange Online send-quota of 10,000 messages per day. Those numbers are the ceiling for what a properly-warmed mailbox is technically allowed to do — they are not the operating range for cold email.

For cold email specifically we recommend 30-50 sends per mailbox per day during the first 90 days post-warmup, and 50-75 per mailbox per day after that only if engagement metrics stay healthy (open rate above 35%, bounce rate under 3%, reply rate above 1.5%). The reason the safe-sending range sits an order of magnitude below the technical ceiling is that Microsoft's reputation grading penalizes mailboxes that send near the cap with low engagement far more aggressively than Google does. An M365 mailbox sending 200 cold emails per day with a 15% open rate will be throttled or suspended within 2-3 weeks. The same mailbox sending 40 emails per day with a 40% open rate runs indefinitely.

The economic implication is straightforward. If you need to send 1,000 cold emails per day from Microsoft 365, you do not buy two mailboxes and push them to 500/day. You buy 25 mailboxes and run each at 40/day. The arithmetic at $2.50/mailbox/month works out to $62.50/month for 1,000 daily sends — substantially cheaper than the cost of a single suspended tenant requiring full reprovisioning, and orders of magnitude cheaper than the campaign damage from a mid-flight throttle.

The tenant-level limit is more interesting at scale. Microsoft enforces tenant-wide outbound caps that are roughly 30 times the per-mailbox limit, which means a tenant with 25 mailboxes has effectively unlimited headroom for cold email volume. The constraint is per-mailbox, not per-tenant. This is why we cap each tenant at ~25 mailboxes — past that point, the next mailbox you add does not get more headroom, and a tenant suspension takes more of your fleet down at once.

Microsoft has been deprecating Basic Auth and SMTP AUTH on new tenants since October 2022. On any M365 tenant created after that date, SMTP AUTH is disabled by default and must be explicitly re-enabled at the tenant level (which we do during provisioning if your sequencer needs it). The strategic direction from Microsoft is clear: programmatic email access should go through Microsoft Graph API with OAuth 2.0 tokens, not legacy SMTP credentials.

For sequencers that support OAuth — Instantly, Smartlead, Saleshandy, Apollo, Outreach, Reply, Lemlist, Woodpecker — use OAuth. The connection is more reliable, it survives password rotations, it does not break when Microsoft re-tightens SMTP AUTH policy, and it lets the sequencer use Graph endpoints that have higher per-minute throughput than the SMTP relay.

For sequencers that only support SMTP — Quickmail, Mailshake, some self-hosted setups — we enable SMTP AUTH on the tenant and surface per-mailbox SMTP credentials in the StackMail dashboard. This works fine. The only tradeoff is that if Microsoft rolls another wave of Basic Auth restrictions, SMTP-connected mailboxes are at higher risk of needing reconnection than OAuth-connected ones.

A common mistake is mixing the two on the same mailbox — connecting via OAuth in one sequencer and SMTP in another. Microsoft Graph and SMTP AUTH count separately against the throttle limits, but reputation signals are aggregated, so you are effectively doubling your sending footprint without doubling your headroom. Pick one auth method per mailbox.

Email authentication is what separates a deliverable mailbox from a deliverable spam-folder placement. For Microsoft 365 there are five records that must be correctly published at your domain registrar before sending starts. StackMail publishes all five automatically when you connect a domain — you can verify them with our free SPF checker, DKIM checker, and DMARC checker.

MX records: Microsoft 365 mail flow points at [yourdomain]-com.mail.protection.outlook.com with priority 0. We publish this automatically when the tenant provisions.

SPF: The required record is v=spf1 include:spf.protection.outlook.com -all. If you also send from another platform (Mailgun, SendGrid, etc.) we merge the includes — the -all hard-fail policy is what tells receiving servers to reject any mail from your domain that did not originate from Microsoft.

DKIM (selector1 and selector2): Microsoft uses a two-selector DKIM setup with automatic key rotation. We publish both CNAMEs at provisioning: selector1._domainkey and selector2._domainkey, each pointing to the tenant's DKIM zone at [tenant-id].onmicrosoft.com. Microsoft rotates which selector is active every few weeks; both must remain published. We also support the newer DKIM2 (RFC 6376bis) signing path that some Microsoft tenants are already migrating to — same publish flow, longer keys (2048 bit by default).

DMARC: We publish v=DMARC1; p=none; rua=mailto:dmarc@stackmail.io; pct=100 for the first 30 days so we can collect aggregate reports without affecting delivery. After 30 days of clean reports we recommend stepping to p=quarantine to prevent third-party spoofing of your domain. Strict p=reject is appropriate at month 3+ once you are confident no legitimate downstream system relies on your domain in the From header.

For agency setups managing many domains, see our domain and DNS setup guide and the more comprehensive cold email infrastructure guide.

The common cold email setup is 30-100 Outlook mailboxes spread across 5-15 domains, all needing identical configuration. Doing this by hand inside the Microsoft 365 admin console would take 3-5 days. The StackMail bulk-provisioning flow takes about 30 minutes for 100 mailboxes including DNS publication and warmup activation.

You start by uploading a CSV with domain names, mailbox prefixes (e.g. first.last, first_initial+last), display names, and the data residency region for each tenant. We support generated naming patterns if you do not want to pre-author every address. The CSV schema is in the dashboard with an example file.

Our automation then runs the provisioning sequence for each domain in parallel: buy or import the domain, create the M365 tenant, assign Business Basic licenses, create all mailboxes inside the tenant, publish MX/SPF/DKIM/DMARC records, register the Microsoft Graph application for OAuth, enable SMTP AUTH if requested, and start warmup. Each tenant takes 8-15 minutes wall clock; running 5 in parallel finishes a 50-mailbox order in under 20 minutes.

The dashboard shows tenant grouping (which mailboxes share which tenant, for blast-radius reasons), domain assignment, warmup progress per mailbox, and sequencer-connection state. Agencies running per-client workspaces can isolate each client's tenants and DNS into a separate workspace inside StackMail — see agency setup for that workflow.

The honest answer is that you should run both for any cold email program above 1,000 sends per day. Below that threshold the operational overhead of managing two providers may not be worth the diversification benefit. Above it, the cost of a single-provider outage is too high to ignore.

The default split we recommend is 60-70% Google Workspace, 30-40% Microsoft 365. Google still wins on three things that matter: deliverability to consumer Gmail recipients (which is most B2B in 2026 because everyone uses Gmail for work-adjacent addresses), policy stability within a campaign cycle, and warmup velocity. Microsoft wins on three different things: enterprise recipient trust, IP-range independence from Google, and being a backup when Google policy shifts mid-quarter.

For lists weighted toward Microsoft-heavy industries — financial services, healthcare, government, manufacturing, large enterprise — shift toward 50/50 or even 40/60 favoring Microsoft. The same-platform recipient trust factor on these lists produces measurable inbox placement gains. For lists weighted toward startup/SaaS/consumer-tech, stay at 70/30 favoring Google.

The mistake is running 100% of either provider when your volume is over 1,000/day. That is the configuration where a single provider-side flag becomes a campaign-down event. Compare provider details directly on the Google Workspace mailboxes page.