Starting October 15, 2025, Microsoft will begin enforcing a hard cap of 100 external email recipients per 24 hours for all tenants sending from the default onmicrosoft.com domain. The move, announced via the Microsoft 365 Message Center, targets the rampant abuse of free trial tenants that have turned the shared namespace into a launchpad for spam, phishing, and sextortion campaigns. Internal mail within the tenant remains unaffected, but any message to an external address beyond the rolling 100‑recipient limit will bounce with non‑delivery report (NDR) code 550 5.7.236.

Background: The Double‑Edged Sword of onmicrosoft.com

Every Microsoft 365 tenant is provisioned with a free domain in the format yourcompany.onmicrosoft.com. Designed as a testing ground during setup, it has been weaponized by malicious actors who spin up trial tenants, exploit the clean IP reputation, and blast out high‑volume junk mail. The shared domain’s reputation has nosedived, dragging down deliverability for legitimate organizations that still use it in production. Microsoft’s telemetry confirms that abusive behavior concentrates on newly created tenants using the default domain, forcing the company’s messaging security team into action.

The new MOERA (Microsoft Online Email Routing Address) outbound cap is a surgical strike against this vector. It follows broader Exchange Online rate‑limit initiatives, such as the External Recipient Rate Limit (ERR) that caps per‑mailbox external recipients at 2,000, and the tenant‑level Tenant External Recipient Rate Limit (TERRL). Together, these controls aim to reshape how transactional and bulk email flows from Microsoft’s cloud.

The Hard Numbers: MOERA Throttling in Detail

The restriction is unambiguous:

  • Cap: 100 external recipients per organization per 24‑hour rolling window.
  • Scope: Applies only to email sent from addresses that use the onmicrosoft.com domain. Internal messages, meeting invitations, and shared mailbox traffic within the same tenant are not counted.
  • Rejection behavior: Once the tenant surpasses the limit, any further attempt to send to an external recipient is blocked with the SMTP error 550 5.7.236 and a corresponding NDR.
  • Recipient counting: Recipients are tallied after distribution list expansion. Sending a single message to a DL with 50 external members consumes 50 slots, even if some addresses repeat across multiple messages; there is no unique‑recipient deduplication.

These rules apply regardless of the client used—Outlook, Outlook on the web, Graph API, third‑party apps, or connectors. Even hybrid mail flows that route outbound messages through on‑premises relays will count toward the cap if the final destination is external.

Rollout Schedule: Trials First, Then Everyone Else

Microsoft is taking a phased approach based on tenant size, measured by Exchange Online seat counts. The published timeline is:

  • October 15, 2025 – Trial tenants
  • December 2025 – Tiny tenants (typically those with fewer than 25 seats)
  • Additional waves throughout early 2026, culminating with the largest tenants on June 1, 2026

One month before each phase begins, affected organizations will receive a Message Center post (likely MC787382 or similar). Admins must monitor these notifications to know when enforcement will hit their tenant. The staged rollout gives smaller and less‑mature tenants—often the most reliant on the default domain—the least preparation time, heightening the urgency for them to act.

How This Fits with Existing Exchange Online Limits

The MOERA cap is not a replacement for other outbound throttles but a complementary layer. The ERR, announced in 2023, sets a per‑mailbox maximum of 2,000 external recipients per 24 hours for all users, whether on a custom domain or not. It is designed to prevent a single compromised account from flooding the internet with spam. Meanwhile, TERRL (Tenant External Recipient Rate Limit) defines an organization‑wide cap that varies by subscription type and sending history.

The MOERA restriction targets only the onmicrosoft.com namespace with a much stricter envelope—100 recipients per day for the entire tenant. Organizations that have already migrated sending to a verified custom domain (e.g., contoso.com) are unaffected by this specific throttle; they remain subject to the ERR and TERRL but not the 100‑recipient MOERA rule.

Who Wins and Who Loses

Clear Beneficiaries

  • Enterprises and SMBs with custom domains enjoy no impact on production email and may see improved deliverability as the shared namespace sheds its spammers.
  • Recipients and mailbox providers benefit from a cleaner “onmicrosoft.com” reputation, reducing false positives.

Those at Risk

  • Small businesses and hobbyists that never got around to buying a domain and rely exclusively on yourbusiness.onmicrosoft.com for client communication. They will suddenly find external emails bouncing after just a handful of messages to customers.
  • Automation and integrations that use the default identity—service accounts for CRM alerts, monitoring dashboards, legacy SMTP relays, or third‑party SaaS connectors hard‑coded to send as [email protected]. These will fail silently or produce unexpected NDRs, potentially breaking critical workflows.
  • Developers and trial tenants are first in the firing line. Any testing that involves mass emailing to external test accounts will hit the cap immediately once enforcement starts.

The community has already flagged examples: one Microsoft 365 admin reported on Windows News that a nonprofit sending weekly newsletters via a free tenant would be blocked after the first batch of 100 recipients, forcing an abrupt halt to operations. Automotive service reminders, order confirmations from small shops, and even internal IT notifications sent through onmicrosoft.com connectors are all vulnerable.

