onmicrosoft.com is no longer just an ugly domain: it is the slow lane

On 28 August Microsoft posted message centre notice MC1463510: organisations using only the default *.onmicrosoft.com domain will face external messaging limits in Teams. The worldwide rollout is mid-September, which is now, it arrives switched on, and there is nothing for an admin to enable. Read on its own, it is the kind of anti-spam tweak that never reaches Monday's meeting. Read alongside what already happened to email, it is something else: for a year Microsoft has been turning the default domain into a slow lane, service by service, and the email one finished rolling out to every company size on 1 June.

What that domain is and what it was meant for

When someone creates a Microsoft 365 tenant, Microsoft gives them a domain: whatever.onmicrosoft.com. It is called a MOERA — Microsoft Online Email Routing Address — and in the Exchange team's own documentation its purpose is stated without ambiguity: "These MOERA (Microsoft Online Email Routing Address) domains enable immediate connectivity and user creation. Having enabled a quick start and testing of a new tenant, customers are expected to add their own custom domains for better brand representation and control moving forward." It is the starter domain. The slip road, not the motorway.

What has changed is not the intent, which was always that, but that there are now consequences. The sentence marking the turn is short: "In the future, MOERA domains should only be used for testing purposes, not regular email sending." And a few lines earlier, closing the previous section, the admission that until then it had been a free-for-all: "Until now, we did not have any limits on use of MOERA domains for email delivery."

The email limit already applies to everyone

The number is 100 external recipients per rolling 24-hour window. Inbound is untouched. And there is a detail in the small print that decides whether this hits you: "External recipients are counted after the expansion of any of the original recipients." They are counted after distribution lists expand. One message to a list with sixty external contacts consumes sixty, not one. Anyone sending a customer notice from a mailbox like that reaches the cap in two sends without doing anything unusual.

When the cap is reached, the sender gets a bounce with this text, worth keeping to hand because it is all that whoever calls the helpdesk will see:

550 5.7.236 Your message can't be sent because your tenant has
exceeded its daily limit for sending email to external recipients
from your tenant's onmicrosoft.com domains

The rollout was staged by the number of Exchange seats in the tenant, and this is the full schedule Microsoft published:

Look at the last row and look at the calendar. No band is still pending. This is not something that will happen: it happened, and the eleven-person company got it on 2 February. If anyone in your organisation sends external email from an address ending in .onmicrosoft.com, the limit has been in force for months, and most likely nobody has connected it to that odd bounce someone got on a Tuesday. And that bounce is worth rereading, because the cap is not per mailbox: the sentence says "your tenant has exceeded its daily limit". It is a whole-tenant quota. One forgotten sender can eat it, and the bounce lands on everybody else.

The reason, in their words: it is a neighbourhood, not a house

Microsoft explains why good behaviour does not fix this: "because these domains all share the 'onmicrosoft' domain (for example, 'contoso.onmicrosoft.com'), their reputation is collectively impacted", and then: "spammers often exploit newly created tenants to send bursts of spam from '.onmicrosoft.com' addresses before we can intervene. This degrades this shared domain's reputation, affecting all legitimate users."

Translated into what it means for you: your tenant does not have a bad reputation because of anything your people did. It has one because of the name it shares. It lives in a neighbourhood that every spammer in the world moves into the moment they open a trial account, and the only way out of the neighbourhood is to move. Microsoft does not even hide it: the fix it proposes is for your company to have its own domain and use it to send. The expensive part comes afterwards.

And now Teams, with the threshold unpublished

August's notice applies the same idea to chat. Scope: organisations that have only the default domain; if you already have a verified one of your own, it does not concern you. Effect: once the threshold is passed, the user is temporarily unable to send messages to external people, sees an in-product notice, and gets the capability back only when activity drops. Internal is untouched. And there is nothing to switch on: it arrives activated.

What the notice does not carry is the number. With email you know it is a hundred and you know which bounce you will see; with Teams you know there is a cap and that Microsoft expects most organisations never to come near it, but you do not know where it sits. That difference matters at the helpdesk: when a user says they cannot write to a supplier, you will not be able to tell them how many messages they have left or how long to wait. You will be able to tell them why.

The case that catches those who think they are safe

