MOERA Throttle: 100 External Recipients per 24h and Migration to Custom Domains

Microsoft’s Exchange team has announced a sweeping, tenant-level restriction that will limit outbound email sent from the shared onmicrosoft.com namespace (MOERA — Microsoft Online Email Routing Address) to 100 external recipients per organization per 24‑hour rolling window, and the change comes with a staged rollout that begins with trial tenants in October 2025 and progresses to the largest tenants by June 1, 2026. (techcommunity.microsoft.com)

Background / Overview​

Every Microsoft 365 tenant is provisioned with a default domain that looks like yourcompany.onmicrosoft.com (or a regional variant such as onmicrosoft.de). These MOERA domains exist to enable immediate connectivity and rapid tenant setup, and they are useful for testing and early-stage configuration. Over time, however, many organizations left MOERA addresses in place as operational sending identities, and attackers repeatedly exploited newly created tenants and the shared namespace to send burst spam and phishing campaigns. The collective result is a degraded reputation for the onmicrosoft.com namespace and measurable impact on deliverability for legitimate tenants that still send from those addresses. (techcommunity.microsoft.com) (proofpoint.com)
Microsoft’s response is surgical: rather than imposing a blanket tenant-level ban, the platform will throttle MOERA-originated outbound traffic to discourage production use while leaving inbound and internal tenant traffic unaffected. This move is explicitly designed to nudge administrators toward adding and using verified custom domains for production email — allowing tenants to own their sending reputation and implement proper authentication (SPF/DKIM/DMARC). (techcommunity.microsoft.com)

---

What Microsoft is changing — hard facts​

The throttle​

• Limit: Mail sent from any address in the .onmicrosoft.com namespace will be limited to 100 external recipients per organization per 24‑hour rolling window. Internal traffic remains unaffected. (techcommunity.microsoft.com)

How recipients are counted​

• Expansion counts: Recipient counting occurs after distribution-list expansion. Sending one message to a list that expands to 500 external recipients consumes 500 of the 100‑recipient quota. Repeated sends are counted per message (no de‑duplication across sends). (techcommunity.microsoft.com)

Failure behavior​

• When the 100‑recipient cap is exceeded, outbound delivery to external recipients from MOERA addresses will be rejected, and senders will receive NDRs (bounce messages) with the SMTP error 550 5.7.236 while the tenant remains throttled. Inbound messages and internal tenant mail are not throttled. (techcommunity.microsoft.com)

Staged rollout​

Enforcement is staged by Exchange seat counts. Microsoft will publish Message Center notices one month before each wave; tenants should treat Message Center as the authoritative notification mechanism. The published schedule (subject to Microsoft’s operational updates) is:

• October 15, 2025 — Trial tenants
• December 1, 2025 — < 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. (techcommunity.microsoft.com)

---

Why Microsoft is acting now​

The change addresses a long‑standing anti‑abuse problem: the shared onmicrosoft.com namespace is cheap for attackers to weaponize. Security researchers and vendors have documented campaigns that use throwaway tenants and default domains to send high‑volume spam before detection and remediation can occur. The collateral damage is real — legitimate tenants that still send from MOERA addresses suffer degraded delivery and can be blocked by downstream recipients. Independent security analysis and incident reports have shown examples of such abuse and relay exploitation across the ecosystem. The throttle raises the operational cost of using new tenants for spam, while encouraging tenants to adopt verified, brandable domains they control. (proofpoint.com, office365itpros.com)

---

Who is affected — practical impact​

The policy is narrowly scoped (MOERA addresses only), but the operational surface area is broad:

• Beneficiaries
• Enterprises and organizations that already send from a verified, custom domain should see little or no direct impact to day-to-day production mail flows, provided they continue using those custom domains. Moving to a custom domain also enables proper DKIM, SPF, and DMARC alignment — improving long‑term deliverability. (techcommunity.microsoft.com)
• At‑risk groups
• Small businesses, nonprofits, hobby projects and trial tenants that never set up a custom domain and use only onmicrosoft.com for external mail will be directly affected. A single distribution send can rapidly exhaust 100 external recipients and trigger bounces.
• Automations and third‑party integrations hard‑coded to use onmicrosoft.com (monitoring alerts, ticketing systems, OTP senders, service accounts) risk silent failures once the tenant is throttled.
• Developers and test environments that target external recipients for verification or testing will be limited early in the rollout (trial tenants are the first wave). (techcommunity.microsoft.com, windowsforum.com)
• Edge cases that require attention
• Sender Rewriting Scheme (SRS) fallbacks: If a tenant keeps MOERA as the default domain, SRS may use MOERA addresses as fallback and cause unexpected external sends.
• Bookings app invites, Microsoft product notifications, and other platform-generated messages can default to MOERA domains unless configured otherwise.
• Federated domains: Federated domains cannot be set as the tenant default — customers using federation must add a non‑federated custom domain to act as the default. (techcommunity.microsoft.com)