The Migration Playbook: Move to a Custom Domain

Switching to a verified custom domain is the only reliable way to avoid the MOERA cap while continuing to use Exchange Online for production email. The process is well documented and should be started immediately:

  1. Acquire a custom domain (e.g., through a registrar like Namecheap, GoDaddy, or Cloudflare).
  2. Add and verify the domain in the Microsoft 365 Admin Center under Setup > Domains.
  3. Update user email addresses: Change the primary SMTP address and, if needed, the UPN to the new domain. The old onmicrosoft.com alias can be kept as a secondary address to avoid login disruptions.
  4. Configure authentication: Publish SPF, DKIM, and DMARC records in your domain’s DNS to ensure deliverability and prevent spoofing. Microsoft 365 provides guided wizards for this.
  5. Re‑point all integrations: Locate every app, connector, and script that sends mail using the onmicrosoft.com domain and switch them to the new address. Use Exchange Admin Center reports to identify high‑volume senders.
  6. Test thoroughly: Send test messages to external mailboxes, monitor DMARC aggregate reports, and check the Exchange message trace for any residual onmicrosoft.com flows.
  7. Phase out the old domain: Once everything is verified, remove the onmicrosoft.com address from production use, keeping it only as a fallback for legacy logins.

Quick tips from experienced admins:
- Use PowerShell to audit current external recipient counts and forecast potential breaches. Commands like Get-MessageTrace and Get-MailTrafficReport can highlight accounts that routinely send to more than a few external addresses.
- For large organizations, pilot the migration with a small user group, validate email authentication, and then roll out company‑wide.
- Many third‑party apps use SMTP AUTH with the default domain. These must be reconfigured, and you may need to generate new app passwords or switch to OAuth.

Alternatives for High‑Volume Sending

Exchange Online mailboxes are not built for mass transactional email. Organizations that need to send thousands of receipts, newsletters, or notifications should offload that traffic to dedicated services:

  • Azure Communication Services for Email: Microsoft’s own high‑volume email platform, designed for transactional and B2C messaging. It integrates natively with Azure and offers per‑job pricing with high deliverability SLAs.
  • Specialist Email Service Providers (ESPs): SendGrid, Mailgun, Amazon SES, and SparkPost provide robust APIs, reputation management, and compliance features ideal for marketing and automated flows.
  • Exchange Online High Volume Email (HVE): An internal Microsoft offering for very large‑scale internal mail. Its external sending capabilities have shifted over time; administrators should verify current eligibility and limits with their Microsoft account team.

Moving bulk sending to these platforms not only sidesteps the MOERA limit but also improves analytics, bounce handling, and regulatory compliance (e.g., unsubscribe requirements).

Operational Risks and Community Concerns

Despite the security upside, the change introduces real disruption risks:

  • Silent failures: Automation scripts and third‑party integrations rarely alert admins to bounce codes. A CRM that stops sending invoices because of 550 5.7.236 could go unnoticed for days, leading to missed payments.
  • Incomplete inventory: Many small tenants lack documentation of which services rely on the default domain. Discovering them after the cap kicks in may cause business outages.
  • Message Center reliance: Microsoft’s plan to warn tenants only via Message Center posts assumes active admin monitoring. Overburdened or part‑time IT staff may miss the notice entirely.
  • Counting ambiguities: The rolling 24‑hour window and DL expansion make it hard to predict exactly when a tenant will exceed the limit. A sudden spike in external replies or a forwarded announcement could trip the cap unexpectedly.

To mitigate these, Microsoft recommends that admins run regular outbound traffic reports and set up transport rules to alert on excessive external recipients. The Exchange team has published diagnostic tools in the Exchange Admin Center to help identify tenants nearing limits.

A 90‑Day Action Plan

Administrators should treat the MOERA cap as an immediate priority, not a distant deadline:

Days 0–30: Audit all outbound flows. Use PowerShell and the EAC to identify every sender, connector, and app using onmicrosoft.com. Register a custom domain and begin the verification process.

Days 30–60: Migrate a pilot group. Publish SPF, DKIM, and DMARC. Re‑point integrations one by one, testing thoroughly. Monitor DMARC reports for unauthorized senders.

Days 60–90: Complete the migration for all users. Remove onmicrosoft.com as the primary address. Evaluate whether high‑volume flows should move to Azure Communication Services or an ESP. Confirm that all systems send from the verified domain and that no critical process still depends on the default domain.

The Final Word

Microsoft’s decision to cap onmicrosoft.com outbound email at 100 external recipients per day is a necessary, if disruptive, measure to reclaim the shared namespace from abusers. The policy forces a long‑overdue shift toward custom domains, which bring better authentication, brand trust, and deliverability. For the vast majority of businesses that have already made that transition, the change is a non‑issue. For those who haven’t, the clock is ticking. Administrators who act now—auditing, migrating, and adopting purpose‑built sending platforms—will avoid the panic of bounced emails and broken automations. Those who wait risk alienating customers and stalling operations when the NDRs start piling up.