Microsoft will begin capping email sent from the default onmicrosoft.com domain to just 100 external recipients per organization per rolling 24-hour window, a move the company says is necessary to crush the rampant spam and phishing abuse that has plagued the shared namespace for years. The policy, which the Exchange team internally calls the MOERA (Microsoft Online Email Routing Address) throttle, starts its phased rollout with trial tenants on October 15, 2025, and eventually touches every Microsoft 365 tenant – from one-person shops to enterprises with over 10,000 seats – by June 1, 2026.

The restriction is surgically narrow: it applies only to messages that originate from an @yourtenant.onmicrosoft.com address. Email sent from a verified custom domain – even when the tenant also uses the onmicrosoft.com namespace for other purposes – escapes the cap and remains governed by the standard Exchange Online outbound limits, such as the tenant-wide external recipient rate limit (TERRL) and per‑mailbox external recipient rate (ERR). Microsoft is betting that by cutting off the easy abuse path of throwaway tenants using the shared default domain, the overall reputation of the onmicrosoft.com namespace will improve, deliverability will rise for legitimate senders, and organizations will finally be nudged to adopt proper branded domains with SPF, DKIM, and DMARC.

The technical specifics: how the MOERA throttle works

The new rule functions as a tenant‑level ceiling on external recipients originating from the onmicrosoft.com domain. Here are the hard facts administrators need to know:

  • Throttle value: 100 external recipients per tenant per 24‑hour rolling window. Internal recipients (any address within the tenant’s accepted domains) are not counted.
  • Recipient counting logic: External recipients are counted after distribution list expansion. If a single message is sent to a distribution group that expands to 200 external members, all 200 are counted – instantly exceeding the cap and blocking subsequent external mail for the remainder of the window.
  • Failure mode: When the cap is reached, the Exchange transport stack rejects further attempts to send to external recipients from MOERA addresses and returns a non‑delivery report (NDR) with SMTP error 550 5.7.236.
  • Scope: The throttle only activates for messages where the P1 (envelope) sender or the From header is an address in the onmicrosoft.com namespace. Sending from a custom domain – even if the mailbox’s primary SMTP address is still onmicrosoft.com – is not captured, provided the sending identity used is the custom domain alias.

This design is intentionally different from the broader outbound throttles Microsoft has already deployed. The well‑known tenant‑wide external recipient rate limit (TERRL) applies to all outbound traffic from a tenant regardless of the sender domain, with a threshold formula based on the number of paid licenses. TERRL became effective for all tenants in May 2025 and typically sits in the tens of thousands or more for even small tenants. The MOERA cap is an additional, much lower, hard‑stop specifically for the shared namespace – an emergency brake against the kind of disposable tenants that have repeatedly damaged the onmicrosoft.com reputation.

Rollout timeline: staggered by tenant size

Microsoft will enforce the MOERA throttle in eight stages, keyed to the number of Exchange Online seats (licenses) in a tenant. The published schedule is:

  • Trial tenants: October 15, 2025
  • <3 Exchange seats: December 1, 2025
  • 3–10 seats: January 7, 2026
  • 11–50 seats: February 2, 2026
  • 51–200 seats: March 2, 2026
  • 201–2,000 seats: April 1, 2026
  • 2,001–10,000 seats: May 4, 2026
  • >10,001 seats: June 1, 2026

Microsoft will deliver a Message Center post to affected tenants one month before enforcement begins for their cohort. Administrators who do not actively monitor Message Center risk being caught off guard when their onmicrosoft.com‑based automation or user mail suddenly bounces. Each stage’s enforcement date is firm; Microsoft has not indicated any grace period or opt‑out.

Why Microsoft is taking this step

The MOERA throttle is the culmination of a multi‑year arc of outbound abuse controls. Microsoft has already imposed the mailbox external recipient rate limit (ERR) and the tenant‑wide TERRL, and in 2024 blocked external chat in Teams for trial tenants. The common thread: cheap, easily provisioned tenants were being weaponized to send spam, phishing lures, and malware. Because these tenants used the shared onmicrosoft.com domain, a single burst of abuse could tarnish the sender reputation for every legitimate tenant also using that namespace.

