Microsoft will begin throttling emails sent from the default onmicrosoft.com domain to just 100 external recipients per day, starting with trial tenants on October 15, 2025. The limit is a hard cap per organization per 24‑hour rolling window, and messages that exceed it will bounce with SMTP error code 550 5.7.236. This aggressive move targets the systemic abuse of the Microsoft Online Email Routing Address (MOERA) namespace, a shared domain that spammers have long exploited to churn out phishing and spam at scale. For legitimate organizations still using their companyname.onmicrosoft.com addresses for day‑to‑day business email, the clock is ticking—and the consequences of inaction are immediate and measurable: lost emails, disrupted workflows, and potential damage to customer relationships.

Microsoft’s new policy marks a fundamental shift in how it manages outbound email from its cloud. The MOERA domain was never intended for production use; it was a quick‑start identity for testing and onboarding. But over the years, countless small businesses, nonprofits, and even some enterprises came to rely on it, often without configuring a verified custom domain. Attackers noticed, and the shared reputation of the onmicrosoft.com namespace suffered. Microsoft’s answer is to choke off the abuse at the source while simultaneously pushing tenants toward security best practices: authenticated custom domains with SPF, DKIM, and DMARC.

How the MOERA Throttle Works

The limit is stark: only 100 external recipients per 24‑hour rolling window, counted after recipient expansion. That means a single message sent to a distribution list that expands to 150 external addresses will instantly exhaust the daily quota and trigger NDRs with the error code 550 5.7.236 for any subsequent external sends until the window resets. Internal recipients—those within the same tenant—are not counted. Only exchanges destined to addresses outside the tenant’s accepted domain list tally against the cap.

Microsoft has engineered the policy to be surgical: it affects only emails sent from an @[tenant].onmicrosoft.com address. If your organization delivers mail from a verified custom domain, you are governed by the normal Exchange Online outbound spam and recipient rate limits, not this new MOERA‑specific throttle. The rule is not a replacement for existing tenant‑ or mailbox‑level controls; it is an additional layer designed to make throwaway tenant abuse expensive and operationally painful.

Rollout Timeline: Phased by Tenant Size

Microsoft will roll out enforcement in stages, giving administrators advance notice via Message Center. The schedule provides a clear timeline, but tenants must watch their own notifications—missing the one‑month pre‑notice is the most common operational failure mode.

  • Trial tenants: Enforcement begins October 15, 2025.
  • Tenants with fewer than 3 seats: Enforcement begins December 1, 2025.
  • Medium and large enterprises: Phased through early 2026, with tenants over 10,001 seats reaching enforcement by June 1, 2026.

Administrators should treat their specific Message Center alert as the definitive enforcement date. While Microsoft has built telemetry and operational readiness buffers, it has historically adjusted windows; the official communications are the single source of truth.

Why Microsoft Is Doing This

Shared default domains are an anti‑abuse nightmare. Creating a new Microsoft 365 tenant is trivially easy and often free, giving attackers a low‑cost vector to send bulk spam or phishing campaigns. Because the onmicrosoft.com namespace is shared across millions of tenants, a handful of bad actors can poison the deliverability pond for everyone else. Legitimate tenants that don’t use custom domains often see their messages land in spam folders or get blocked outright due to the domain’s tainted reputation.

By capping the number of external recipients from MOERA identities, Microsoft raises the operational bar. Attackers can no longer fire up a trial tenant and blast out thousands of messages; they’re limited to 100 per day, making the platform far less attractive for abuse. This protects the overall ecosystem and restores some trust in the namespace for the few legitimate uses that remain—such as initial tenant setup, testing, and emergency fallback.

The policy also serves as a governance nudge. It forces organizations to adopt verified custom domains, which enable full control over authentication (SPF, DKIM, DMARC) and brand consistency. Microsoft’s larger goal is to move tenants off a shared identity that was never built for production and onto domains they own and can properly manage.

Who Is Most Affected

The pain of this change falls unevenly. The primary beneficiaries are enterprises already using custom domains; they will see minimal direct impact. The at‑risk groups include:

  • Small businesses, nonprofits, hobbyist projects, and trial tenants that never configured a custom domain.
  • Applications, automation, and third‑party services hard‑coded to send from @tenant.onmicrosoft.com addresses—think monitoring alerts, support ticketing systems, and one‑time password generators.
  • Hybrid environments where mail flow routes externally after seeming to be internal; such routes may still count against the quota if the final destination is outside the accepted domain list.

A single overlooked automation that fires off 101 status emails to external partners overnight will cause a hard stop. Recovery is not instant: the rolling window must naturally move past the breach, and during that time all other external mail from the tenant will bounce. This makes the impact of the throttle both immediate and disruptive for unprepared organizations.

Operational Consequences and Migration Pain Points

Migrating off the onmicrosoft.com domain is, on paper, straightforward—change the primary SMTP address on mailboxes. In practice, it touches many layers of an organization’s IT stack.

  • Primary SMTP and UPN alignment: Changing a user’s primary email address often requires updating their user principal name (UPN) to match. This can force re‑authentication on all devices, disrupt OneDrive and Teams sessions, and break cached credentials in Office apps. Plan for a support spike.
  • Applications and connectors: Scripts, SMTP connectors, line‑of‑business apps, and cloud services that hard‑code an onmicrosoft.com address must be reconfigured. Where reconfiguration isn’t possible, route those flows through an authenticated exchange connector or a dedicated transactional email service.
  • Authentication and deliverability: A new custom domain must have its SPF record published, DKIM signing enabled, and DMARC implemented (starting with p=none). Skipping these steps results in spoofed‑looking mail and deliverability failures. Without DKIM, even legitimate mail may be quarantined.
  • Distribution list auditing: Because recipients are counted after expansion, a single message to a large nested group can consume the entire 100‑recipient quota. Audit and split external‑heavy lists, or move those contacts to a specialist email platform.

