The sending limit that does not reset at midnight

Somebody in a volunteer organisation sent a mail merge to about 900 people. It went out with no trouble. The next day they sent another one to the same list, and the last hundred came back undeliverable with a message about a daily limit.

Same list, same mailbox, one day apart. Most of the second batch left; the tail of it did not.

The thread where they asked about it never settled which limit they had actually reached, and 900 addresses is nowhere near the headline figure everybody quotes. That is the useful part of the story. A work mailbox has several ceilings, they are counted in units nobody expects, and the one people plan around runs on a clock that is not the clock on the wall.

"Per day" does not mean "by tomorrow morning"

The number itself is easy. A Microsoft 365 mailbox can send to 10,000 recipients per day, and Microsoft describes it as "the maximum number of recipients that a user or mailbox can send to in a 24-hour period. These limits are applied per user to all outbound and internal messages."

The part that catches people is the clock. Here is Microsoft's own worked example, in a footnote under the sending limits table:

"After the recipient rate limit is reached, messages can't be sent from the mailbox until the number of recipients that were sent messages in the past 24 hours drops below the limit. For example, a user sends an email message to 5000 recipients at 09:00 AM, then sends another message to 2500 recipients at 10:00 AM, and then sends another message to 2500 recipients at 11:00 AM, hitting the limit of 10,000 messages. The user won't be able to send messages again until 09:00 AM the next day."

Microsoft, Exchange Online limits

Eleven in the morning, and the mailbox is finished until nine the next day. Not midnight. Not the start of the business day. Nine, because that is when the first batch turns twenty-four hours old and falls out of the count.

Microsoft's troubleshooting page for these limits names the mechanism directly: a "24-hour sliding window". The window does not reset. It moves.

The limit lifts in pieces, in the order you spent it

Because the count is a rolling total, the block clears the way it filled: a batch at a time.

In Microsoft's example, 09:00 the next morning releases the first 5,000 recipients and nothing more. The 2,500 from 10:00 come back at 10:00. The rest at 11:00. By lunchtime the mailbox is whole again, and at nine in the morning it is half free.

Which sounds academic until somebody is standing over a laptop at 09:15 trying to send the second half of yesterday's list. Whether that works depends entirely on how the first half was spent, and nobody has that number written down anywhere.

The practical version: if you sent everything in one go, you get everything back in one go, a day later. If you dribbled it out across the afternoon, it comes back dribbled across the afternoon.

The counter is in recipients, and even the documentation forgets

Ten thousand of what, exactly. Microsoft's answer is recipients, and a recipient is a recipient whether it sits in To, Cc or Bcc.

So one email addressed to 500 people in Bcc spends 500 of your allowance, not one. A list of 500 costs 500 whether you send it as 500 separate messages or as one message with every address hidden in a field.

Watch the wording drift, though, because it will trip you up when you go looking. The example quoted above ends with "hitting the limit of 10,000 messages" - messages, in a paragraph about a limit measured in recipients. Microsoft's page about the resulting bounce says "If you sent 10,000 messages in the last 24 hours, you need to wait one day before you can send email from your mailbox."

The limit is in recipients. Two Microsoft pages describing it say messages. If you are trying to work out why you were blocked after what felt like a small number of emails, that inconsistency is part of the reason the answer never adds up.

There is a second, separate ceiling on how many addresses one message may carry at all. Microsoft's service description lists it as customisable up to 1,000 recipients per message; the Defender documentation gives 500 as the default, adjustable between 1 and 1,000. Either way, the Bcc field is not a way around anything.

The second ceiling belongs to everybody at once

Here is the case that makes people certain their account has been hacked.

"This started happening yesterday without warning. Fron what I've read, it's about sending too many emails in a single day. I'm not sure what that number is but we've only sent about 15-20 emails in the last two days. How do I stop this so I can email my clients?"

A user on Microsoft Q&A

Twenty emails, and the mailbox stopped. The explanation is that there are two limits, and only one of them is yours.

The personal one is the 10,000 recipients above. The other is the tenant external recipient rate limit, which Microsoft defines as "the maximum number of external recipients a tenant can send to per day (24-hour sliding window). External recipients are those whose email address domains aren't an accepted domain in the tenant. This limit depends on the number of licenses a tenant has."

Everything your company sends outside its own domain draws on that one pool. Every person, every shared mailbox, every automation, every notification from every app that sends through your tenant. You can send fifteen emails and find the door shut, because the ceiling you hit was never about you.

The bounce for it is specific enough to search for: "550 5.7.233 Your message can't be sent because your tenant exceeded its daily limit for sending email to external recipients (tenant external recipient rate limit)."

Two details worth knowing before you go looking for the culprit. A trial tenant is "capped at 5,000 external recipients per day" regardless of anything else. And a tenant still sending from its onmicrosoft.com starter domain is limited to 100 external recipients for the whole organisation in a rolling 24 hours, with its own bounce code, 550 5.7.236.

Sending as info@ spends somebody's personal limit

A common piece of folk wisdom: route the bulk of it through the shared mailbox so nobody's personal allowance takes the hit.

It does not work, and Microsoft says so in one line: "Sending from another mailbox via permissions is counted for the delegate with rights and not the mailbox that is being sent from."

The allowance follows the person who pressed send, not the address in the From field. Whoever has delegate rights on info@ is spending their own 10,000 every time they answer as the company. If that person is also the one who runs the monthly announcement, they are competing with themselves.