By capping MOERA‑sourced external email at a draconian 100 recipients per day, Microsoft achieves three goals:

  1. Directly raises the cost of abuse: Attackers can no longer spin up a trial tenant and immediately blast thousands of external targets from the onmicrosoft.com address. They would need to provision multiple tenants or move to custom domains – both of which leave a more traceable footprint.
  2. Incentivizes best practice: The policy forces organizations to own and verify a domain, properly configure DNS authentication records, and use that domain for all production external email. This aligns with longstanding industry guidance for email deliverability.
  3. Improves the shared namespace reputation: With less abuse traffic flowing from onmicrosoft.com addresses, legitimate mail from tenants that still rely on MOERA for low‑volume notifications should see fewer false positives and better inbox placement.

Who will feel the impact – and who won’t

The throttle is a non‑event for tenants that have already adopted a custom domain as the primary sender for all external mail. If your users’ From addresses display your own domain and your DNS records are in order, the MOERA cap will not apply to that traffic. You will only need to worry about edge cases where an onmicrosoft.com address might still be used, such as:

  • Automated emails from third‑party services that hard‑coded the onmicrosoft.com address.
  • “Send As” or “Send on Behalf” permissions that still reference the MOERA alias.
  • System‑generated messages from Bookings, Teams, or SharePoint that were never reconfigured to use a custom domain.

Conversely, the highest‑impact groups include:

  • Small businesses, trial users, and hobbyists that set up their tenant and never purchased or configured a custom domain. These tenants often use the onmicrosoft.com address as the primary sender for everyday email. Once the cap hit, they will be unable to send to more than 100 external contacts in a day – a threshold easily exceeded by a single newsletter or a busy day of customer correspondence.
  • Automation and SaaS integrations that rely on MOERA identities. Monitoring tools, ticket systems, e‑commerce platforms, and CRMs that send alerts to external parties using the tenant’s onmicrosoft.com address will silently break unless the sending identity is updated to a custom domain or routed through a transactional email service.
  • Tenants that inadvertently use MOERA for SRS (Sender Rewriting Scheme) or as the default domain for features like forwarding. Because recipient expansion counts after expansion, a single auto‑forward of an external email to a distribution list containing external members can consume the entire daily quota.

A practical migration checklist: 30/60/90‑day plan

For tenants that still depend on the onmicrosoft.com domain for external sending, a structured cutover is the only way to avoid service disruption. Here is a phased playbook proven in early adoption:

0–30 days: immediate triage

  • Audit current senders. Use Exchange Admin Center reports and Message Trace to identify every mailbox, connector, and application sending from *@yourtenant.onmicrosoft.com. A PowerShell script can automate the trace and export a list of source mailboxes.
  • Catalog hard‑coded addresses. Inventory integrations, monitoring systems, and scripts that may be using the MOERA address. Pay special attention to any service that mails external contacts.
  • Purchase and verify a custom domain. Choose a domain you own, add it to Microsoft 365 / Entra ID, and prove ownership via DNS TXT record. Plan the DNS zone to host SPF, DKIM, and DMARC records.

30–60 days: plan and test

  • Add aliases and pilot users. For a small pilot group, add a custom‑domain SMTP alias as a secondary address, then promote it to the Primary SMTP. Align the user’s UPN (sign‑in name) with the new primary if you want a uniform experience, but be aware of potential impacts on OneDrive links and cached credentials.
  • Reconfigure connectors and applications. Update SMTP relays, printer‑scanner senders, and any webhook or API‑based sending tools to use the custom domain. For high‑volume transactional mail, consider offloading to a dedicated email service provider (SendGrid, Mailgun, Amazon SES, etc.) so that future Exchange outbound limits never become a bottleneck.

60–90+ days: execute and monitor

  • Staged cutover. Migrate remaining users in waves, keeping MOERA addresses as secondary aliases for legacy compatibility. Monitor mail flow using the Exchange admin center’s outbound reports and DMARC aggregate reports from your domain provider.
  • Lock and observe. After each wave, search Message Trace for NDRs with the code 550 5.7.236 to spot throttled sends. Adjust distribution lists that contain external members to ensure they do not unexpectedly consume the quota.

Detection, diagnostics, and the NDR play