---

Technical implications and operational gotchas​

Primary SMTP vs. UPN​

Changing a mailbox’s primary SMTP address to a custom domain is straightforward but not inconsequential. Primary SMTP is the address used for outbound mail; the User Principal Name (UPN) used for sign-in may or may not be changed automatically. Misalignment between UPN and primary SMTP can cause login confusion, cached‑credential issues on devices, OneDrive/Teams profile mismatches, and credential resets across apps. Plan reauthentication windows and user communications. (techcommunity.microsoft.com)

DKIM/SPF/DMARC alignment​

To preserve deliverability when moving to a custom domain, administrators must:

• Publish SPF records that include Microsoft 365 and any other sending services.
• Enable DKIM for the custom domain (Microsoft 365 supports DKIM signing for verified domains).
• Implement DMARC in a phased rollout (start p=none → monitor → enforce).
  Failing to configure authentication properly after migration can produce new deliverability issues. (techcommunity.microsoft.com, office365itpros.com)

Distribution lists and unexpected expansion​

Because the MOERA quota counts recipients after expansion, a single message to a nested distribution list or to an alias that contains external recipients can consume most or all of the 100‑recipient cap. Administrators must audit group membership and dynamic distribution rules to avoid surprise throttling. (techcommunity.microsoft.com)

Hybrid and connector routing behavior​

Hybrid setups and custom relay configurations can create confusing counting behavior. The policy counts recipients destined to external domains (not in your tenant’s accepted domain list) regardless of routing path. If on‑prem relays or connectors involve fallback to MOERA addresses, those flows may be counted. Test message traces for representative hybrid flows. (techcommunity.microsoft.com)

Journaling and Microsoft Exchange Recipient messages​

Journaling reports and messages generated by the Microsoft Exchange Recipient address (MicrosoftExchangeRecipientPrimarySmtpAddress) are not counted toward the MOERA throttle because the address is a system setting that tenants cannot alter. Administrators should be aware of which platform-generated messages are excluded. (techcommunity.microsoft.com)

High‑volume legitimate sending​

If you have legitimate high‑volume transactional or marketing sends, Exchange Online is not the right channel. Move those flows to purpose‑built platforms such as Azure Communication Services for Email or a dedicated email service provider (SendGrid, Amazon SES, SparkPost, etc.). Doing so avoids Exchange rate limits and provides reputation and deliverability tooling. (techcommunity.microsoft.com, office365itpros.com)

---

How to analyze your MOERA traffic and discover risk​

Microsoft provides Message Trace in the Exchange Admin Center to retrieve outbound traffic. A common technique is to place a wildcard sender (e.g., *@yourtenant.onmicrosoft.com) in the Senders filter to capture messages sent from MOERA addresses, then filter results by recipient domain to exclude internal traffic. PowerShell can automate and extend this analysis for tenant-wide audits. Administrators should inventory:

• Mailboxes and shared mailboxes with onmicrosoft.com as primary SMTP.
• Service accounts, connectors, and apps that send as onmicrosoft.com.
• Distribution groups with external members or dynamic membership that expands externally. (techcommunity.microsoft.com)

Practical community guidance and scripts exist to enumerate proxyAddresses and mail-flow connectors; use those tools to build an accurate inventory before making changes. (windowsforum.com)

---

A practical 30/60/90‑day migration plan​

The following phased plan reduces operational risk and helps avoid surprises when Microsoft enables enforcement for your tenant’s seat tier.
0–30 days — Audit & Acquire

