Microsoft will soon enforce a hard limit on external email sent from the shared onmicrosoft.com namespace, capping it at just 100 external recipients per tenant per day. The policy, dubbed MOERA (Microsoft Online Email Routing Address) throttling, aims to curb the rampant spam and abuse that has plagued the platform for years, as threat actors exploit throwaway Microsoft 365 tenants to blast junk mail through legitimate infrastructure. Admins who fail to migrate to a verified custom domain before their enforcement window could see critical email bounce with a 550 5.7.236 NDR — and the clock is ticking.

The change, announced via the Microsoft 365 Message Center and detailed in a Microsoft Tech Community post, is not a gentle suggestion. It is a staged, non-negotiable rollout that will bite hard and fast, starting with trial tenants on October 15, 2025, and progressing through larger organizations by June 2026. The immediate message for IT teams: inventory every script, connector, and mailbox still using an @company.onmicrosoft.com address, and move to a custom domain now. Delay means deliverability disaster.

Why the Shared onmicrosoft.com Domain Became a Spam Magnet

To understand Microsoft’s drastic action, one need look no further than the forensic evidence compiled by security vendor Proofpoint. In a detailed threat advisory released in mid-2024, Proofpoint researchers documented massive spam campaigns in which attackers created hundreds of Microsoft 365 tenants with nonsensical onmicrosoft.com names — think 23gdfs56gsd.onmicrosoft.com or x0j93o6.onmicrosoft.com — then relayed spoofed spam through legitimate enterprise email infrastructure. The root cause: a modifiable relay configuration on Proofpoint servers (and similar gateway products) that, by default, allowed outbound mail from any Microsoft 365 tenant, not just the customer’s own.

Attackers exploited this to send high-velocity bursts of spam, often spoofing the RFC822 “from” header while the envelope sender (RFC821) came from the throwaway tenant. When the spoofed domain matched a legitimate Proofpoint customer’s domain, DKIM signing would even be applied in transit, making the messages appear more trustworthy. The campaigns targeted free email providers like Gmail, Yahoo, and GMX, and Proofpoint’s list of indicators of compromise includes over 600 such abusive onmicrosoft.com tenants.

This abuse vector was not unique to Proofpoint. The email relay configuration is a common feature across email security gateways, and other vendors have likely faced similar attacks. Microsoft itself has long struggled with bad actors spinning up trial tenants, using them for spam, and discarding them before automated systems can react. The result: the shared reputation of the onmicrosoft.com namespace has been dragged through the mud, causing legitimate mail from well-meaning organizations that still rely on it to be delayed, quarantined, or dropped outright.

The Hard Facts: What the MOERA Throttle Does

The MOERA throttle is a surgical control that applies only to outbound mail sent with an onmicrosoft.com domain in the From: or envelope sender. Here are the specifics, directly from Microsoft’s Tech Community blog and corroborated by the forum discussion:

  • Recipient Cap: 100 external recipients per organization per 24-hour rolling window. Internal-only messages (within the tenant) are not counted.
  • Post-Expansion Counting: External recipients include members of distribution lists, shared mailboxes, and nested groups after they are expanded. A single message to a list with 150 external members will instantly blow the cap.
  • Error Behavior: When the cap is exceeded, further attempts to send external mail from MOERA addresses are rejected with an NDR bearing SMTP code 550 5.7.236. The cap resets as the rolling window advances.
  • Staged Rollout: Microsoft has published a precise timeline:
  • October 15, 2025: Trial tenants
  • December 1, 2025: Tenants with fewer than 3 paid Exchange seats
  • Subsequent stages, at roughly one-month intervals, for larger tenants, concluding with those having 10,001+ seats by June 1, 2026.
  • Microsoft will send a Message Center notice one month prior to each stage.

This throttle is separate from the broader External Recipient Rate (ERR) limits Microsoft has been rolling out, which cap bulk external sending per mailbox or tenant. The MOERA cap is additive and targeted specifically at the shared namespace. Internal mail, mail destined for on-premises recipients via hybrid connectors, and mail from custom domains remain unaffected — provided you have switched your primary SMTP address.

