How to Warm Up Microsoft 365 Mailboxes Without Getting Restricted

There's a specific kind of bad morning in outbound: you log into the Microsoft Defender portal and find one of your sending accounts sitting in Restricted entities. No sends going out, a pile of 5.7.511 bounces in the sequence log, and a support ticket queue between you and getting it unblocked. Nothing in your campaign changed. You just crossed a line Microsoft never showed you.

Microsoft 365 behaves very differently from Google Workspace when you push a new mailbox. Google mostly throttles quietly and lets domain reputation do the talking. Microsoft has hard tenant-level policy limits, an automated compromised-account detector, and an outbound spam policy whose default action is *restrict the user from sending mail*. Warming up an M365 mailbox is as much about staying under those policy ceilings as it is about building reputation.

This is the M365-specific version of the warm-up problem. If you're on Google, read the Google Workspace warm-up guide instead — the failure modes are not the same.

What's actually different about Microsoft 365

Four things change how you should think about the ramp:

• Shared outbound IPs you don't control. Every M365 tenant sends through Microsoft's shared Exchange Online outbound pools. You cannot warm an IP. What you're warming is your *domain* reputation and your tenant's standing — and if your mail starts looking spammy, Microsoft routes it to the high-risk delivery pool, where deliverability falls off a cliff for everything you send.
• Policy limits are enforced, not fuzzy. Exchange Online publishes recipient rate limits and message rate limits, and the outbound anti-spam policy has its own per-hour and per-day external recipient ceilings. Hit them and you get a hard block, not a soft slowdown.
• The default remediation is a user block. In the default outbound spam filter policy, exceeding limits or generating enough spam complaints puts the account in Restricted entities. Unblocking is manual, and repeat offenders get flagged faster.
• SMTP AUTH is off by default. New tenants ship with basic SMTP client submission disabled and Security Defaults on. A lot of "my warm-up isn't sending" tickets are really authentication tickets.

The limits that actually get people restricted

Approximate defaults for a licensed Exchange Online mailbox. Check your own tenant — Microsoft adjusts these, and trial or new tenants sometimes get lower ceilings.

Note the gap: the technical ceiling is 10,000 recipients a day, but the *policy* ceiling that gets you restricted can be 1,000 external recipients a day — and the heuristic ceiling, the one that matters for cold email, is far lower than both. Nobody sending cold outbound at sane volumes should be anywhere near these numbers. You get restricted from complaint rate and bounce rate long before you get restricted from volume.

Do this before day one of warm-up

Every one of these is a reason a ramp stalls or a domain never recovers:

• License the mailbox properly. Shared mailboxes without a license cannot send via SMTP or OAuth in a sequencer. Exchange Online Plan 1 published pricing starts around $4/user/month; Business Basic is a common alternative.
• Prefer OAuth over SMTP AUTH. Modern OAuth connection avoids the Security Defaults fight entirely and survives tenant hardening. If you must use SMTP, enable it per-mailbox (`Set-CASMailbox -SmtpClientAuthenticationDisabled $false`) and add a Conditional Access exclusion rather than turning Security Defaults off tenant-wide.
• Register the sending domain as an accepted domain. Sending from a domain your tenant doesn't own produces `5.7.750 Client blocked from sending from unregistered domains` — a very common day-one failure.
• Publish SPF with Microsoft's include, enable DKIM for the custom domain, and set DMARC. M365 does *not* DKIM-sign your custom domain by default; you have to enable it per-domain and publish the two CNAME selectors. An unsigned custom domain sending cold mail is a reputation problem waiting to happen.
• Set a real display name, signature, and profile. Mailboxes that have never sent anything and have no identity look like exactly what a compromised-account detector is trained on.
• Tighten your own outbound spam policy. Create a custom policy for the sending accounts with lower per-hour limits than the default and set the action to *restrict after* your chosen threshold. You'd rather trip your own guardrail than Microsoft's.

A Microsoft-appropriate ramp

