Microsoft is pulling the plug on unrestricted outbound email from its shared onmicrosoft.com domains, imposing a hard cap of just 100 external recipients per tenant every 24 hours. The change, announced by the Exchange team, is a direct response to years of spam and phishing campaigns that weaponized the default routing addresses tied to every Microsoft 365 tenant.
Mail sent from any address ending in onmicrosoft.com—or regional variants like onmicrosoft.de—will count toward that rolling limit. Once a tenant hits the quota, any further outbound mail to external recipients bounces with a non-delivery report carrying SMTP error code 550 5.7.236. Internal mail within the tenant is not affected. The restriction does not touch inbound messages or communication between users inside the same organization.
The move targets the very heart of a long-standing abuse vector. Throwaway Microsoft 365 tenants with names like 23gdfs56gsd.onmicrosoft.com have for years been used to pump out high-volume spam and phishing campaigns. Security researchers, including those at Proofpoint, have documented how spammers exploit the ease of tenant creation and the shared reputation of the onmicrosoft.com namespace to slip past filters.
Why an onmicrosoft.com crackdown is long overdue
Every Microsoft 365 tenant comes with a default MOERA (Microsoft Online Email Routing Address) domain—typically yourcompany.onmicrosoft.com. These domains allow immediate connectivity and rapid tenant setup, but far too many organizations left them in place as their primary sending identities. Attackers, aware that the shared namespace enjoys a baseline of trust, began using scripted tenant creation to launch spam bursts and phishing campaigns that often got through.
Proofpoint’s Threat Research team exposed one such campaign in March 2024. The spammer relaid messages through a small number of Proofpoint customers’ email infrastructures by abusing a modifiable configuration that allowed outbound relay from any Microsoft 365 tenant, not just specific, approved ones. The attacker controlled hundreds of oddly named tenants—0h1.onmicrosoft.com, 2cxz1f56s.onmicrosoft.com, x9n9vlm.onmicrosoft.com—and used them to send rapid-fire bursts of spam to recipients at free email providers. Many of those tenants remained active months after the report, underscoring the low barrier to entry for abusers.
“Curbing abuse at the source of message sending is the most effective way to reduce spam,” Proofpoint wrote in its findings. “We encourage email service providers to limit the power of free trial and newly created unverified tenants to send large volume outbound email campaigns.”
Microsoft’s response is surgical. Rather than ban onmicrosoft.com sending entirely, the platform will throttle outbound traffic to 100 external recipients per organization per 24-hour rolling window. The goal is to discourage production use of the shared domain while nudging administrators toward verified custom domains that they control and can authenticate properly with SPF, DKIM, and DMARC.
How the throttle works—hard facts
- Limit: 100 external recipients per tenant per 24 hours, measured on a rolling basis.
- Recipient counting: Counts are applied after distribution-list expansion. Sending one message to a list that expands to 500 external contacts consumes 500 of the 100-recipient quota. There is no de-duplication across repeated sends.
- Failure behavior: Once the cap is breached, new external deliveries from MOERA addresses are rejected with NDR 550 5.7.236. Internal tenant mail and inbound messages are untouched.
- Scope: The limit covers all mail flowing from the onmicrosoft.com namespace. Mail sent from verified custom domains is not subject to this throttle (though it remains subject to other Exchange Online rate limits).
Staged rollout: a 9-wave enforcement plan
Enforcement will roll out by tenant seat count, with Message Center notices one month before each wave. The published schedule is:
- October 15, 2025: Trial tenants
- December 1, 2025: Fewer than 3 seats
- January 7, 2026: 3–10 seats
- February 2, 2026: 11–50 seats
- March 2, 2026: 51–200 seats
- April 1, 2026: 201–2,000 seats
- May 4, 2026: 2,001–10,000 seats
- June 1, 2026: 10,001+ seats
Administrators must treat Message Center notifications as authoritative; dates are subject to operational updates.
Who stands to lose—and who won’t even notice
Enterprises already routing outbound mail through verified custom domains will see little direct impact. Their mail flows continue under existing Exchange Online recipient rate limits, not the MOERA cap. In fact, these organizations may benefit from improved deliverability as the onmicrosoft.com namespace sheds its abuse-laden reputation.
The real pain arrives for tenants that never moved beyond the default domain:
- Small businesses, nonprofits, and trial tenants who use only onmicrosoft.com for external mail will be hit immediately. A single newsletter sent to 101 external subscribers triggers bounces.
- Automated alerts and integrations hard-coded to onmicrosoft.com addresses—monitoring tools, ticketing systems, one-time-passcode senders—risk silent failures once a tenant is throttled.
- Developers and test environments targeting external recipients will be affected early, since trial tenants are the first wave.
Edge cases complicate the picture. The Sender Rewriting Scheme (SRS) may fall back to MOERA addresses if the tenant keeps onmicrosoft.com as the default domain. Booking app invites, Microsoft product notifications, and other platform-generated messages can default to the shared domain unless explicitly reconfigured. Federated tenants, which cannot set a federated domain as the default, must add a non-federated custom domain to avoid SRS-related surprises.
The migration imperative: custom domains and real authentication
Moving to a custom domain is now an operational mandate. The process is straightforward but requires deliberate planning to avoid user confusion and authentication gaps.
Primary SMTP vs. UPN – Changing a mailbox’s primary SMTP address to a custom domain does not automatically update the User Principal Name (UPN) used for sign-in. Misalignment can cause login failures, cached-credential issues, and mismatched profiles in OneDrive and Teams. Plan for reauthentication windows and clear user communication.
DKIM, SPF, and DMARC – A proper migration includes publishing SPF records that include Microsoft 365, enabling DKIM signing for the custom domain, and rolling out DMARC in monitoring mode (p=none) before enforcement. Failing to configure authentication after moving off onmicrosoft.com can trigger deliverability problems as severe as the throttle itself.
Distribution lists – Because the MOERA quota counts recipients after expansion, a single message to a nested list loaded with external contacts can burn through the daily cap. Auditing group membership and dynamic distribution rules is critical before enforcement hits.
Hybrid and connector routing – The policy counts recipients destined to domains outside the tenant’s accepted domain list, regardless of the routing path. Hybrid setups that fall back to MOERA addresses through on-premises relays or connectors may count toward the limit. Administrators should trace representative flows to spot surprises.
High-volume legitimate sends – Exchange Online was never designed for bulk transactional or marketing mail. Tenants with such needs should offload those streams to purpose-built platforms like Azure Communication Services for Email, SendGrid, or Amazon SES. Doing so avoids the MOERA cap and sidesteps broader Exchange Online rate limits.
Practical migration plan: 30/60/90 days
A phased approach reduces operational risk:
0–30 days – Audit & Acquire
- Inventory all senders using onmicrosoft.com: mailboxes, shared mailboxes, connectors, scripts, scheduled tasks.
- Identify high-volume external senders and distribution lists that expand externally.
- Purchase and validate a custom domain; add it to Microsoft 365 and verify ownership.
- Alert stakeholders and monitor Message Center for your enforcement wave.
30–60 days – Pilot & Configure
- Add custom domain aliases to a pilot group.
- Configure SPF, enable DKIM, start DMARC in p=none.
- Update connectors and application SMTP settings.
- Test mail flow and external deliverability.
60–90+ days – Migrate & Monitor
- Change primary SMTP for remaining users (preserve onmicrosoft.com addresses as secondary aliases during cutover).
- Consider aligning UPNs with new primary SMTP addresses; plan for reauthentication and profile impacts.
- Move large-list external sends to an ESP or Azure Communication Services.
- Monitor DMARC reports, Message Trace, and Exchange Admin Center for anomalies.
The broader abuse landscape and Proofpoint’s involvement
The Proofpoint incident illustrates why such throttles are overdue. Spammers exploited a misconfiguration in outbound relay settings to route messages from their Microsoft 365 tenants through legitimate Proofpoint customers’ infrastructure. The attacker rotated through hundreds of randomly named tenants, spoofed sender addresses, and relied on the lack of tenant allow-listing to slip past defenses. Microsoft 365 accepted the spoofed messages and handed them off to the relay, where they were further authenticated with the customer’s DKIM signature, boosting deliverability.
Proofpoint quickly released a streamlined interface that lets customers specify which tenants are permitted to relay, defaulting all others to deny. But the root issue—unrestricted outbound sending from ephemeral onmicrosoft.com tenants—remained a platform-wide weakness. Microsoft’s new cap directly addresses that gap, raising the cost of standing up throwaway tenants for spam and pushing legitimate tenants toward domains they own and can protect.
Actionable priorities for every admin
If your tenant still uses an onmicrosoft.com address for external mail, calendar this as a migration project. The three highest-priority actions are:
- Add and verify a custom domain in the Microsoft 365 Admin Center.
- Configure email authentication—SPF, DKIM, and DMARC—for that domain.
- Update connectors, apps, and service accounts to send from the custom domain or an authenticated relay.
Audit outbound mail flow now using Message Trace. Place a wildcard sender like *@yourtenant.onmicrosoft.com in the Senders filter and exclude internal recipients to see exactly how much mail headed to external contacts. PowerShell can automate this for tenant-wide visibility.
Microsoft’s MOERA throttle is not a surprise attack. It is a measured, staged intervention that targets an abuse vector while giving everyone a path to compliance. The 100-recipient daily cap is low enough to neuter bulk spam but high enough to allow limited testing. The real win for organizations that migrate is permanent—a branded sending identity, full authentication control, and a deliverability profile they own. The time to start that work is now, well before the enforcement wave reaches your seat count.