• Inventory all senders using onmicrosoft.com (mailboxes, shared mailboxes, connectors, applications, scheduled tasks).
• Identify high‑volume external senders and distribution lists that expand externally.
• Purchase and validate a custom domain with your registrar; add it to Microsoft 365 and verify ownership in the Admin Center.
• Communicate the plan and schedule to stakeholders, and monitor Message Center for your tenant’s enforcement notification. (techcommunity.microsoft.com)

30–60 days — Pilot & Configure

• Add new custom domain aliases to a pilot group of users and service accounts.
• Configure SPF, enable DKIM for the new domain, and start DMARC in p=none to collect reports.
• Update connectors and application SMTP settings to use the custom domain or authenticated relays.
• Test mail flow and conduct external deliverability checks with representative recipients. (techcommunity.microsoft.com)

60–90+ days — Migrate & Monitor

• Change primary SMTP addresses for remaining users (preserve onmicrosoft.com addresses as secondary aliases during cutover where practical).
• Consider aligning UPNs with the new primary SMTP addresses to reduce user confusion — plan for credential re-authentication and OneDrive/Teams profile impacts.
• Split or move large-list external recipients to an ESP or Azure Communication Services for Email.
• Monitor DMARC aggregate reports, Message Trace, and the Exchange Admin Center for anomalies. (techcommunity.microsoft.com)

---

Example checklist for developers and applications​

• Update hard‑coded email addresses in code, scripts, and third‑party integrations that use onmicrosoft.com.
• Reconfigure monitoring alerts, ticketing systems, and transactional email from service accounts to use a custom domain or authenticated connector.
• Where reconfiguration is impossible, route application sends through an authenticated SMTP connector or a dedicated ESP.
• Verify DKIM signing identity and selectors after migration to ensure the d= value aligns with the custom domain. Misaligned DKIM (signing with d=onmicrosoft.com while sending from a custom domain) can still cause deliverability problems. (techcommunity.microsoft.com)

---

Relation to other Exchange limits (context)​

Microsoft has been rolling out a family of recipient‑rate controls for Exchange Online, including a mailbox‑level External Recipient Rate Limit (ERR / MERRL) that targets 2,000 external recipients per mailbox over 24 hours for certain deployment waves. The MOERA throttle is distinct and much lower (100 external recipients per tenant per day), but it applies only to the shared onmicrosoft.com namespace. If you already send from a custom domain, you will still be governed by the broader ERR/MERRL rules rather than the MOERA cap. Administrators should review both sets of limits as part of their migration planning. (techcommunity.microsoft.com)

---

Strengths, weaknesses, and risk assessment​

Strengths​

• Targets the core abuse vector — directly raises the cost for throwaway tenant abuse and improves the shared namespace hygiene.
• Encourages best practice — nudges customers to use brand‑owned domains, which enables proper authentication and control over reputation.
• Surgical scope — the throttle is specific to MOERA addresses, minimizing impact on tenants that already use custom domains. (techcommunity.microsoft.com)

Weaknesses & risks​

• Collateral disruption risk — legitimate small tenants, nonprofits, and trials that never set a custom domain may experience sudden external mail failures.
• Migration complexity — changing primary SMTP addresses, aligning UPNs, and reconfiguring a patchwork of applications and connectors can be time‑consuming and prone to oversight.
• Edge‑case unpredictability — expansion counting, hybrid routing, and legacy connector behavior can produce surprising quota consumption unless administrators audit thoroughly. (windowsforum.com)

Operational mitigation​

• Proactively audit and remediate. The most important single action is to add and validate a custom domain and migrate external sending to that domain. Preserve legacy MOERA aliases as secondary addresses during cutover to minimize authentication fallout. Use staged pilot migrations and maintain robust rollback procedures. (techcommunity.microsoft.com)

---

Practical Q&A — quick answers to common administrator concerns​

• Will internal email continue to work?
  Yes — the MOERA cap only applies to external recipients; internal tenant mail is not counted. (techcommunity.microsoft.com)
• What NDR will senders see if throttled?
  Senders will receive a non‑delivery report with SMTP error code 550 5.7.236 for attempts to send to external recipients from MOERA addresses while the tenant is throttled. (techcommunity.microsoft.com)
• How are distribution lists and nested groups counted?
  Recipient counts are calculated after expansion; if a list expands to external recipients, every expanded external recipient counts toward the quota. Audit distribution-group membership carefully. (techcommunity.microsoft.com)
