Microsoft has given a clear ultimatum to organizations still using the shared .onmicrosoft.com sending address: migrate to a verified custom domain or expect severe outbound throttling that will constrain external email to just 100 external recipients per organization in any 24‑hour rolling window for mail sent from MOERA (Microsoft Online Email Routing Address) domains. This restriction — aimed squarely at curbing abuse of freshly provisioned tenants and protecting the shared onmicrosoft.com reputation — is rolling out in stages beginning with trial tenants on October 15, 2025 and progressing through larger organizations over the following months. (techcommunity.microsoft.com)
Microsoft automatically issues every new Microsoft 365 tenant a default domain that looks like companyname.onmicrosoft.com. That domain was designed for quick setup, testing, and early-stage tenant configuration, not as a long‑term production sending domain. Over time, many organizations left MOERA addresses in place for convenience — and spammers and opportunistic actors repeatedly exploited newly created tenants to blast external recipients from these shared namespaces. The resulting abuse has degraded the reputation of the onmicrosoft.com namespace and caused collateral deliverability problems for legitimate senders that continued to rely on it. (techcommunity.microsoft.com, proofpoint.com)
This new MOERA throttling sits alongside broader Exchange Online rate‑limit initiatives Microsoft has been rolling out in recent years — notably the per‑mailbox/tenant external recipient rate controls intended to prevent cloud mailboxes from sending high volumes of external mail. Those efforts include the Exchange Online External Recipient Rate (ERR/MERRL) work that targets per‑mailbox and tenant‑wide bulk sending. The MOERA limit is a narrower, surgical control that targets the shared onmicrosoft.com namespace specifically. (techcommunity.microsoft.com, practical365.com)
Beyond simple reputation damage, the vector is operationally noisy for email security teams. Third‑party abuse researchers and security vendors have documented a steady stream of onmicrosoft.com‑based abuse campaigns and tenant relays that escalate quarantine volumes and require manual mitigation — a clear signal that automated sender‑level controls alone were not sufficient. Microsoft’s MOERA policy is an ecosystem measure intended to reduce that noise by discouraging production sending from any shared namespace Microsoft controls. (proofpoint.com, bleepingcomputer.com)
However, several legitimate risks and operational burdens must be acknowledged:
Organizations should treat the October–December 2025 window for small tenants as a hard deadline for planning and at least start the migration steps now: acquire and verify a custom domain, configure SPF/DKIM/DMARC, update mailbox primary SMTPs and UPNs in a coordinated way, reconfigure applications and connectors, and move high‑volume sends to dedicated transactional systems. Waiting until the Message Center notice arrives is a risky gamble; by then the operational work will be compressed and user impact more visible.
For administrators, the immediate action is simple: inventory everything that sends from onmicrosoft.com, build a migration plan, and execute early. The platform change will reduce abuse and improve global deliverability — but only if tenants make the switch before their MOERA quota becomes an operational bottleneck. (techcommunity.microsoft.com, learn.microsoft.com)
Source: theregister.com Microsoft puts the squeeze on onmicrosoft.com freeloaders
Background
Microsoft automatically issues every new Microsoft 365 tenant a default domain that looks like companyname.onmicrosoft.com. That domain was designed for quick setup, testing, and early-stage tenant configuration, not as a long‑term production sending domain. Over time, many organizations left MOERA addresses in place for convenience — and spammers and opportunistic actors repeatedly exploited newly created tenants to blast external recipients from these shared namespaces. The resulting abuse has degraded the reputation of the onmicrosoft.com namespace and caused collateral deliverability problems for legitimate senders that continued to rely on it. (techcommunity.microsoft.com, proofpoint.com)This new MOERA throttling sits alongside broader Exchange Online rate‑limit initiatives Microsoft has been rolling out in recent years — notably the per‑mailbox/tenant external recipient rate controls intended to prevent cloud mailboxes from sending high volumes of external mail. Those efforts include the Exchange Online External Recipient Rate (ERR/MERRL) work that targets per‑mailbox and tenant‑wide bulk sending. The MOERA limit is a narrower, surgical control that targets the shared onmicrosoft.com namespace specifically. (techcommunity.microsoft.com, practical365.com)
What Microsoft is changing (the hard facts)
- Throttle: Messages sent from addresses in the .onmicrosoft.com namespace will be limited to 100 external recipients per organization per 24‑hour rolling window. Internal-only messages (within the same tenant) are not counted against this cap. (techcommunity.microsoft.com)
- What counts: External recipients are counted after expansion. That means distribution lists and expanded recipients (including nested lists) count toward the 100‑recipient cap. (techcommunity.microsoft.com)
- Error behavior: When a tenant hits the MOERA cap for the 24‑hour window, attempts to send to external recipients from onmicrosoft.com addresses will be rejected with a non‑delivery report (NDR) bearing SMTP code 550 5.7.236 until the rolling window moves past the offending sends. (techcommunity.microsoft.com)
- Staged rollout: Microsoft published a staged enforcement timeline keyed to Exchange seat counts. The schedule begins with trial tenants on October 15, 2025, moves to tenants with fewer than 3 paid seats on December 1, 2025, and continues in stages through tenants with more than 10,001 seats, which are slated for enforcement by June 1, 2026. Microsoft will send Message Center notices one month before each stage. (techcommunity.microsoft.com)
Why Microsoft is taking this step
The technical and business rationale is straightforward: shared namespaces used in production are a ripe target for abuse. Trial tenants and freshly created tenants are cheap to obtain and easy to weaponize; attackers create throwaway tenants, send bursts of spam from onmicrosoft.com addresses, then abandon the tenancy before detection and remediation can occur. That abuse drags down the sending reputation of the entire shared onmicrosoft.com domain and increases false positives and drops for legitimate organizations that rely on that namespace. (proofpoint.com, techcommunity.microsoft.com)Beyond simple reputation damage, the vector is operationally noisy for email security teams. Third‑party abuse researchers and security vendors have documented a steady stream of onmicrosoft.com‑based abuse campaigns and tenant relays that escalate quarantine volumes and require manual mitigation — a clear signal that automated sender‑level controls alone were not sufficient. Microsoft’s MOERA policy is an ecosystem measure intended to reduce that noise by discouraging production sending from any shared namespace Microsoft controls. (proofpoint.com, bleepingcomputer.com)
Who is affected — and how badly
- Organizations that already use a verified custom domain for outbound mail (for example, user@company.com) will be largely unaffected, provided they continue sending from that custom domain. The MOERA cap only applies to mail sent from the onmicrosoft.com MOERA addresses. (techcommunity.microsoft.com)
- Organizations that still send system notifications, application alerts, automated messages, or business communications from .onmicrosoft.com addresses will be directly impacted. Any workflow that targets more than 100 external recipients in a rolling day risks immediate rejection and bouncebacks during the throttled period. (techcommunity.microsoft.com)
- Small tenants and trial tenants are the first to be subject to enforcement, but the staged rollout means larger organizations risk enforcement as their window approaches in the specified months. Microsoft’s Message Center notices will warn customers one month in advance for each stage; administrators must monitor those notices closely. (techcommunity.microsoft.com)
- Because external recipient counting occurs after expansion, an ostensibly small send to a distribution list with external members can unintentionally exhaust the 100‑recipient cap. That expansion behavior creates edge cases that will surprise administrators who have not audited list membership and expansion rules. (techcommunity.microsoft.com)
Practical consequences and operational headaches
Shifting off MOERA addresses is not just cosmetic; it touches many moving parts in a modern Microsoft 365 deployment. Administrators should expect the following impacts and plan accordingly:- Primary SMTP address changes — Mailboxes using onmicrosoft.com as their primary SMTP address must be switched to the verified custom domain. Changing a mailbox’s primary SMTP address does not always change the user’s sign‑in username (UPN); best practice is to align UPN and primary SMTP to avoid login confusion, but that can require a coordinated update across devices. Microsoft’s guidance and community experience show that changing SMTP/UPN values can affect OneDrive profiles, cached credentials, and application logins. Plan for user communication and a post‑change support window. (learn.microsoft.com, m365scripts.com)
- Applications and automation — Any scripts, connectors, third‑party services, or in‑app mailers that send from user@company.onmicrosoft.com addresses must be reconfigured to send as the custom domain or routed through a proper transactional email service. Failure to update connectors and SMTP configurations will cause bounced automation and lost messages. (techcommunity.microsoft.com)
- DKIM / SPF / DMARC alignment — To preserve deliverability when moving to a custom domain, admins must configure SPF, DKIM signing, and DMARC policies for the new domain. Microsoft’s guidance recommends gradual DMARC rollout (p=none → p=quarantine → p=reject) and verifying DKIM and SPF for all sending services. Leaving DKIM/SPF/DMARC misconfigured immediately after migration can cause new deliverability problems. (learn.microsoft.com)
- Distribution lists and expansion — Because recipient expansion counts toward the cap, organizations must audit distribution lists, shared mailboxes, and workflow recipients to ensure they don’t inadvertently trigger throttling. In some cases administrators will need to split lists, move external recipients to a marketing platform, or send through a purpose‑built bulk service. (techcommunity.microsoft.com)
- Credential and device churn — If administrators update UserPrincipalName values to match new email addresses, devices and cached credentials may require re‑authentication. OneDrive and Teams rely on UPNs in some scenarios; changing UPNs without planning can produce user friction. Microsoft community documentation and Q&A entries repeatedly emphasize careful sequencing of SMTP, UPN, and AD Connect changes. (learn.microsoft.com, answers.microsoft.com)
What to do now — a practical migration checklist
Below is a prioritized, actionable checklist administrators should use immediately. Treat MOERA migration as a short‑term program: there’s limited time before staged enforcement begins for trials and small tenants.- Inventory:
- Audit all mailboxes, shared mailboxes, service accounts, connectors, applications, and automation that currently use @.onmicrosoft.com* addresses as a sending identity.
- Identify distribution lists and groups containing external recipients and flag lists that might expand beyond 100 external recipients. (techcommunity.microsoft.com)
- Acquire and validate a custom domain:
- Purchase or select a verified domain for production mail (for example, company.com).
- Add the domain in the Microsoft 365 admin center and follow verification steps (publish TXT proof records as required). (learn.microsoft.com)
- Configure DNS and mail authentication:
- Publish SPF records for the custom domain to include Microsoft 365 and any third‑party senders.
- Configure DKIM signing for the custom domain using Microsoft 365 DKIM settings.
- Implement DMARC in a phased manner, starting with p=none, monitoring reports, then gradually tightening to p=reject as appropriate. (learn.microsoft.com)
- Change primary SMTP addresses:
- Update user and mailbox primary SMTP addresses to the new custom domain using the Microsoft 365 admin center or Exchange Online PowerShell (Set‑Mailbox / WindowsEmailAddress patterns).
- Consider updating UPNs to match primary SMTP addresses to minimize login confusion; plan for OneDrive/Teams impacts. Test with a pilot group. (m365scripts.com, learn.microsoft.com)
- Reconfigure applications and connectors:
- Update SMTP connector settings, application sender addresses, and service account credentials to use the custom domain.
- If applications cannot send from custom domains, route them through authenticated connectors or use a transactional email service designed for high‑volume or marketing sends. (techcommunity.microsoft.com)
- Validate and test:
- Send staged test mailings to internal and external test accounts and verify DKIM/SPF/DMARC alignment and deliverability.
- Monitor Message Center for Microsoft notices about your tenant’s rollout window and any additional guidance. (techcommunity.microsoft.com)
- Move large volumes to purpose‑built services:
- For high‑volume transactional or marketing sends, evaluate Azure Communication Services for Email, or third‑party marketing/transactional email platforms. Microsoft’s Exchange limits are not designed for high‑volume transactional mail. (techcommunity.microsoft.com, practical365.com)
Edge cases and tricky scenarios
- Hybrid and federated tenants: If your tenant is federated with on‑premises AD, changing default domains and UPNs may require on‑prem AD changes and an AD Connect reconfiguration. Federated domains have additional constraints when toggling default domain settings. Test carefully and consult federation guidance before large‑scale UPN changes. (answers.microsoft.com)
- Mailboxes whose primary SMTP address flips to onmicrosoft.com unexpectedly: Administrators have observed scenarios where MFA/SSPR updates or other back‑end services can cause the proxyAddresses attribute to be altered, creating unexpected onmicrosoft.com primaries. Audit your identity provisioning flow and locking mechanisms for proxyAddresses to prevent inadvertent reversion. (answers.microsoft.com)
- Distribution lists, nested groups, and dynamic membership: Because expansion counts recipients post‑expansion, a single message to a complex or nested distribution group can consume most or all of the 100‑recipient quota. Splitting lists, using marketing platforms, or switching to targeted segmented sends are practical mitigations. (techcommunity.microsoft.com)
The tradeoffs: strengths and risks of Microsoft’s approach
Microsoft’s MOERA throttling is sensible from a platform stewardship perspective. By discouraging production sending from a shared namespace, it protects deliverability for the vast majority of paying customers who use custom domains. The policy is surgical — a low quota applied only to MOERA addresses — and it dovetails with the broader ERR/MERRL program to curb bulk abuse across Exchange Online. That combination should reduce the number of throwaway tenants used for spam and improve forensic clarity for abuse investigations. (techcommunity.microsoft.com)However, several legitimate risks and operational burdens must be acknowledged:
- Administrative workload: Small organizations and MSPs that provision many trial tenants or who historically used MOERA addresses as a shortcut will face concentrated migration work in a short timeframe. The change may collide with other lifecycle events (for example, OS or application end‑of support) and create resource bottlenecks. (techcommunity.microsoft.com)
- Potential for breakage: Automated systems, third‑party integrations, and legacy workflows that reference onmicrosoft.com addresses are susceptible to immediate disruption if not updated. The requirement to change primary SMTP addresses and possibly UPNs introduces a nontrivial change management project for many tenants. (learn.microsoft.com, m365scripts.com)
- Reputational friction for Microsoft: Some organizations historically used MOERA addresses for legitimate reasons (temporary projects, constrained budgets, etc.). While Microsoft’s goal is to improve platform quality, the policy risks angering small customers who perceive the cap as an unexpected product change with operational consequences. Clear messaging and robust migration tooling will be critical to avoid avoidable support load. (techcommunity.microsoft.com)
- Edge cases around DKIM identity: If organizations sign with the MOERA d= value even when sending from custom domains (a configuration that can occur if custom domains are not configured for DKIM), admins will need to ensure DKIM alignment moves to the custom domain to fully benefit deliverability. Microsoft community threads already indicate confusion around domain signing defaults. Administrators should verify DKIM selectors and signing identity after migration. (techcommunity.microsoft.com, learn.microsoft.com)
Bottom line
Microsoft’s new MOERA throttling is a clear and enforceable nudge: stop relying on shared onmicrosoft.com addresses for production email. The technical goal — reducing abuse of throwaway tenants and protecting the shared namespace reputation — is defensible and long overdue. That said, the change places practical burdens on administrators who must inventory, reconfigure, and test email flows, adjust UPNs and primary SMTP addresses where appropriate, and align DKIM/SPF/DMARC across new domains.Organizations should treat the October–December 2025 window for small tenants as a hard deadline for planning and at least start the migration steps now: acquire and verify a custom domain, configure SPF/DKIM/DMARC, update mailbox primary SMTPs and UPNs in a coordinated way, reconfigure applications and connectors, and move high‑volume sends to dedicated transactional systems. Waiting until the Message Center notice arrives is a risky gamble; by then the operational work will be compressed and user impact more visible.
For administrators, the immediate action is simple: inventory everything that sends from onmicrosoft.com, build a migration plan, and execute early. The platform change will reduce abuse and improve global deliverability — but only if tenants make the switch before their MOERA quota becomes an operational bottleneck. (techcommunity.microsoft.com, learn.microsoft.com)
Source: theregister.com Microsoft puts the squeeze on onmicrosoft.com freeloaders
