Microsoft is imposing a hard limit on outgoing email from free “.onmicrosoft.com” (MOERA) tenant domains to combat widespread abuse and protect delivery for legitimate Microsoft 365 customers, and the change — which takes effect in staged waves starting October 15, 2025 for trials — restricts MOERA-hosted tenants to 100 external recipients per 24‑hour rolling window, with internal mail flows unaffected. (techcommunity.microsoft.com)
Microsoft 365 historically supplies every new tenant with a free default domain that looks like yourcompany.onmicrosoft.com. That domain is convenient for initial setup and testing, but large numbers of tenants continue to use it as a production sending identity. Because the “onmicrosoft.com” namespace is shared and widely abused by spammers and opportunistic actors, Microsoft’s security and messaging teams say the shared reputation has suffered — degrading deliverability for legitimate senders and increasing blocked or flagged messages across the ecosystem. Microsoft’s messaging team has therefore moved to formally restrict regular outbound usage of MOERA domains and to encourage customers to use their own custom domains for production email. (techcommunity.microsoft.com)
This change sits alongside broader Exchange Online rate‑limit work announced over the last year (the External Recipient Rate Limit / ERR, also described as a tenant-level outbound cap) intended to curb bulk‑sending misuse across Exchange Online. That other limit (a per‑mailbox external recipient cap in the low thousands) is a separate but related control and highlights Microsoft’s push to reshape how high‑volume and transactional mail is sent from Microsoft cloud infrastructure. (techcommunity.microsoft.com, bleepingcomputer.com)
Practical evidence of malicious use of Microsoft services (for example, social engineering and sextortion campaigns that leverage Microsoft messaging flows) underlines the urgency and context for the change; community reports have documented attackers abusing administrative or sharing features as part of scams, making tenant hygiene and domain ownership more critical.
Administrators who proactively register a custom domain, authenticate it with SPF/DKIM/DMARC, and move production sending off MOERA addresses will gain better deliverability, brand control, and lower operational risk. Organizations that delay the migration risk broken automation, rejected external messages, and confused customers when outbound mail suddenly bounces with a 550 error.
In short: treat the onmicrosoft.com address as a testing identity only. Plan migration now, audit integrations and automation, and move any external‑facing or high‑volume email to a verified domain or a purpose‑built email service to preserve delivery, reputation, and customer trust. (techcommunity.microsoft.com, practical365.com)
Source: Windows Report Microsoft Limits Free "onmicrosoft" Email Domains to Stop Spam
Background / Overview
Microsoft 365 historically supplies every new tenant with a free default domain that looks like yourcompany.onmicrosoft.com. That domain is convenient for initial setup and testing, but large numbers of tenants continue to use it as a production sending identity. Because the “onmicrosoft.com” namespace is shared and widely abused by spammers and opportunistic actors, Microsoft’s security and messaging teams say the shared reputation has suffered — degrading deliverability for legitimate senders and increasing blocked or flagged messages across the ecosystem. Microsoft’s messaging team has therefore moved to formally restrict regular outbound usage of MOERA domains and to encourage customers to use their own custom domains for production email. (techcommunity.microsoft.com)This change sits alongside broader Exchange Online rate‑limit work announced over the last year (the External Recipient Rate Limit / ERR, also described as a tenant-level outbound cap) intended to curb bulk‑sending misuse across Exchange Online. That other limit (a per‑mailbox external recipient cap in the low thousands) is a separate but related control and highlights Microsoft’s push to reshape how high‑volume and transactional mail is sent from Microsoft cloud infrastructure. (techcommunity.microsoft.com, bleepingcomputer.com)
What Microsoft is changing (technical specifics)
MOERA throttling: hard facts
- Throttle: MOERA (onmicrosoft.com) outgoing email will be throttled to 100 external recipients per organization per 24‑hour rolling window. Internal messages (within the tenant) are not counted against this limit. (techcommunity.microsoft.com)
- Error behavior: Attempts to send to external recipients beyond this cap will be rejected and generate NDRs (bounce messages) with SMTP code 550 5.7.236 while the tenant is throttled. (techcommunity.microsoft.com)
- Counting rules: External recipients are counted after expansion (distribution lists and recipient expansion count towards the total). (techcommunity.microsoft.com)
Rollout schedule (staged by tenant size)
Microsoft will roll this out in stages based on Exchange seat counts — trials first, then progressively larger tenants. The published schedule begins with trial tenants on October 15, 2025, moving through tiny tenants in December 2025, to the largest tenants in June 1, 2026. Microsoft will issue Message Center notices to impacted tenants one month before each stage begins. Administrators must monitor the Message Center to see the advisories relevant to their tenant. (techcommunity.microsoft.com)Where this sits relative to other Exchange limits
The MOERA limit is distinct from the Exchange External Recipient Rate Limit (ERR) and other tenant‑level outbound controls Microsoft has announced. The ERR initiative caps external recipients per mailbox (various announcements proposed 2,000 external recipients per mailbox in certain timelines) and is aimed at per‑user prevention of bulk email abuse. MOERA throttling is a targeted restriction that specifically addresses the shared, default onmicrosoft.com namespace and places a much lower per‑tenant cap for that namespace only. Administrators running real production mail on a custom domain are subject to the regular ERR / tenant outbound calculations, not the MOERA 100‑recipient rule. (techcommunity.microsoft.com)Why Microsoft did this: the anti‑abuse rationale
Shared default domains are a long‑standing attack surface. Bad actors sign up for trial tenants and immediately start sending spam or phishing at scale using onmicrosoft.com addresses because a newly created tenant inherits a “clean” sending IP and a default domain that can look legitimate to naive filters and recipients. The result is:- rapid degradation of shared domain reputation,
- collateral damage to legitimate tenants still relying on MOERA addresses, and
- increased deliverability issues for millions of customers.
Practical evidence of malicious use of Microsoft services (for example, social engineering and sextortion campaigns that leverage Microsoft messaging flows) underlines the urgency and context for the change; community reports have documented attackers abusing administrative or sharing features as part of scams, making tenant hygiene and domain ownership more critical.
Real‑world impact: who wins, who risks disruption
Beneficiaries
- Most enterprises and professional organizations that use a branded custom domain will see no direct impact to production sending, because their mail flows originate from their own domains once configured properly.
- Customers that migrate away from MOERA to proper domains typically gain better email deliverability, improved brand presentation, and clearer DKIM/SPF/DMARC control.
At‑risk groups
- Small businesses and hobbyists that never set up a custom domain and use only the onmicrosoft.com address for day‑to‑day email will see outbound mail to external recipients fail once the tenant hits 100 external recipients in 24 hours.
- Automation and SaaS integrations that use the onmicrosoft.com identity (service accounts, monitoring alerts, legacy connectors, embedded OTP systems, or third‑party apps hard‑coded to use the default address) risk unexpected failures.
- Developers and trial tenants who rely on the default tenant for broad external testing will hit the limit earliest (trial tenants are first in the rollout).
Practical migration checklist: how to avoid the limit and restore reliability
The good news is the path away from MOERA is standard and well‑understood. The recommended migration is straightforward but must be planned and executed to avoid breakages.- Buy a custom domain (for example, yourcompany.com).
- Add the domain to Microsoft 365 / Entra and verify ownership in the Microsoft 365 Admin Center.
- Update user email addresses (UPNs and SMTP addresses) to use the custom domain; preserve the onmicrosoft.com aliases during transition if needed.
- Publish SPF, DKIM and DMARC records for the new domain to ensure authentication‑based deliverability.
- Reconfigure any applications, connectors, or automation that use onmicrosoft.com addresses (service accounts, SMTP relays, Azure services, monitoring alerts, webhook senders).
- Test delivery and monitor the Exchange Admin Center reports and Message Center notifications.
- Remove or minimize usage of the onmicrosoft.com address once the custom domain is fully live; maintain aliases only as needed for legacy login compatibility. (techcommunity.microsoft.com, practical365.com)
Quick tips for the migration
- Keep the old onmicrosoft.com addresses as secondary aliases during the cutover to avoid login problems with apps that still use the legacy username format.
- Use staged rollouts for large estates: migrate a pilot group, validate DKIM/SPF/DMARC, then migrate the rest.
- Use the Exchange Admin Center and PowerShell to locate high‑volume senders to external recipients before enforcement—these accounts are the ones most likely to trip the limit. The Exchange team has published tools and reporting to help identify senders nearing limits. (techcommunity.microsoft.com, practical365.com)
Alternatives for legitimate high‑volume sending
Not all organizations need to use Exchange Online mailboxes as their transactional or high‑volume channel. Microsoft and independent providers recommend specialized services for high throughput:- Azure Communication Services for Email (Azure ECS) — Microsoft’s recommended path for high‑volume transactional and B2C messaging, built for scale and distinct from Exchange Online. (techcommunity.microsoft.com)
- Dedicated Email Service Providers (SendGrid, Mailgun, Amazon SES, SparkPost, etc.) — industry‑standard options for newsletters, marketing, and transactional blasts with reputation and deliverability tooling.
- Exchange Online High Volume Email (HVE) — an internal Microsoft construct for scaled internal messaging (note: HVE’s external recipient capabilities and commercial model have evolved; organizations should confirm current HVE policy and availability).
Common admin questions and gotchas
Will internal mail continue to work?
Yes — Microsoft’s MOERA throttling is specifically for external recipients. Internal emails within the tenant are not counted against the 100‑recipient MOERA cap. (techcommunity.microsoft.com)What bounce or error will senders see?
When the MOERA cap is exceeded, senders will receive a non‑delivery report (NDR) with code 550 5.7.236 for attempts to send to external recipients while throttled. That code is Microsoft’s stated enforcement response. (techcommunity.microsoft.com)How are recipients counted?
Microsoft counts recipients after distribution expansion (so sending to lists or multiple recipients can multiply counts). Repeated sends to the same external address are counted per message; there is no unique‑recipient de‑duplication for the MOERA throttle. (techcommunity.microsoft.com)Will hybrid tenants or on‑prem relays be affected?
The policy counts recipients destined to domains not on the tenant’s accepted domain list; hybrid mail flow paths that ultimately deliver externally are counted. Administrators with hybrid setups should validate how routing and connectors are counted in reporting and test message flows. (techcommunity.microsoft.com)What about existing tenant‑level outbound formulas (TERRL/TERR, etc.)?
Microsoft has been rolling out a family of tenant and mailbox‑level outbound controls (ERR, MERRL, TERRL). These govern broader external recipient behavior and are separate from, but related to, the MOERA restriction. Organizations should review their tenant’s published limits and reporting in the Exchange Admin Center. (techcommunity.microsoft.com, mc.merill.net)Risk analysis: strengths, weaknesses and practical concerns
Strengths of Microsoft’s approach
- Directly targets the attacker vector. Limiting the shared namespace makes it harder for newly provisioned tenants to be used as throwaway spamming platforms.
- Encourages best practice. Forcing or nudging tenants toward verified custom domains improves brand trust and enables proper DKIM/SPF/DMARC configuration.
- Protects deliverability for legitimate senders. Reducing reputation bleed helps recipients’ inbox providers make more appropriate spam/ham decisions.
Potential downsides and operational risks
- Collateral disruption to legitimate users who forgot to configure a custom domain, or who rely on onmicrosoft.com for automation and logins. Some small businesses, non‑profits, or product trials may face sudden external email failures.
- Migration complexity for embedded systems. Hard‑coded addresses, SaaS integrations, and third‑party apps that use onmicrosoft.com may break silently, causing business process failures.
- Communication and timing risk. Staged enforcement relies on Message Center notifications; tenants that miss notices or lack active admin monitoring could be surprised by bounces.
- Edge cases in counting and reporting. Distribution lists, connector routing, and hybrid setups may make it non‑trivial to forecast whether a tenant will exceed the 100‑recipient MOERA cap during normal operations.
Recommended action plan for administrators (30/60/90 day)
- 0–30 days (Immediate)
- Audit current outbound senders to external recipients (use Exchange reports and PowerShell).
- Identify any accounts, connectors, or apps using onmicrosoft.com addresses.
- Register a custom domain and validate it in Microsoft 365 if you don’t already have one. (techcommunity.microsoft.com, practical365.com)
- 30–60 days (Plan & Test)
- Move a small pilot group of users and a representative set of automation to the custom domain.
- Publish SPF/DKIM/DMARC for the new domain and monitor DMARC reports for delivery anomalies.
- Reconfigure integrations (monitoring tools, ticket systems, SaaS vendors) to use new addresses. (practical365.com)
- 60–90+ days (Execute & Monitor)
- Complete the migration for remaining users, keep legacy onmicrosoft.com aliases only as needed.
- Monitor Exchange Admin Center for any warnings and review Message Center announcements related to your seat counts.
- Consider moving high‑volume external sending to Azure Communication Services or a specialist ESP. (techcommunity.microsoft.com)
Final assessment — what this means for email deliverability and reputation
Microsoft’s MOERA throttling is a surgical policy that addresses a real abuse vector: the shared onmicrosoft.com namespace. By limiting external sending from that namespace to 100 external recipients per tenant per day, Microsoft tightens the gate on cheap, throwaway tenants that damage shared reputation and cause collateral deliverability problems. The policy’s staged rollout, clear error codes, and public advisories give administrators time to migrate, but the change is consequential for any tenant still relying on onmicrosoft.com as a production sending domain. (techcommunity.microsoft.com, bleepingcomputer.com)Administrators who proactively register a custom domain, authenticate it with SPF/DKIM/DMARC, and move production sending off MOERA addresses will gain better deliverability, brand control, and lower operational risk. Organizations that delay the migration risk broken automation, rejected external messages, and confused customers when outbound mail suddenly bounces with a 550 error.
In short: treat the onmicrosoft.com address as a testing identity only. Plan migration now, audit integrations and automation, and move any external‑facing or high‑volume email to a verified domain or a purpose‑built email service to preserve delivery, reputation, and customer trust. (techcommunity.microsoft.com, practical365.com)
Source: Windows Report Microsoft Limits Free "onmicrosoft" Email Domains to Stop Spam