• What about federated tenants?
  Federated domains cannot be set as the default domain; federated customers must add a non‑federated custom domain to act as the tenant default to avoid SRS fallback and other MOERA-related issues. (techcommunity.microsoft.com)

---

Final assessment and recommended next steps​

Microsoft’s MOERA throttling is a pragmatic and narrowly targeted intervention designed to reduce a measurable anti‑abuse problem and improve deliverability for the broader customer base. The policy is consistent with an industry best practice: use a verified, brandable domain for production outbound email. The 100‑recipient cap is low enough to deter abuse but high enough to permit limited testing from MOERA addresses.
Every tenant that still uses an onmicrosoft.com identity for external messaging should treat this announcement as an operational mandate and calendar it as a migration project with the following immediate actions:

• Inventory all senders that use onmicrosoft.com.
• Purchase and validate at least one custom domain in Microsoft 365.
• Configure SPF, DKIM, and DMARC for the custom domain and pilot the migration.
• Reconfigure connectors, apps, and automations to send from the custom domain or an authenticated relay/API platform.
• Monitor Message Center for your tenant’s enforcement notification and test thoroughly before your enforcement window begins. (techcommunity.microsoft.com, windowsforum.com)

Caveat: Microsoft’s published schedule is the plan today, and Microsoft will post Message Center notices one month before enforcement for each tenant group. Administrators should treat those Message Center messages as authoritative and be prepared for operational updates if Microsoft adjusts dates or telemetry. (techcommunity.microsoft.com)
The practical truth for administrators: acquiring and configuring a custom domain is inexpensive and straightforward, and the work required to migrate properly will pay dividends in deliverability, brand trust, and operational control. Tenants that delay migration risk unexpected bounces and interruptions — especially those using distribution lists or automations that reach external recipients. Start the inventory now, run a pilot, and move production sending off MOERA well before your tenant’s enforcement window. (techcommunity.microsoft.com, office365itpros.com)

---

Microsoft’s messaging team framed this change as a nudge toward platform health and better customer outcomes; for administrators, it is a measurable operational priority with a clear mitigation path. The time to act is now.

---

Source: Microsoft Exchange Team Blog Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub

 

[ChatGPT]

Microsoft is imposing a hard cap on outbound email sent from the shared onmicrosoft.com tenant namespace: mail from MOERA (Microsoft Online Email Routing Address) domains will be throttled to 100 external recipients per organization in any 24‑hour rolling window, with attempts beyond that returning an NDR carrying SMTP code 550 5.7.236; the change is being rolled out in staged waves keyed to Exchange seat counts beginning with trial tenants on October 15, 2025 and completing for the largest tenants on June 1, 2026. (techcommunity.microsoft.com)

Background​

Microsoft 365 automatically provisions a default tenant domain when a new tenant is created — the familiar companyname.onmicrosoft.com (and regional variations such as .onmicrosoft.de). That namespace was designed for rapid provisioning and testing, allowing administrators to create users and validate mail flow without buying and verifying a custom domain. Over time, however, many tenants kept using their MOERA address as a production sending identity. Because the onmicrosoft.com namespace is shared across millions of tenants, abuse from throwaway or trial tenants has steadily degraded the global reputation of that space and created deliverability problems for legitimate customers. (techcommunity.microsoft.com)
Microsoft’s announcement formalizes a change in policy: MOERA domains should be retained for testing only. To enforce that expectation, Microsoft will throttle external sending from onmicrosoft.com addresses to a small, tenant‑level quota (100 external recipients per 24 hours), leaving inbound mail and internal tenant mail flows unaffected. This change sits alongside broader Exchange Online outbound controls such as the External Recipient Rate Limit (ERR / MERRL) and tenant outbound quotas — but it is distinct and purposely surgical: it targets only the shared MOERA namespace.

---

What Microsoft announced — the technical specifics​

The hard limits, counting rules and failure mode​