The general shape of a warm-up ramp — small starting volume, steady increments, plateau at a modest ceiling — is covered in the 30-day warm-up schedule. Three adjustments for M365 specifically:

Start lower and hold longer. Days 1–7, keep total outbound (warm-up plus anything else) at 8–12 messages a day per mailbox. Microsoft's compromised-account heuristics weight *change* heavily — a dormant mailbox that goes from 0 to 60 sends in a day is the exact pattern they look for. A mailbox that went 10, 14, 18, 22 over four days is not.

Cap external cold volume around 30–40 a day per mailbox. Not because of Microsoft's 1,000/day policy ceiling, but because a single mailbox sending 40 cold emails at a 0.2% complaint rate generates roughly one complaint every 12 days — survivable. At 150/day the math stops working. If you need more volume, add mailboxes, not per-mailbox volume. That's an infrastructure question, not a warm-up question.

Spread sends across the day. Thirty messages fired in four minutes hits the 30/minute submission rate and looks nothing like a human. Thirty messages across a seven-hour window with jitter looks like a rep.

Start blending real cold sends around day 10–14, at roughly 20% of daily volume, and keep warm-up traffic running underneath at a reduced rate permanently. Warm-up isn't a phase you finish; it's a floor of positive engagement you maintain.

What good warm-up traffic looks like inside a tenant

Warm-up only helps if the signals are real ones Exchange Online and the receiving providers can see. That means messages that actually land in an inbox, get opened by a human-shaped session, get replied to, and — critically — get pulled out of Junk and marked not-junk when they land there. Threaded replies with varied subjects and bodies. Messages that live in folders, not a single synthetic loop.

What doesn't help: high-volume reciprocal blasts between thousands of throwaway accounts, identical templated warm-up bodies, or pools where your mailbox is exchanging mail with addresses that have themselves been flagged. Microsoft's filters have had years of data on those networks. At best it's neutral; at worst your mailbox is now associated with a known warm-up graph.

The signals to watch weekly

• Defender → Review → Restricted entities. Should be empty. If an account appears, don't just unblock and resume — find the complaint or bounce spike that caused it first.
• NDR codes in your sequence logs. `5.7.511` (banned sender) and `5.7.708` (traffic not accepted from this IP) mean you're in the high-risk pool. `4.7.500` means throttling — slow down. `5.7.750` means domain registration, not reputation.
• Bounce rate per mailbox. Above 3% and you're feeding the compromised-account detector. Verify lists before send, every time.
• Where mail actually lands. M365-to-M365 inbox placement can differ sharply from M365-to-Gmail. Run seed-based inbox placement tests rather than trusting open rates, which are inflated by Defender's own link and attachment scanning.
• Alert policies. Turn on the built-in "User restricted from sending email" alert so you find out in minutes, not days.

One tenant or several?

A single tenant with several accepted domains is cheaper and simpler to administer. The trade-off is blast radius: Restricted-entity blocks are per-user, but outbound reputation, the high-risk pool assignment, and any tenant-level enforcement are shared. If cold email is a meaningful revenue channel, isolating it in its own tenant — separate from the domain your invoices and contracts go out on — is worth the extra admin overhead.

Where Sendvanta fits

Sendvanta connects Microsoft 365 mailboxes over OAuth, runs warm-up as real labeled messages inside the workspace, and ramps volume gradually rather than jumping to a target. The part that matters for M365 specifically: deliverability health scoring runs across the mailbox, domain, DKIM, and IP layers, and campaigns slow down or pause automatically when risk thresholds are crossed — before Microsoft's outbound spam policy makes that decision for you. Drafts get SpamAssassin-scored before send, engagement is classified bot-aware so Defender's link scanning doesn't show up as opens, and suppression plus one-click unsubscribe are on by default. You bring your own mailboxes and leads; nothing is proxied through shared IPs. The free plan is $0 forever with 1,000 active leads and 3,000 emails a month, and connecting your own mailboxes is free on every plan. More detail on /features.