The Microsoft 365 tenant sending limit: what 5.7.233 means and where we measured it

Every mailbox on a Microsoft 365 tenant has its own sending limits, and they are generous: 10,000 recipients a day and 30 messages a minute. Those are not the limits a cold email tenant runs into. The one it runs into belongs to the tenant as a whole, and the bounce that announces it looks like a problem with the recipient when it is not.

The bounce carries the status code 5.7.233 and the tag LES301.1, and it names the tenant external recipient rate limit. This post is about what that means, what Microsoft says the limit is, and what we measured it to be on a tenant of our own.

What does the 5.7.233 error mean?

A 5.7.233 bounce means Microsoft refused to send because the tenant used up its allowance of external recipients for the rolling 24 hours. The message never left Microsoft. It is about total volume across every mailbox on the tenant, not about the address it was going to, and it clears as the 24-hour window moves on.

Three things follow from that. The recipient is fine, so removing it from your list is wrong and costs you a good contact. The mailbox that bounced is fine, because it was simply the one that asked after the pool ran dry. And no setting on the domain will change it, because the domain is not what is being counted.

What is the published limit?

Microsoft calls it the Tenant External Recipient Rate Limit, usually shortened to TERRL, and publishes it as a formula: roughly 500 multiplied by the number of licences raised to the power 0.7, plus 9,500 external recipients per day. Every mailbox in the tenant draws from that one pool.

By that arithmetic the floor is about 10,000 a day. One licence gives 500 plus 9,500. A hundred licences gives about 22,000. Read that way, the limit is so far above any sensible cold email volume that it is easy to dismiss, and we said as much in earlier posts. The measurement below is why we stopped saying it.

What did we actually measure?

From 18 to 24 September 2026 we watched a tenant carrying one domain and 100 mailboxes, running warm-up only. No campaign mail was sent. Every day, once the day’s external recipients passed roughly 950 to 1,000, further sends were refused with 5.7.233.

That is a tenth of the published floor. We do not know which input Microsoft applied to arrive at it, and we are not going to reverse-engineer a formula from one tenant and one week. What we can say is that the published number did not describe this tenant, and that planning around 10,000 would have been planning around a figure the tenant never had.

Measured, not claimed, cuts both ways. This is one tenant. A tenant set up differently may well get closer to the published formula. But if you run cold email on Microsoft and have never checked where your own tenant refuses, the safe assumption is ours rather than the formula.

Does warm-up count toward the tenant limit?

Yes. The limit counts external recipients, and warm-up mail goes to external recipients. Every warm-up send, every reply the warm-up pool generates from your mailboxes, every campaign email, every follow-up and every test message draws from the same daily pool. The tenant above reached the cap on warm-up alone.

This is the part that catches people. A domain with 100 inboxes sending 3 campaign emails each looks like 300 a day, comfortably small. Add a warm-up tool ramping each inbox to 8 or 10 a day and the tenant is at 1,100 to 1,300 before a single follow-up, and the overflow bounces with an error that seems to blame the list.

How do you budget around it?

Budget about 900 external recipients a day for the whole tenant, warm-up and campaign together, until you have measured your own tenant somewhere else. That leaves a margin under the point where we saw refusals start, and the margin matters because the window is rolling rather than resetting at midnight.

Those are the limits our handover email sets on every Microsoft domain we deliver, and the warm-up ceiling of 5 is where it is partly for this reason. The 3 a day for campaign mail comes from how many cold emails an inbox can carry, and it leaves room under the tenant pool rather than spending all of it.

• Set the warm-up daily limit in your sequencer explicitly. Some ramp past 5 by default, and the default is what fills the pool
• Count follow-ups. A three-step sequence started at 300 a day is 900 a day by the third step if every lead stays in it
• Count your own tests. A spam test to 50 seed addresses is 50 recipients from the same pool
• Keep one domain per tenant, so one domain’s volume cannot spend another’s allowance

What 5.7.233 is not

It is not a reputation signal. Reputation problems show up as mail accepted and filed in Junk, or as refusals from the receiving side. A 5.7.233 refusal happens before the mail leaves Microsoft, so no receiving server has formed any view of it.

It is not the 5.7.708 error either. That one is a refusal of a fixed share of traffic whatever the volume, and lowering volume does not clear it. 5.7.233 is the opposite: it appears only above a volume, disappears below it, and lowering the daily sends is the whole fix.

And it is not a per-mailbox limit. Pausing the mailbox that bounced does nothing useful, because the next mailbox to send hits the same empty pool. The fix is the sum across the tenant.

Why this matters more on a shared tenant

On a tenant you control, the pool is yours and the budget above is arithmetic. On a tenant shared between several customers, the pool is everyone’s, and you have no way to see how much of it someone else spent this morning. Your mail can bounce with 5.7.233 on a day you sent less than usual.

That is one more reason tenant isolation is worth checking before you buy inboxes. Every Microsoft domain we deliver runs in a dedicated tenant, so the only volume drawing on its pool is the volume you chose to send.