The two changes have different scopes, and that is the detail almost nobody separates. The Teams one targets organisations that use only the default domain. The email one is written differently: it limits "messages sent from your organization's onmicrosoft.com domains". It does not say tenants without their own domain: it says messages sent from those addresses. Your company can have had its own domain for fifteen years and still have senders going out through the default one.

The usual suspects are always the same, and none of them is a person: the mailbox the multifunction printer sends scans from, the ERP service account that sends invoices, the sender behind monitoring alerts, the user created for an integration, who never went through proper onboarding. Nobody ever changed their primary address because nobody looks at them: they are not on the staff list, they have no manager and they do not complain. It is the same family of objects we described when we wrote that the directory holds more records than employees, and the same one that turns up when an Exchange server is left running after the migration.

How to find out this morning

In the admin centre, Settings → Domains: if the only one listed ends in .onmicrosoft.com, the Teams notice concerns you and there is nothing more to discuss. If there is a custom domain, the interesting check is the other one, and it is two Exchange Online PowerShell commands:

Get-AcceptedDomain | Format-Table DomainName, Default

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.PrimarySmtpAddress -like "*.onmicrosoft.*" } |
  Format-Table DisplayName, PrimarySmtpAddress, RecipientTypeDetails

The first tells you Exchange's default domain. The second lists mailboxes whose primary address is still the default one, which is the list that actually matters: shared mailboxes and rooms show up there before people do. The trailing wildcard in the pattern is there on purpose, because some default domains do not end in .com; and if something turns up with mail.onmicrosoft.com, do not count it as a problem yet: Microsoft says those hybrid routing domains are not throttled so long as they are not used for original traffic. The third check is not a command and Microsoft's own page explains it: in message trace in the Exchange admin centre, put a wildcard in the senders field to pull all traffic leaving through your default domain, then strip the internal traffic by filtering on recipient domain. If there is mail going to customers in there, this is not a hypothesis.

Fixing it is not buying a domain

Microsoft describes the fix in four steps — buy the domain, use it only for real sending, set it as default and change mailboxes' primary SMTP address — and then adds the sentence that turns the third step into a project: "Changing the primary SMTP address will have an impact on the username used to log into accounts so updates may need to be made to any credentials configured to authenticate devices or applications with users' accounts."

That is the real bill. What gets touched is not an email address: it is the name people sign in with, and behind it come printers configured with an account, devices authenticating as a user, applications holding somebody's credentials and scripts nobody remembers writing. It gets done, done properly and done in batches, but not on a Friday afternoon or in a two-hour window. Microsoft also adds a separate case: "Customers with Federated Domains will have to add a non-Federated custom domain in Microsoft 365 to act as a default domain". If your identity is federated, there is an extra step before you start.

Our opinion, stated as such: this is not an emergency, and treating it as one is how you break something. It is background work with a date that has already passed, and the order that works is the reverse of how it usually gets framed — first the senders that are not people, which can be fixed without telling anybody and are the ones consuming the limit; then the people, with a schedule and a notice. And as with everything hanging off this provider, it is worth remembering that here six services depend on one single thing: the name you sign in with.

Note on sources

All consulted on 20 September 2026. One: the Exchange team blog post "Limiting Onmicrosoft Domain Usage for Sending Emails", published on 20 August 2025 and last updated on 30 March 2026 (version 9.0), source of every English quotation about email, the limit of 100 external recipients per rolling 24-hour window, the text of the 550 5.7.236 bounce, the full rollout table by seat count, the shared-reputation explanation, the steps Microsoft recommends and the two warnings about the sign-in name and federated domains. Two: Microsoft 365 message centre notice MC1463510, "External messaging limits for onmicrosoft.com-only organizations in Microsoft Teams", published on 28 August 2026, worldwide general availability from mid-September 2026; from it come the scope (organisations using only the default domain), the temporary effect on external messaging with automatic recovery, the fact that internal messaging is unaffected and that the protection activates without admin intervention. What we are not claiming: we have not reproduced either limit in a tenant of our own; Microsoft does not publish the Teams threshold, which is why we give no figure for it; and the two PowerShell commands are read-only checks that change nothing, but you run them on your own tenant. Our opinion: that the two changes read better together than apart; that the case most often missed is the senders that are not people; that the real cost sits in the sign-in name and not in the domain; and the order we propose for fixing it.

Cover image: public domain photograph, cropped by us. The text and branding are ours, added on top.