Distinguish the default domain from the sending path
An onmicrosoft.com address can serve several roles in a Microsoft 365 environment. It may be a default tenant address, a mailbox address, a routing identity or an application sender. Finding the string anywhere in a message or account does not by itself establish which outbound restriction applies. Begin with the actual message route and sender identity, then compare them with Microsoft's documented scope.
This article reviews first-party guidance on 8 November 2026. It does not inspect a tenant, remove an initial domain, alter addresses or send test messages. A custom domain is a possible supported design component, not a promise that changing a display field will solve a quota problem or exempt the organization from other sending controls.
Read the documented restriction in recipient units
The Exchange Online limits page, updated 19 October 2026, states that outbound mail from the organization's default onmicrosoft.com domains is limited to 100 external recipients per organization in a rolling 24-hour window. It says inbound messages are unaffected and identifies the 550 5.7.236 diagnostic when the restriction is reached. This is an organization-level published restriction, not 100 messages for every mailbox or a midnight-reset entitlement.
The Exchange Team announcement, dated 20 August 2025, describes the default MOERA domain's testing role and encourages custom-domain use for regular sending. The successfully retrieved text supplies that context; later attempts to inspect additional passages timed out. No rollout completion date or unobserved tenant state is inferred from that incomplete read.
Keep this restriction separate from the mailbox recipient rate, message submission rate, anti-abuse controls and Tenant External Recipient Rate Limit. An organization can encounter a different restriction after correcting one source of throttling. Numeric similarity between two quotas is not evidence that they share the same counting rule or enforcement scope.
Inventory identities without guessing the counting field
For each affected application, record the configured sender, SMTP MAIL FROM identity, visible From address, authenticated account, submitting endpoint, connector and actual recipient domains. Retain complete headers and trace evidence only under appropriate access controls. Distinguish information supplied by the application from information rewritten or added by an intermediary.
The retrieved provider passages describe mail sent from onmicrosoft domains but do not establish every edge case involving divergent envelope, header and routing identities. If a message shows a custom visible From address and an onmicrosoft identity elsewhere, do not declare it exempt or affected solely from that fragment. Ask the responsible administrator to correlate the actual diagnostic and trace with the applicable provider interpretation. The unknown belongs in the assessment, not in a guessed rule.
DMARC alignment is a separate protocol question. A DKIM signer, SPF identity and visible From domain may differ, and quota classification is not established by a DMARC pass. Conversely, adopting a custom sender domain requires appropriate authentication and authorization; a branding change cannot replace those checks.
Classify the route before proposing a remedy
Microsoft's device and application guidance, updated 16 September 2026, distinguishes mailbox submission, connector relay and Direct Send. A scanner using Direct Send cannot use that path for external recipients simply by changing its sender address. A mailbox-submission application still needs the correct supported authentication and sending permissions. A connector route has its own eligibility and trust requirements.
A fictional inventory might contain a test mailbox using tenant-example.onmicrosoft.com, a receipts application configured with a verified custom domain and an internal scanner. The assessment would examine each separately. It would not assume the receipts application is safe merely because its interface displays a custom address, or remove the scanner's routing identity because it resembles the default tenant domain. No such tenant or traffic was inspected here.
Prepare a change plan only after confirming the relevant restriction. Include dependencies on account sign-in names, aliases, application configuration, connector identity and administrative policy. These can require different owners and approval paths. Avoid an indiscriminate rename or deletion of onmicrosoft addresses, which may serve unrelated operational purposes.
Use the diagnostic to separate restrictions
A documented 550 5.7.236 points to the onmicrosoft external-recipient restriction, while 5.7.233 is associated with TERRL. Preserve the complete provider wording and context rather than treating either code as a generic authentication error. RFC 5321 classifies a 5xx reply as permanent for that SMTP attempt. The application needs a deliberate recovery decision, not an endless immediate retry loop.
The current TERRL update also distinguishes cloud environments, tenant populations and exceptions. Those details do not automatically define the onmicrosoft restriction's scope. If a quota is falling within a rolling window, determine when actual prior traffic ages out rather than promising a reset at a fixed clock time.
Verify the outcome on a controlled sample
After a separately approved correction, use a small representative test covering the intended sender and recipient class. Retain the submission outcome, trace, receiver-side evidence and relevant quota observation. Confirm that queued mail has not been duplicated and that the application's real business flow remains functional. Successful transport does not promise inbox placement, and a single successful message does not establish sustainable capacity.
Document who owns future review when the application, domain configuration or Microsoft guidance changes. The exact commissioning requirement is still open: Use current Microsoft documentation and controlled route-specific delivery evidence. Current documentary sources and a proposed route map are included, but no original controlled delivery evidence exists. Technical interpretation of identity edge cases, tenant applicability, operational acceptance and owner publication approval remain required.