Organizations that treat this as a simple domain flip without a thorough inventory and testing phase are likely to encounter cascading failures.

A Practical 30/60/90 Migration Plan

Administrators have a clear runway to act before their enforcement date. The following plan distills the necessary steps:

0–30 days (Immediate)
- Run PowerShell scripts to audit all senders using @*.onmicrosoft.com addresses: user mailboxes, shared mailboxes, service accounts, connectors, scheduled tasks, and applications. Log their external recipient volumes.
- Acquire and validate a custom domain in Microsoft 365 / Entra. Complete DNS verification and add the domain.
- Communicate the migration plan to stakeholders, schedule pilot windows, and prepare a support plan.

30–60 days (Plan & Test)
- Pilot the migration with a representative user group. Update their primary SMTP addresses to the custom domain; align UPNs if needed. Observe OneDrive, Teams, and device login behavior.
- Publish SPF records for the custom domain, enable DKIM signing, and deploy DMARC in p=none mode. Monitor aggregate reports (RUA) for anomalies.
- Reconfigure connectors, applications, and third‑party services to use the custom domain or an authenticated relay. Test thoroughly.

60–90+ days (Execute & Monitor)
- Complete the migration for all remaining mailboxes, retaining onmicrosoft.com addresses only as secondary aliases where needed for legacy login compatibility.
- Monitor Exchange Admin Center, Message Center, and DMARC reports for delivery issues. Tune DMARC policy gradually toward p=reject.
- Move any high‑volume external sending (marketing newsletters, transactional emails) to a dedicated email service provider (ESP) or Azure Communication Services.

Alternatives for Legitimate High‑Volume Sending

For organizations that need to send bulk external email, Exchange Online mailboxes are not the right tool—even with a custom domain. Microsoft recommends dedicated platforms:

  • Azure Communication Services for Email: Microsoft’s first‑party cloud solution for transactional and B2C high‑volume messaging. It handles reputation, scaling, and compliance out of the box.
  • Specialist ESPs: Services like SendGrid, Mailgun, Amazon SES, and SparkPost are purpose‑built for deliverability, analytics, and list management. They integrate with Microsoft 365 connectors or APIs.
  • Exchange Online High Volume Email (HVE): Currently in preview, HVE is designed for internal bulk mail (think company‑wide announcements) with enhanced reporting and security. It is not a workaround for MOERA external sending limits; it serves internal workflows and does not change the external cap.

Choosing the right tool keeps your email strategy compliant and reliable, and avoids awkward workarounds that eventually hit another limit.

Strengths and Weaknesses of Microsoft’s Approach

This move is not without its critics, but its design reflects a thoughtful balance between ecosystem protection and operational reality.

Strengths
- Directly neutralizes the abuse vector. Limiting the shared namespace to 100 external recipients per day makes throwaway tenants economically unviable for spam.
- Encourages best practices: verified domains, SPF/DKIM/DMARC, and proper reputation management. Over time, this improves global deliverability.
- Surgical enforcement minimizes collateral damage for well‑managed tenants. The vast majority of production organizations already use custom domains and will feel no impact.

Weaknesses
- Collateral damage for small, legitimate tenants without IT resources. A small nonprofit that sends a weekly newsletter to 150 external supporters will suddenly find their mail bouncing, with little warning beyond an easily missed Message Center post.
- Migration complexity is real and costly. Changing primary SMTP addresses and UPNs across many users and systems is non‑trivial. Hard‑coded addresses in legacy software are especially painful.
- The 24‑hour rolling window with expansion counting can trip up even prepared teams if they overlook a single automated distribution list. Recovery is not immediate, causing business disruption.

Overall, the policy’s benefits far outweigh its costs if organizations take the deadline seriously and prioritize migration.

Immediate Actions for Administrators

  • Run an inventory script to list every sender using an onmicrosoft.com address and track their external recipient count. Prioritize high‑volume senders.
  • Preserve onmicrosoft.com aliases as secondary addresses during cutover to reduce login breakage. Only change the primary SMTP.
  • Audit distribution groups. Split lists that contain many external recipients or move them to an ESP.
  • For automated flows that cannot be reconfigured, route them through an authenticated SMTP connector or a transactional email service.
  • Subscribe to Message Center notifications and set up alerts so the one‑month pre‑notice is never missed.

Administrators who start today can complete their migration within the typical 90‑day window and avoid service interruptions entirely.

Final Assessment

Microsoft’s MOERA throttling is a decisive, ecosystem‑level intervention. It stops a long‑standing abuse pattern dead in its tracks, protects deliverability for the overwhelming majority of enterprises, and forces the remaining organizations to adopt modern email authentication practices. The pain is real but concentrated: small tenants and automation‑dependent workflows. The value proposition is clear: a defined deadline to improve security and reliability.

The message is unambiguous: onmicrosoft.com is a testing and tenancy namespace, not a production sending domain. The timetable gives administrators a defined runway; those who act now will migrate smoothly. Those who wait will face bounced mail, frustrated users, and a rush to fix problems under pressure. The choice is stark—and the cost of delay is measured in lost business.