Microsoft matters to cold email twice. It is a receiver: Outlook.com consumer mailboxes and the Microsoft 365 tenants of a large share of B2B prospects. It is also a sender platform: Microsoft 365 mailboxes are the second most common cold-email infrastructure. Saleshandy says they carried 33% of the cold email it tracked in H1 2026, against 44% for Google Workspace (vendor data).
The 2026 headline is on the sending side. Microsoft cancelled the planned 2,000-external-recipients-per-mailbox limit on January 6, 2026, after delaying it from January 2025 to April 2026. Its stated reason: the limit "creates significant operational challenges, especially given the limited capabilities of bulk sending offerings available today". The per-mailbox ceiling stays where it was, at 10,000 recipients a day. Microsoft promised "smarter, more adaptive approaches" with no date attached.
Receiving side: Outlook.com high-volume sender rules (May 2025)
Microsoft's postmaster policy page, as of October 2026:
"Effective May 5th, 2025 … Domains sending more than 5,000 emails per day to Outlook.com accounts must fully be compliant with SPF, DKIM, and DMARC. Messages from high-volume senders that do not meet these requirements will be sent to the junk folder. If issues remain unresolved, messages may be rejected with the error: 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level." (Microsoft)
| Item | Outlook.com (May 2025) | Gmail (Feb 2024) |
|---|---|---|
| Threshold | > 5,000/day per domain to Outlook.com consumer addresses | ~5,000/day per primary domain to personal Gmail |
| SPF + DKIM + DMARC | Required, all three must pass; DMARC aligned, p=none minimum | Required for bulk |
| Complaint threshold | None published | 0.3% |
| One-click unsubscribe | Recommended, not mandated | Required for marketing |
| Failure mode | Junk, then possible 550 5.7.515 rejection | Temporary/permanent rejection or spam folder |
Microsoft's policy page says non-compliant mail goes to Junk first and "may be rejected" if issues persist. URIports reports that messages "face immediate rejection, not filtered placement" from May 5, 2025. Treat a 550 5.7.515 as possible from day one.
The same Microsoft page carries two lines most cold-email tools ignore:
- "Senders must not use namespace mining techniques against Outlook.com inbound email servers. This is the practice of verifying email addresses without sending." SMTP-handshake email verification, the core of the Email verification market, is against Outlook.com policy.
- "Connections from dynamic IP space may not be accepted."
As with Google, the published rules cover consumer Outlook.com domains. Mail to Microsoft 365 business tenants is filtered by Exchange Online Protection and Defender, which assign a bulk complaint level of 0–9 with a default threshold of 7 that each tenant can change. There is no single "Microsoft 365 rule", just thousands of tenant policies. See How filtering works.
Sending side: Microsoft 365 / Exchange Online outbound limits
As of October 2026, per the Exchange Online limits service description:
| Limit | Value | Notes |
|---|---|---|
| Recipient rate limit (per mailbox) | 10,000 recipients / 24h rolling | Internal and external recipients both count |
| Message rate limit | 30 messages / minute | Excess is throttled and carried over, not blocked |
| Tenant External Recipient Rate Limit (TERRL) | Scales with licences; trial tenants 5,000/day | 24h sliding window, external recipients only |
| onmicrosoft.com default domain | 100 external recipients per org / 24h | NDR 550 5.7.236 when exceeded |
| Mailbox External Recipient Rate (MERR/ERR), 2,000/day | Cancelled January 2026 | Proposed April 2024, never enforced |
TERRL formula. Per Microsoft's March 2025 message-centre notice, as summarised by LazyAdmin: 500 × (licences^0.7) + 9,500. That gives 10,000/day for 1 licence, 22,059 for 100 and 72,446 for 1,000. Rollout ran in phases through April 2025. The curve is concave. Doubling licences does not double tenant capacity, which caps how far one tenant can be stuffed with cold-email mailboxes.
Microsoft's own position is that "Exchange Online isn't suited to accommodate bulk-mailing scenarios", and it points bulk senders to Azure Communication Services or High Volume Email.
A cold mailbox sending 10–30 emails a day uses 0.1–0.3% of its 10,000-recipient cap. Infra resellers sell Microsoft domains with 25 mailboxes each, at up to 10 emails per mailbox per day. That is 250 sends a day per domain, comfortably inside even a 1-licence TERRL of 10,000. The binding constraint is reputation, not Microsoft's quotas.
SNDS and JMRP: changed in June 2026
Microsoft's sender telemetry is IP-based. The June 8, 2026 overhaul moved SNDS to a new portal with OAuth 2.0, made automated download links expire after 30 days, stripped complaint reports to standard ARF without the original message, and removed trap-hit counts from July 22, 2026. For senders on Microsoft 365 or Google mailboxes, SNDS shows nothing about them. For SMTP/private-IP senders it now shows less than before. See Reputation and blocklists.
Why the cancellation matters
The cancelled 2,000/day ERR would not have hurt a mailbox sending 20 cold emails. It mattered as a signal. Microsoft tried to bring a per-mailbox external-sending cap to Exchange Online, enterprise customers pushed back, and Microsoft backed down, citing the weakness of its own bulk-sending alternatives. Two readings:
- Bullish for Microsoft-based cold infra. Microsoft is reluctant to impose blunt limits that hit legitimate enterprise mail, so per-mailbox caps are unlikely soon.
- Bearish over time. Microsoft said it will pursue "adaptive" approaches, which in practice means behaviour-based detection. That is harder to engineer around than a fixed number. Mass-provisioned tenants with many low-volume mailboxes sending near-identical external mail are an obvious pattern to model.
Reports of Microsoft suspending or throttling tenants built for cold email (resold "Outlook inboxes") circulate among practitioners. No primary Microsoft statement was found for this pass. Evidence belongs in Provider crackdowns.
What this means for an entrant
- Microsoft capacity is cheap and, for now, structurally unconstrained. With ERR cancelled and TERRL scaling with licences, M365 mailboxes are the lowest-cost "big provider" send capacity (see Volume math: what 10k and 100k emails a day cost). Support M365 OAuth as a first-class connection, not an afterthought. See OAuth verification and the end of basic auth.
- Parse 5.7.515 and 5.7.236 as product events. They are unambiguous: authentication failure at Outlook.com, or a tenant still sending from onmicrosoft.com. Surface the fix in the UI.
- Rethink SMTP verification for Outlook.com addresses. Microsoft prohibits "namespace mining". A verification step that probes Outlook.com servers puts the platform's own IPs at risk. Prefer bounce-based learning or providers that take that risk on.
- Build for per-tenant variance. Report placement and replies by recipient company domain. A prospect's tenant with a strict BCL threshold explains more variance than "Outlook vs Gmail". This also strengthens ESP matching logic.
- Don't build the business on M365 tenant stuffing. Microsoft has shown it wants adaptive controls. Keep infra provider-agnostic (Infrastructure strategy: build or partner).