Who Is Most Affected — and How to Tell if You’re at Risk

If every user in your tenant already sends with a verified custom domain (e.g., [email protected]), and you never use [email protected] for outbound communication, you can breathe easy. The cap will not apply to those messages. However, many organizations have lingered for years on MOERA addresses out of convenience, inertia, or lack of a custom domain. The following scenarios are particularly vulnerable:

  1. Automated Application Mail: Internal apps, line-of-business systems, and cloud services often default to using the tenant’s .onmicrosoft.com address for notifications, password resets, and reports. If those apps blast thousands of external alerts daily, they will hit the 100-recipient ceiling almost immediately.
  2. Small and New Tenants: Startups, schools, and nonprofits that signed up for Microsoft 365 and never added a custom domain will be among the first affected, with enforcement starting as early as October 2025 for trials and December 2025 for very small paid tenants.
  3. Distribution Groups with External Members: A large external distribution list, perhaps used for partner communications or customer newsletters, can consume the entire quota with a single send. Because expansion occurs server-side, admins may not realize how many external addresses they truly reach until the NDRs start piling up.
  4. Hybrid Environments: Organizations with on-premises Exchange servers that use the .onmicrosoft.com domain as the primary SMTP address for synced mailboxes face additional complexity. Changing primary SMTP addresses in a hybrid setup may require altering AD Connect synchronization rules and updating on-premises mail routing.

A Practical Migration Checklist

The community discussion and Microsoft’s own guidance emphasize that switching to a custom domain is not a flip of a switch. It touches mailboxes, DNS, authentication, applications, and user experience. Here is a prioritized, step-by-step checklist to tackle before your enforcement deadline:

1. Inventory Everything That Uses MOERA

  • Run Exchange Online PowerShell to list all mailboxes where the primary SMTP address ends in onmicrosoft.com:
    powershell Get-Mailbox -ResultSize Unlimited | Where-Object {$_.PrimarySmtpAddress -like '*onmicrosoft.com*'}
  • Audit connectors, applications, multifunction devices, and cloud services (like CRMs, HR platforms, and monitoring tools) that send mail through your tenant. Check SMTP logs for onmicrosoft.com sender addresses.
  • Identify all distribution lists, dynamic groups, and shared mailboxes that contain external members, and estimate their expansion size.

2. Acquire and Verify a Custom Domain

  • Purchase or designate a domain you already own (e.g., company.com). Add it in the Microsoft 365 admin center under Settings > Domains.
  • Complete DNS verification by adding the TXT record provided. This can take a few minutes to a few hours to propagate.

3. Configure Email Authentication (SPF, DKIM, DMARC)

  • SPF: Publish a DNS TXT record that includes Microsoft 365 (include:spf.protection.outlook.com) and any other legitimate senders (e.g., your marketing platform, on-premises servers).
  • DKIM: In the Exchange admin center, enable DKIM signing for your custom domain. Microsoft will generate two CNAME records you must publish in DNS. Rotate any existing default signing for the onmicrosoft.com domain.
  • DMARC: Start with a policy of p=none to monitor, then gradually move to p=quarantine and finally p=reject as you confirm legitimate mail is aligned. Microsoft recommends publishing a DMARC record early and using aggregate reports to spot misuse.

4. Change Mailbox Primary SMTP Addresses (and Possibly UPNs)

  • Update the primary SMTP address for each user, shared mailbox, and room mailbox to the custom domain.
  • Via admin center: Edit each user’s email aliases and set the custom domain as primary.
  • Via PowerShell: Set-Mailbox -Identity user@olddomain -WindowsEmailAddress [email protected]
  • Consider aligning UserPrincipalName (UPN) with the new primary SMTP address to avoid sign-in confusion. However, changing UPNs can cause OneDrive resets, cached credential issues, and Microsoft Teams re-authentication prompts. Perform this step in a pilot group with clear communication.

5. Reconfigure Applications and Connectors

  • Update SMTP relay connectors (Exchange admin center > Mail flow > Connectors) to expect mail from the new domain.
  • For apps that use SMTP AUTH: change the sending address and, if necessary, the credentials. If the app cannot be reconfigured, route its traffic through a high-volume email service like Azure Communication Services or SendGrid.
  • Test each integration thoroughly after changes.