• Throttle: Mail sent from any address in the onmicrosoft.com namespace will be limited to 100 external recipients per organization per 24‑hour rolling window. Internal deliveries (recipients within the same tenant) are not counted against the cap. (techcommunity.microsoft.com)
• Counting behavior: External recipients are counted after recipient expansion. That means distribution list expansion, nested groups, or any automatic expansion that produces more external recipients will consume the quota equal to the expanded recipient total. A single send to a list that expands to 300 external addresses will use 300 of the 100‑recipient daily budget.
• Error code and visibility: When a tenant exceeds the MOERA quota, further attempts to send to external recipients from onmicrosoft.com addresses will be rejected with a non‑delivery report bearing SMTP error code 550 5.7.236 until the rolling 24‑hour window falls below the threshold. Administrators and senders will see NDRs for the failed messages.

Rollout schedule (enforcement windows by seat count)​

Microsoft will enable enforcement in stages based on the number of Exchange seats in a tenant. The published schedule in the announcement is:

• Trial tenants: enforcement begins October 15, 2025.
• Tenants with fewer than 3 seats: enforcement begins December 1, 2025.
• Tenants with 3–10 seats: enforcement begins January 7, 2026.
• Tenants with 11–50 seats: enforcement begins February 2, 2026.
• Tenants with 51–200 seats: enforcement begins March 2, 2026.
• Tenants with 201–2,000 seats: enforcement begins April 1, 2026.
• Tenants with 2,001–10,000 seats: enforcement begins May 4, 2026.
• Tenants with more than 10,001 seats: enforcement begins June 1, 2026.

Microsoft will notify tenants one month before enforcement for their seat bracket using Message Center announcements; administrators are instructed to monitor Message Center carefully for tenant‑specific notices.

---

Why Microsoft is doing this — the anti‑abuse and deliverability case​

Shared namespaces are a classic abuse vector. Attackers and opportunists routinely create trial tenants, use the out‑of‑the‑box onmicrosoft.com address to send spam or phishing bursts, and then abandon the tenancy. Because new tenants often inherit a relatively “clean” sending reputation and Microsoft’s infrastructure is broadly trusted, that abuse can achieve wide inbox placement before detection. Repeated misuse degrades the reputation of the entire onmicrosoft.com namespace and causes collateral deliverability problems for thousands or millions of legitimate tenants still sending from MOERA identities.
Putting a low, explicit cap on MOERA outbound external recipients increases the operational cost of using throwaway tenants for large‑scale abuse. It also creates a clear operational incentive for customers to migrate production sending to verified, company‑owned custom domains, where administrators can control SPF, DKIM, DMARC and reputation. In short: the throttle is both a targeted anti‑abuse control and a nudge toward email best practices that improve deliverability for all. (techcommunity.microsoft.com)

---

Who is affected — immediate and edge‑case impacts​

Likely unaffected groups​

• Organizations that already send production email exclusively from a verified custom domain and have properly configured SPF/DKIM/DMARC will not see their production traffic affected, provided their outbound mail originates from those custom domains rather than onmicrosoft.com addresses.

At‑risk groups and scenarios​

• Small businesses, non‑profits, hobby projects and trial tenants that never set up a custom domain and use onmicrosoft.com addresses for day‑to‑day communication will be directly impacted when they exceed 100 external recipients in a rolling 24‑hour window.
• Automation, monitoring and SaaS integrations: Many apps and scripts are hard‑coded to send from service accounts like service@tenant.onmicrosoft.com. Those flows (alerts, ticket system emails, build notifications) will fail if they target more than 100 external recipients per day, possibly silently if administrators miss the NDRs.
• Distribution lists and recipient expansion: Because counting occurs after expansion, a seemingly small send to a distribution list that includes external members can exhaust the quota instantly. Admins must audit group membership and expansion behavior.
• Hybrid and complex routing: Hybrid setups, connectors, or on‑prem relays that ultimately deliver externally may still cause MOERA addresses to be counted if the original sender address is in the onmicrosoft.com namespace. Administrators of hybrid environments should test and verify how connectors and routing affect MOERA counting.

Special cases Microsoft calls out​

• Sender Rewriting Scheme (SRS) can fall back to MOERA domains if the default domain remains an onmicrosoft.com address; tenants must set a custom default domain to avoid SRS using MOERA.
• Microsoft Bookings and other Microsoft services might default to MOERA addresses; those products need to be configured to use a custom domain to avoid hitting the limit.
• Federated domains cannot be used as the tenant default domain; tenants that rely on federated UPNs must add a non‑federated custom domain to act as the default for outbound sending.
• Journaling reports that originate from MicrosoftExchangeRecipientPrimarySmtpAddress are not modifiable by admins and will not count against the MOERA throttle.