When a tenant hits the MOERA wall, the transport pipeline generates a specific NDR: 550 5.7.236. This is the unmistakable fingerprint that the onmicrosoft.com address has exhausted its 100‑recipient budget. Administrators can pre‑emptively search for this code in message trace logs and set up alerts in Microsoft Sentinel or Defender for Office 365 to catch it in real time.

For proactive monitoring, use the following Exchange Online PowerShell cmdlet to retrieve a snapshot of recent traffic from MOERA addresses:

Get-MessageTrace -StartDate (Get-Date).AddHours(-24) -EndDate (Get-Date) | Where-Object {$_.SenderAddress -like "*@yourtenant.onmicrosoft.com" -and $_.RecipientAddress -notlike "*@yourtenant.onmicrosoft.com"}

The output will reveal which accounts are still using the shared domain to reach outside the organization, allowing you to remediate before enforcement catches you.

Risk assessment: strengths and potential downsides

From a security and ecosystem‑health perspective, the MOERA throttle is a nett positive. It surgically targets the abuse vector that has long undermined the onmicrosoft.com namespace, and it costs Microsoft nothing in terms of infrastructure—the limit is enforced at the transport layer. Legitimate tenants that already follow domain best practices will see no disruption, and many may find their own deliverability improves as the overall reputation of the namespace climbs.

However, every broad‑stroke anti‑abuse measure carries collateral risk:

  • Disruption for the smallest tenants. Inexpensive or free trials are often the stepping stone for startups and sole proprietors. A 100‑recipient cap can be suffocating for a business that relies on the onmicrosoft.com address while still building its brand. Some may legitimately not understand why their email stopped working, and Microsoft’s support channels may be overwhelmed in the first weeks of each enforcement phase.
  • Migration friction. Changing primary SMTP addresses is more than a mailbox tweak. Aligned UPN changes can ripple into single sign‑on, device registration, and even file‑sharing links. Organizations that pushed through a migration without proper planning have seen temporary lockouts and broken workflows.
  • Hidden dependencies. In complex hybrid environments, on‑premises Exchange servers or third‑party tools may still reference mail.onmicrosoft.com addresses. Automated replies (OOF, automatic forwarding) can generate external email that counts against the cap without administrators ever seeing the origin. A thorough, scripted discovery is essential.
  • Communication gaps. The staggered rollout relies entirely on Message Center notifications. Tenants that ignore these posts – a chronic problem in the Microsoft 365 space – may have business‑critical messages bounced before they realize the policy is active.

Tie‑in to broader outbound controls: TERRL and ERR

The MOERA throttle does not replace the tenant‑wide external recipient rate limit (TERRL) or the per‑mailbox external recipient rate (ERR) – it complements them. TERRL, which went into effect for all tenants on May 1, 2025, uses a formula based on purchased licenses to set a meter on total external recipients from any domain within the tenant. For a tenant with 100,000 seats, that threshold is over 1.5 million recipients per day – an order of magnitude higher than the MOERA cap. The TERRL is designed to stop a tenant from turning Exchange Online into a bulk mail platform, while the MOERA cap is designed to stop an unverified tenant from sending even modest amounts of spam from a domain they don’t own.

Administrators should view these controls as layers in a defense‑in‑depth strategy. Mail that passes the MOERA check (because it originates from a custom domain) is still subject to TERRL, ERR, and other content‑based filters. For organizations that need to send high volumes of external email – marketing campaigns, transactional alerts, password resets – Microsoft’s official recommendation is to use Azure Email Communication Services (ECS) or Exchange Online High‑Volume Email (HVE), both of which bypass TERRL and the MOERA cap because they operate on separate infrastructure.

The bottom line: an invitation to tidy tenant hygiene

The MOERA throttle is an aggressive but predictable move. Microsoft has been telegraphing its intolerance of default‑domain abuse for years, and the phased rollout gives organizations ample time to prepare. For the majority of well‑managed tenants, the change will be invisible. For those that have relied on the onmicrosoft.com address as a free‑lunch production sender, the days of that convenience are numbered.

Administrators should use the coming weeks to run a comprehensive audit, get a custom domain verified, and pilot the transition before their enforcement date arrives. The technical path is straightforward; the operational impact depends entirely on how early you start. With the first wave hitting trial tenants on October 15, 2025, the clock is already ticking.