6. Handle Distribution Lists and Bulk Sends

  • For large external distribution lists, consider moving them to a dedicated bulk mailing platform. Microsoft Exchange Online is not designed for high-volume marketing email, and the broader ERR limits will also apply.
  • Split lists if possible, but remember that the 100-recipient cap is tenant-wide and rolling. No amount of splitting within the MOERA namespace will circumvent it.

7. Monitor Message Center and Test Extensively

  • Watch for the specific Message Center post announcing your tenant’s enforcement date. Do not assume you have until the final stage; small tenants get hit first.
  • Prior to go-live, send test emails to internal and external accounts, examine headers, and verify DMARC alignment. Use tools like MXToolbox or the Microsoft Remote Connectivity Analyzer to confirm SPF, DKIM, and DMARC pass.

Edge Cases That Could Derail a Migration

Even well-planned migrations can hit snags. The forum surface several pain points:

  • Unintended MOERA Reversion: Some admins have observed that processes like self-service password reset or MFA updates can overwrite the proxyAddresses attribute, flipping a user’s primary SMTP back to onmicrosoft.com. Tighten attribute flow in Azure AD Connect and consider setting immutable ID values.
  • Federated Domains: If your tenant uses federation with an on-premises Active Directory, changing the default domain may require reconfiguration of AD FS or other identity providers. UPN changes in particular can disrupt sign-in for federated users.
  • Hybrid Mail Flow: In hybrid Exchange deployments, mailboxes synced from on-premises typically have their primary SMTP address set there. Changing it requires updating on-premises user attributes and ensuring that the hybrid send connector routes correctly for the new domain.
  • DKIM Selector Confusion: Even after switching, some tenants inadvertently continue to sign with the onmicrosoft.com DKIM selector, because the custom domain’s DKIM was never properly configured. Double-check that your outbound mail shows d=customdomain.com in the DKIM signature header.

The Big Picture: Why This Is Good for the Ecosystem — With Notable Pain

Microsoft’s MOERA throttling is an overdue but necessary course correction. By turning the shared onmicrosoft.com domain into a low-reputation, low-volume namespace, it disincentivizes the exact abuse documented by Proofpoint and others. Legitimate senders who have already invested in proper domain authentication will see improved deliverability because spammers will no longer be able to piggyback on the platform’s default domain.

For the industry, it’s a model for how email service providers can combat tenant-based abuse without resorting to broad, customer-impacting restrictions. The staged rollout gives conscientious admins time to act, and the policy is narrowly targeted.

Yet, the administrative burden is real. Smaller organizations, managed service providers, and educational institutions that relied on onmicrosoft.com for expedience now face a scramble. Microsoft has not provided an automated migration tool, leaving admins to manually update mailboxes, DNS, and applications. The alignment of this change with other major IT initiatives (like Windows 11 migrations or the looming end of Exchange on-premises) could strain resources.

Moreover, the policy may inadvertently legitimize the use of onmicrosoft.com for internal-only mail, encouraging sloppy practices. But the overriding message is clear: the shared namespace is no longer acceptable for production email. The era of something.onmicrosoft.com as a primary sending identity is over.

Act Now — The First Deadline Is Closer Than It Appears

With the first enforcement date for trial tenants set for October 15, 2025, there is no room for procrastination. Even if your tenant falls into a later bucket, the migration effort requires lead time for testing, user communication, and troubleshooting. Start your inventory today. Verify a custom domain this week. Begin piloting changes for a small group of users.

The Proofpoint exposé of hundreds of spam tenants — with names like dgfvcbxcgzcbfchfcvbcbcxfnb.onmicrosoft.com — should serve as a stark reminder of why Microsoft is doing this. Those tenants are still active as of mid-2024, and new ones appear daily. Until the throttle is universally enforced, the spam will continue.

For the conscientious admin, the path forward is clear: embrace a verified custom domain, lock down your authentication, and wave goodbye to the onmicrosoft.com crutch. The alternative — a flood of NDRs and grumpy stakeholders — is not a viable option.