---

Strengths and potential risks — critical analysis​

Strengths​

• Surgical, evidence‑based control: The policy targets the specific attack surface (shared MOERA namespace) rather than broadly restricting tenant or mailbox behavior, reducing the chance of unnecessary disruption to organizations that already follow best practices. (techcommunity.microsoft.com)
• Improves ecosystem deliverability: Encouraging migration to custom domains improves SPF/DKIM/DMARC alignment and brand trust — outcomes that generally improve inbox placement and reduce false positives.
• Operational deterrence to abuse: The cost/benefit for attackers using throwaway tenants becomes less attractive when large bursts of external email are capped at a very low quota.

Risks and potential downsides​

• Collateral damage to legitimate users: Organizations that have not audited their tenant and rely on MOERA addresses for automation or external notification could face immediate operational impacts, with automated messages failing and business processes disrupted.
• Migration complexity: Changing primary SMTP addresses and aligning UPNs has real operational friction: device re‑authentication, cached credentials, OneDrive profile issues, SSO/ADFS integration quirks, and application updates may be required. That work can be time‑consuming and error‑prone for larger tenants.
• Silent failures and monitoring gaps: If administrators do not monitor Message Center, Exchange Admin Center reports, or NDRs, tenants can be surprised by blocked sends. Microsoft’s staged notifications help, but they rely on tenants actually reading Message Center messages.
• Edge‑case counting surprises: Recipient expansion, hybrid routing, and SRS fallbacks produce non‑intuitive counts; organizations need to model and test flows to ensure they don’t accidentally exceed the cap.

---

A practical migration and mitigation plan (30/60/90 days)​

The work is predictable; the challenge is executing it across people, apps and automation. The following is a pragmatic, prioritized plan suitable for most tenants.

0–30 days: immediate triage and planning​

• Audit all senders using onmicrosoft.com: Use Exchange Admin Center message trace and the EAC mail flow reports to find mailboxes, shared mailboxes, service accounts, connectors, and apps using MOERA addresses. Query for wildcards like @.onmicrosoft.com to identify all outbound traffic originating from the namespace.
• Identify high‑risk flows: Flag any sender or automated process that targets external recipients at scale (alerts, newsletters, ticket emails). Prioritize remediation for flows that approach or exceed 100 external recipients/day.
• Purchase and validate a custom domain: If the organization doesn’t already own a custom domain, buy one from a registrar and add it to Microsoft 365 (Entra) as an accepted domain. Validate ownership via DNS so you can start using it for mail.
• Communicate change: Notify stakeholders, especially teams that manage automation, helpdesk, DevOps and third‑party integrations.

30–60 days: pilot and test​

• Pilot migration: Move a representative pilot group of users and a sample of automation to the custom domain. Make the new alias a primary SMTP address for the pilot mailboxes.
• Publish SPF/DKIM and start DMARC in p=none: Configure outbound authentication for the new domain. Start DMARC in monitoring mode to detect alignment issues before moving to enforcement.
• Reconfigure connectors and apps: Update SMTP connectors, scripts, third‑party services and SaaS vendors to send from the custom domain or route through an authenticated relay or a transactional email service.
• Validate SRS and Bookings: Ensure SRS fallback and Bookings instances are configured to use your verified domain rather than MOERA addresses.

60–90+ days: execute and monitor​

• Complete primary SMTP/UPN changes: Move remaining mailboxes’ primary SMTP addresses to the custom domain; where practical, align UserPrincipalName (UPN) with the primary SMTP to reduce login confusion.
• Retain onmicrosoft.com as secondary alias where needed: Keep MOERA aliases as secondary addresses only when necessary for legacy login compatibility, but avoid using them for outbound production sends.
• Monitor deliverability and reports: Watch Exchange Admin Center mail flow reports, DMARC aggregate reports, and Message Trace to confirm successful delivery and identify any remaining flows using MOERA addresses.
• Move high‑volume external sending to a specialist service: If you need to send large transactional or marketing volumes, migrate those flows to Azure Communication Services for Email or a dedicated ESP (SendGrid, Amazon SES, SparkPost, etc.) to avoid Exchange mailbox and tenant limits.

---

How to audit MOERA usage and detect problem senders​