The same list costs one recipient here and a thousand there

Distribution lists are counted differently by the two limits, which is the sort of detail nobody discovers until it matters.

For the personal recipient limit, a distribution group from the organisation's own address book counts as a single recipient. A group from a user's personal Contacts folder counts as every member individually.

For the tenant limit, groups always expand. Microsoft: "TERRL counts distribution group members individually. For example, if someone sends a message to a group in the tenant that has 1,000 external recipients, it will be counted as 1,000 external recipients."

One list. Costs one against your mailbox, a thousand against the company. This is why the person who sends the announcement is rarely the person who gets blocked.

Nobody can raise it for you

The usual escalation path does not exist here. Microsoft's troubleshooting page is blunt: "The recipient rate limit and message rate limit are hard limits enforced at the service level and can't be increased."

Not by your administrator, and not by an argument about how important the mailing is. The tenant limit scales with the number of licences the tenant holds, which is a purchase rather than a request.

And the vendor is straightforward about what it thinks you should be doing instead. From the same documentation: "Exchange Online customers who need to send legitimate bulk commercial email (for example, customer newsletters) should use third-party providers that specialize in these services." A second page repeats it: "Exchange Online isn't designed for bulk mailing scenarios."

Worth reading that as a design statement rather than a scolding. Your mailbox is a mailbox. It was never the newsletter tool, and the limit is where that shows.

What your automation does when the wall arrives

This is where a limit stops being an inconvenience and starts costing you customers, because the software in the middle usually handles it by trying again.

Microsoft's own business applications do exactly that. When Dynamics 365 cannot send through a mailbox that has hit its quota, the message the user sees is: "An unknown error occurred while sending the email message [Email Subject] through the mailbox [Mailbox Name]. The owner of the associated email server profile Microsoft Exchange Online has been notified. The system will try to send the message again later."

Later, into a door that stays closed for up to a day. Meanwhile the record says an attempt was made and something will happen eventually, which is not the same as a customer being told anything.

Sending straight over SMTP behaves differently again. On the per-minute rate limit, Microsoft says that "if a user submits messages at a rate that exceeds the limit via SMTP client submission, the messages will be rejected and the client will need to retry" - the retry is the sender's problem, not the service's. Elsewhere the same documentation describes excess volume being "throttled and successively carried over to the following minutes", which is the gentler behaviour. Both are documented; which one you get depends on how your mail leaves the building.

Either way the failure is quiet in the places you look. The workflow that chases invoices reports a normal run. It is the same shape as a green run that did nothing, and it is why chasing invoices by email is usually the first process to notice.

Google's version has the same shape and different numbers

If you are on Google Workspace rather than Microsoft, none of the above applies and all of it applies. Different numbers, same mechanism.

	Microsoft 365 mailbox	Google Workspace account
Messages per day	not limited directly	2,000 (1,500 via mail merge; 500 on trial)
Recipients per day	10,000	10,000 total, 3,000 external
Recipients per message	500 by default, up to 1,000	2,000 total, up to 500 external
Per-minute ceiling	30 messages per minute	not published as a per-minute figure
Window	24-hour sliding window	"a rolling 24-hour period, not a set time of day"
Can it be raised	"can't be increased"	no admin setting; rises automatically once the account is paid

Google states the shape of the clock as plainly as anyone does: "Limits per day are applied over a rolling 24-hour period, not a set time of day."

Its phrasing of the consequence is worth having next to Microsoft's too: "After reaching one of these limits, users can't send new messages for up to 24 hours. However, they can still access their Google Workspace account, get incoming email, and use their other Google services."

Everything else keeps working. Only sending stops. That is precisely why nobody notices for hours.

What to check in your own setup

Find out what already spends the allowance. Not the newsletter - the rest. Appointment reminders, invoice chasers, form notifications, the CRM that replies to customers, the helpdesk that mails from your domain, the reporting tool that emails a PDF every morning. Each of those is drawing on the same pool as the person trying to answer a client at four in the afternoon.

Ask where each one sends from. An app configured with an employee's login is sitting on that employee's personal limit. Microsoft lists the throttling on that route as "10,000 recipients per day. 30 messages per minute", the same numbers as the human.

Count in recipients, once. Take your largest regular send, count the addresses rather than the messages, and see what proportion of 10,000 it is. Most small businesses are nowhere near. The ones who are near got there through a list they inherited rather than a decision they made.

Decide what should happen on a rejection. The default in most tools is retry, which is wrong for this failure: the block outlives the retry schedule. What you want is for somebody to be told, in a place they will look, that outgoing mail is stopped. The same reasoning applies to limits imposed by other services you connect to and to running out of the plan you are on.

Move bulk off the mailbox before you need to. Both vendors say the same thing about newsletters, and the migration is far easier on a quiet Tuesday than on the morning you are blocked.

When this stops being a settings question

For one mailbox and one monthly announcement, the checks above are the whole job. Count the recipients, move the newsletter somewhere built for it, and the limit stops being something you think about.

It becomes a design question when several systems send on your behalf. Then the question is no longer "what is the limit" but which sends are allowed to consume a shared allowance, in what order, and what happens to the ones that do not fit. A reminder to a customer booked for tomorrow morning and a monthly digest are not equally urgent, and nothing in your setup currently knows that.

Working out which of those two situations you are in is what a process audit settles: $299, three business days, and a written map of what sends what, from where, and what breaks first when the ceiling arrives.