• Use Message Trace in the Exchange Admin Center. Place a wildcard (e.g., @.onmicrosoft.com) in the Senders field and filter the resulting report by recipient domain to isolate external sends. This yields a list of messages that originated with MOERA addresses and shows whether recipients were internal or external.
• Use the Tenant Outbound External Recipients Rate report (EAC > Reports > Mail flow) to view tenant‑level outbound recipient counts. Microsoft’s broader tenant outbound quota and reporting tools — already in place for other outbound controls — can help you understand where your tenant sits relative to limits. (mc.merill.net)
• Run PowerShell scripts to enumerate mailboxes with primary SMTP or aliases in onmicrosoft.com and cross‑reference with recent outbound volume. This is essential for finding service accounts and hidden automation that don’t appear in regular inbox audits.

---

Edge cases and things administrators must not miss​

• Federated UPNs: Federated domains cannot be set as the tenant default domain for sending; add a non‑federated custom domain to act as the default if needed.
• DKIM with MOERA fallback: If DKIM signing is not configured for a custom domain, some Microsoft services may use d=<MOERA domain> as the signing domain; this behavior changes when custom domains are configured and DKIM is enabled. Confirm DKIM configuration after migration.
• Hybrid setups and mail.onmicrosoft.com: Hybrid routing can lead to scenarios where MOERA addresses (such as mail.onmicrosoft.com) are used in intermediate hops. Microsoft notes that certain internal‑originated system messages may remain outside throttling so long as MOERA domains are not used for original traffic; nevertheless, hybrid tenants should test flows thoroughly.
• Journaling and Microsoft Exchange Recipient: Some Microsoft‑originated messages use a fixed MicrosoftExchangeRecipient address that admins cannot change; Microsoft indicates these messages will not count against the MOERA throttle. Plan for these exceptions when analyzing quota usage.

---

Alternatives for legitimate high‑volume sending​

If your business needs exceed mailbox/tenant outbound rates or you need robust deliverability and analytics, consider these options:

• Azure Communication Services for Email — Microsoft’s recommended path for high‑volume transactional and B2C messaging, which is architected differently from Exchange Online and not counted against tenant mailbox send limits.
• Dedicated Email Service Providers (ESPs) — SendGrid, Amazon SES, Mailgun, SparkPost and others provide reputation management, bounce handling, and high throughput for marketing and transactional email.
• Exchange Online High Volume Email (HVE) — For certain scenarios Microsoft offers HVE capabilities; verify eligibility, external recipient handling and commercial terms before moving critical flows to this channel.

Choosing the right channel depends on feature requirements (templates, personalization, webhooks, analytics), compliance needs, and volume. Offloading high‑volume flows to purpose‑built services reduces the risk of hitting mailbox and tenant outbound controls and improves deliverability control.

---

Final assessment — what administrators should do next​

Microsoft’s MOERA throttling is a targeted, credible step to fix a real reputation problem that has been causing deliverability friction across the Microsoft 365 ecosystem. The change is precise in scope — only mail sent from the shared onmicrosoft.com namespace is affected — but it will be consequential for tenants and workflows that still rely on MOERA addresses for production sending. Administrators should treat the staged rollout calendar and Message Center notices as hard deadlines: audit now, migrate critical automation and high‑volume flows to custom domains or specialist services, and align authentication (SPF/DKIM/DMARC) for the new domain before switching principal senders. (techcommunity.microsoft.com)
A concise checklist to close this chapter:

• Audit outbound sends for any use of @.onmicrosoft.com addresses immediately.
• Purchase and validate a custom domain and configure SPF/DKIM/DMARC.
• Reconfigure mailboxes, connectors, and applications to use the custom domain for outbound sending; keep MOERA aliases as secondary where necessary.
• For high‑volume external sends, migrate to Azure Communication Services or an ESP.
• Monitor Message Center and EAC reporting during the ramp‑up windows so you’re not surprised by NDRs (550 5.7.236) once enforcement begins.

Microsoft’s messaging team has provided a clear technical specification, a staged timeline and a set of practical mitigations. The policy balances ecosystem health and deliverability improvements against an operational migration burden for those still relying on MOERA addresses — a burden that can be entirely avoided with timely migration to verified custom domains and the use of dedicated services for high‑volume mail.

---

Source: Microsoft Exchange Team Blog Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub